Chipkarten im Mobilfunk

Diplomarbeit

Chipkarten im Mobilfunk

Thomas Richter

Erstgutachter: Prof. Dr. Martin Leischner Zweitgutachter: Prof. Dr. Stefan Böhmer Abgabedatum: 29.10.2002

Erklärung: Hiermit versichere ich, dass ich die Diplomarbeit selbständig verfasst, und nur die hier angegebenen Quellen und Hilfsmittel verwendet habe. © by Thomas Richter ________________________________ Abgabedatum, Thomas Richter

Danksagung: Besonderer Dank gilt:

Prof. Dr. Martin Leischner und Prof. Dr. Stefan Böhmer für die gute Zusammenarbeit und die

konstruktive Kritik.

Stefan Kaliner, T-Mobile International für die praxisbezogene Beantwortung einiger Fragen zum Thema SIM,

SAT und UICC, die anhand der zur Verfügung stehenden Literatur nicht beantwortet werden konnten, sowie für

die Bereitstellung des in der Arbeit analysierten Traces.

Meinem Vater, Dipl. Ing. Dr. Gernot Richter, AIS - Fraunhofer Institut, der meine Arbeit probegelesen und mir

zusätzlich durch konstruktive Diskussionen eine objektivere Sicht vermittelt hat.

Meiner Frau, Dipl. Geol. Inga Niemeyer, die trotz mangelnder Sachkenntnis meine Arbeit im Frühstadium auf

Ausdrucksschwächen hin untersuchte.

Abbildungsverzeichnis ________________________________________________________________ Abbildungsverzeichnis

Abbildung 1 : Die Zellen im GSM Netz 6 Abbildung 2 : Intra MSC Handover 9 Abbildung 3 : Veränderungen der Netzinfrastruktur auf dem Weg von GSM zu GPRS 12 Abbildung 4 : Das UMTS Netz der ersten Generation 15 Abbildung 5 : Baumstruktur zur Erreichbarkeit von Files 17 Abbildung 6 : Der Aufbau von Command- und Response APDU 19 Abbildung 7 : ATR mit PTS und einem Command/Answer Paar 20 Abbildung 8 : Zustandsautomat „Mobile Equipment“ 24 Abbildung 9 : Die Verzeichnis-Struktur des SIM 30 Abbildung 11: Das Elementary File „Integrated Circuits Card Identification“ Annex A, Nr. 1 Abbildung 12: Das Elementary File „Language Preferences“ Annex A, Nr. 2 Abbildung 13: Das Elementary File „IMSI“ Annex A, Nr. 3 Abbildung 14: Das Elementary File „KC“ Annex A, Nr. 4 Abbildung 15: Das Elementary File „PLMN“ Annex A, Nr. 5 Abbildung 16: Das Elementary File „SIM Service Table“ Annex A, Nr. 6 Abbildung 17: Das Elementary File „Service Provider Name“ Annex A, Nr. 7 Abbildung 18: Das Elementary File „PUCT“ Annex A, Nr. 8 Abbildung 19: Das Elementary File „ACM“ Annex A, Nr. 9 Abbildung 20: Das Elementary File „Location Information“ Annex A, Nr.10 Abbildung 21: Das Elementary File „Phase“ Annex A, Nr.11 Abbildung 22: Das Elementary File “Fixed Dialling Numbers“ Annex A, Nr.12 Abbildung 23: Das Elementary File „Short Message Service“ Annex A, Nr.13 Abbildung 24: Das Elementary File „MSISDN“ Annex A, Nr.14 Abbildung 25: Das Elementary File „Last Number Dialled“ Annex A, Nr.15 Abbildung 26: Das Elementary File „Image“ Annex A, Nr.16 Abbildung 27: Image Instance Data File, eine Instanz eines EF Annex A, Nr.17 Abbildung 28: Das Elementary File „Ciphering and Integrity Keys” Annex A, Nr.18 Abbildung 29: Das Elementary File „Ciphering and Integrity Keys PS” Annex A, Nr.19 Abbildung 30: Das Elementary File „Packet Switched Location Information” Annex A, Nr.20 Abbildung 31 Das Elementary File „Incoming Call Information” Annex A, Nr.21 Abbildung 32: Das Elementary File „Incoming Call Timer“ Annex A, Nr.22 Abbildung 33: Das Elementary File „Hiddenkey“ Annex A, Nr.23 Abbildung 34: Das Elementary File „Enabled Services Table” Annex A, Nr.24 Abbildung 35: Das Elementary File „Phone Book Reference” Annex A, Nr.25 Abbildung 36: Das Elementary File „Phone Book Control” Annex A, Nr.26 Abbildung 37: Das Elementary File „EMAIL“ Annex A, Nr.27 Abbildung 38: Das 16. Byte des Terminal Profile Kommandos 47 Abbildung 39: Darstellung einer Proactive SIM Session, Menüauswahl 54 Abbildung 40: Structure of ENVELOPE (SMS-PP DOWNLOAD 55 Abbildung 41: Structure of ENVELOPE (CELL BROADCAST DOWNLOAD) 55 Abbildung 42: Structure of Response APDU after ENVELOPE (Call Control) 56 Abbildung 43: Empfang einer Daten SMS (SMS DATA DOWNLOAD) aus dem Netz 60 Abbildung 44: Der logische Aufbau der Smartcard 74 Abbildung 45: Übergabe der AV 80 Abbildung 46: Benutzer-Authentisierung und Schlüsselkontrolle 81 Abbildung 47: Authentisierung bei UMTS 82 Abbildung 48: Authentisierung des Netzes gegenüber USIM 83 Abbildung 49: 2G and 3G authentication in direct comparison Faltblatt Abbildung 50: Authentisierung des USIM gegenüber dem Netz 84 Abbildung 51: Die Protokollebenen von SIM und UICC im Vergleich 86

Tabellenverzeichnis ________________________________________________________________ Tabellenverzeichnis

Tabelle 1: Die funktionalen Anforderungen an das ME im „Generationenwechsel“ 22 Tabelle 2: Lv.2 DF Typen 30 Tabelle 3a: Die in der SIM Spezifikation vordefinierten Dateien der SIM Karte (übrige) 31 Tabelle 3b: Die in der SIM Spezifikation vordefinierten Dateien der SIM Karte (DFTELECOM) 32 Tabelle 4: Auf Dateien ausführbare Funktionen während einer GSM Session 32 Tabelle 5: Zugriffsbedingungen auf Dateien nach Sicherheitslevel 34 Tabelle 6: Ausschnitt aus der Dienst Nummerierungs-Liste 36 Tabelle 7: Unterschiede in der Zugriffsberechtigung bei Rufnummernverzeichnissen 38 Tabelle 8: Kodierung der einzelnen Kommandos 41 Tabelle 9: Kommandostruktur TLV Codierung 53 Tabelle 10: TLV Darstellung der IMEI 53 Tabelle 11: Zugriffsbedingungen auf Dateien nach Sicherheitslevel 73 Tabelle 12: Dateien der USIM Spezifikation, die auf der SIM-Karte nicht enthalten sind 76 Tabelle 13: Bei UMTS eingesetzte kryptographische Algorithmen 80 Tabelle 14: Vergleich von Dateitypen, Zugriffsmethoden und Sicherheitsaspekten 87 Tabelle 15: Vergleichende Analyse der Dateien in SIM und UICC (USIM) 88 Tabelle 16: Unterschiede in den Sicherheitskonzepten von UICC und SIM 90 Tabelle 17: Vergleich Initialisierungsprozedur SIM-USIM 91

Abkürzungsverzeichnis ________________________________________________________________ Abkürzungsverzeichnis 2G 2nd Generation

3G 3rd Generation

3GPP 3rd Generation Partnership Project AC Authorisation Center ACK Acknowledge (Byte) ACM Accumulated Call Meter ADF Application Dedicated File ADF Application Dedicated File ADM Administration AID Application Identifier AID DO Application Identifier Data Object AK Anonymity Key AMF Authentication Mangement Field APDU Application Protocol Data Unit APN Access Point Name ASCII American Standard Code for International Interchange ATM Asynchronous Transfer Mode ATR Answer To Reset AUTN Authentification Token AV Authentification Vector BC Bearer Capability BCCH Broadcast Control Channel BCD Binary Code Decimal BER Basic Encoding Rules BGT Block Guard Time BS Base Station BSC Base Station Controller BSS Base Station Subsystem BTS Base Transceiver Station BWT Block Waiting Time C-APDU Command-APDU CB Cell Broadcast CCP Capability Control Parameters CDMA Code Division Multiple Access CHV Card Holder Verification (Number) CK Cipher Key CTS Cordless Telephony System DCS Digital Cellular System CWI Character Waiting Integer CWT Character Waiting Time DF Dedicated File DTFM Dual Tone Frequency Management DRNC Drift RNC E-Commerce Electronic-Commerce EEPROM Erasable Enhanced Programmable Read Only Memory EF Elementary File EIR Equipment Identity Register ETSI European Telecommunications Standards Institute etu elementary time unit

Abkürzungsverzeichnis ________________________________________________________________ FAC Final Assembly Code FCP File Control Parameters FDD Frequency Division Duplex FDM Frequency Division Multiplex FID File Identifier FTP File Transfer Protocol GGSN Gateway GSN G/IWMSC Gateway / Inter Working MSC GMSC Gateway MSC GPRS General Packet Radio Services GSM Global System for Mobile communications (ehem. Group Special Mobile) GSN GPRS Support Node HLR Home Location Register HO Hand Over HTML Hyper Text Markup Language ICCID Integrated Circuits Card Identification (Number) ICS Incoming Call Status ID Identification (Number) IK Integrity Key IMEI International Mobile Station Equipment Identity IMEISV IMEI and Software Version Number IMSI International Mobile Subscriber Identity IN Intelligent Network IOC Insertion Of Card IP Internet Protokoll (zur Zeit Version 4) Ipv6 Internet Protokoll Version 6 auch IpnG (next Generation) genannt ISDN International Services Digital Network ISO/IEC International Organisation for Standardization / International Electrotechnical Commission ITU International Telecommunications Union IWMSC Inter Working MSC JVM Java Virtual Machine kbs, kbps Kilo Bit Per Second LA Location Area LAC Location Area Code LAI Location Area Identifier LAPD Link Access Procedure for D Channel lc length command (die Länge des Datenteils der folgenden Anweisung) le length expected (die Länge des Datenteils der erwarteten Rückantwort) LU Location Update M Mandatory MAC Message Authentification Code MCC Mobile Country Code M-Commerce Mobile-Commerce ME Mobile Equipment (auch: mobiles Endgerät, Endgerät, MT) MExE Mobile Execution Environment MF Master File (auf Chipkarte) MMI Man Machine Interface MNC Mobile Network Code MO Mobile Originated (die MS ist Verursacher) MS Mobile Station (dt. Mobilstation, MT+SIM, auch als UE bezeichnet) MSC Mobile Switching Center (Vermittlungsstelle des Mobilfunks) MSISDN Mobile Station ISDN (Rufnummer Mobilfunk)

Abkürzungsverzeichnis ________________________________________________________________ MSRN Mobile Station Roaming Number MT Mobile Terminal (oder, ME, Endgerät, mobiles Endgerät) MT Mobile Terminated (Die MS ist Empfänger) NDC Network Detection Code (PLMN Vorwahl, z.B. 0172) NSS Network Switching Subsystem O Obligatory OMC Operation and Maintanence Center (dt. Betreiber-Teilsystem) OSS Operation Sub System PCH Paging Channel PCU Packet Control Unit PCM 30 Pulse Code Modulation mit 30 Verkehrs-Kanälen PDA Personal Digital Assistant PIN Personal Identification Number PKI Public Key Infrastructure PLMN Public Land Mobile Network PMP Point to Multi Point PP Point to Point PSTN Public Switched Telephone Network PTS Protocol Type Selection PUK Pin Unlock Key PW Pass Word QoS Quality of Service RACH Random Access Control Channel RADIUS Remote Authentification Dial-In User RAM Random Access Memory RAND Random (Zufallszahl) R-APDU Response-APDU RegTP Regulierungsbehörde für Telekommunikation und Post (in Deutschland) REQ Request RFC Request For Command RI Radio Interface RNC Radio Network Controller ROM Read Only Memory RSA Rivest-Shamir-Adleman (Algorithmus - zur asymmetrischen Verschlüsselung) SABM Set Asynchronous Balanced Mode SAP Service Access Point SAT SIM Application Toolkit SC Security Condition SDCCH Stand Alone Dedicated Control Channel SE Security Environment SEID Security Environment ID SFI Short Elementary File Identifier SGSN Serving GSN SigG Signatur Gesetz SIM Subscriber Identity Module SMS Short Message Service SMS-SC Short Message Service - Service Center SNR Serial Number SoLSA Support of Localized Service Areas SQN Sequence Number SRES Signed RESponse (vom SIM berechnet) SRNC Serving RNC

Abkürzungsverzeichnis ________________________________________________________________ SS Supplementary Service (Zusatzdienst, Mehrwertdienst) SST SIM Service Table SVN Software Version Number TCH Traffic Channel TCP Transport Control Protocol T-D1 Telekom-D1 (Mobilfunknetz der Deutschen Telekom) TDD Time Division Duplex TDM Time Division Multiplex TDMA Time Division Multiplex multiple Access TLV Tag Length Value (eine Vorschrift, wie Objekte nach BER zu codieren sind) TOC Type Of Code TMSI Temporary Mobile Subscriber Identity TMUI Temporary Mobile User Identity (TMSI im UMTS-Umfeld) TON Type Of Number TPDU Transport Protocol Data Unit TRAU Transcoder and Rate Adaption Unit UDP User Datagram P UE User Equipment (synonym: ME) UICC Universal Integrated Circuit Card UMTS Universal Mobile Telecommunication System URL Uniform Resource Locator USAT USIM Application Toolkit USIM Universal Subscriber Identity Module USSD Unstructured Suplemmentary Service Data UST USIM Service Table UTRAN UMTS Terrestrial Radio Access Network VAS Value Added Services (Mehrwertdienste) VE:N Schnittstelle Internet : Mobiles Netz VLR Visitor Location Register WAE Wireless Application Environment WAP Wireless Application Protocol WCDMA Wide CDMA (es werden lange Codewörter verwendet) WIM Wireless Identity Module WML Wireless Markup Language WMP Wireless Bit Map (das BMP-Pendant von WAP) WTLS Wireless Transport Layer Security WWW World Wide Web

Inhaltsverzeichnis ________________________________________________________________ Inhaltsverzeichnis

Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis

1. Einführung 1 1.1. Der Einsatz von Chipkarten im Mobilfunk 1 1.2. Aufgabenstellung und Eingrenzung 3 1.3. Erläuterungen zum Aufbau der Arbeit und der Vorgehensweise 3

2. Funktionseinheiten des Mobilfunks 5

2.1. Subsysteme von GSM 5 2.2. Subsysteme von GPRS und UMTS 11 2.3. Kontaktbehaftete Chipkarten 16 2.4. Mobile Equipment 20 2.5. Zusammenfassung 27

3. SIM: Phase 1 - Die Chipkarte des GSM 28

3.1. Das Trägersystem 29 3.2. Sicherheitsrelevante Prozesse des SIM 42

4. SAT: Phase 2 - Eine funktionale Erweiterung des SIM 45

4.1 Zusätzlicher Funktionsumfang 45 4.2 Wirkungsweise der neuen Funktionen 46 4.3 Die Interaktion zwischen ME und SIM am Beispiel eines Traces 60

5. UICC: Phase 2+ - Die Multiapplikationskarte des UMTS 70 5.1 Das Trägersystem 70 5.2 Sicherheitsrelevante Prozesse des USIM 80

6. Vergleichende Analyse und Zusammenfassung 86

7. Ausblick: Entwicklungstrends 93

Literaturverzeichnis Annex A: Grafische Darstellungen von Dateiinhalten aus SIM und UICC Annex B: Ausschnitte des Traces aus Kapitel 4.3 und Analyse Annex C: Zusätzliche Informationen

Kapitel 1: Einführung ________________________________________________________________

1 Einführung Motivation zur Wahl dieser Thematik für die Diplomarbeit ist die Tatsache, dass es bisher keine zusammenfas-

sende und vergleichende Darstellung der verschiedenen Mobilfunk-Chipkarten-Spezifikationen und Normen

gibt. Vielmehr kommt der am Gesamtüberblick oder auch Detail interessierte Leser nicht umhin, mangels Se-

kundärliteratur auf die für einen Außenstehenden schwer lesbaren Spezifikationen zuzugreifen.

Natürlich bilden diese Spezifikationen die Grundlage für eine wirtschaftlich vertretbare Umsetzung neuer Tech-

nologien. Die Notwendigkeit, dass sich die einzelnen Hersteller jeweils an die aktuellste Version einer Spezifika-

tion zu halten, ist am folgenden Beispiel gut erkennbar:

Im Oktober 1999 wurde der Dienst WAP (Wireless Application Protocol) in der Version WAP 1.1 flächende-

ckend in das Wirknetz integriert. Die Hersteller der Endgeräte produzierten jedoch ihre Endgeräte für die WAP

Version 1.0, was zur Folge hatte, dass zwar der Dienst theoretisch seitens der Anbieter zur Verfügung stand, er

jedoch vom Endkunden nicht genutzt werden konnte, da die als WAP-fähig produzierten Endgeräte der Version

1.0 die empfangenen Daten aufgrund wesentlicher Veränderungen beim Versionswechsel zu Version 1.1 nicht

interpretieren konnten. Dieser schwer nachvollziehbare Fehler kostete beide Seiten Millionen an Umsatz. Das

Weihnachtsgeschäft fiel zumindest für die WAP-Dienste aus. Schwer nachvollziehbar war der Fehler deshalb,

weil sowohl die meisten Endgerätehersteller, als auch die großen Telekommunikationsanbieter Mitglieder des

WAP-Forums sind (und waren) und ihnen somit alle Informationen frühzeitig zur Verfügung standen.

Die Quellen, auf die sich diese Arbeit stützt, sind größtenteils Spezifikationen der Normungsgremien ETSI,

3GPP und des WAP-Forums. Die meisten Spezifikationen im Bereich des Mobilfunks werden vom internationa-

len 3GPP Konsortium veröffentlicht. Einige wenige Spezifikationen sind in ihrem Geltungsbereich zunächst auf

Europa beschränkt und daher von ETSI spezifiziert worden. WAP-spezifische Dokumente werden vom WAP-

Forum erstellt und als De-facto-Standards veröffentlicht. In Bereichen, zu denen bereits Standardliteratur exis-

tiert, so z.B. zu den Chipkartenstandards und zu GSM allgemein, wurde diese ebenfalls verwendet.

1.1 Der Einsatz von Chipkarten im Mobilfunk

Seit Anbeginn des zellularen Mobilfunks nach dem GSM Standard waren Chipkarten zur Authentisierung der

einzelnen Benutzer vorgesehen und wurden auch verwendet. Bei den Entscheidungen der damaligen Group Spe-

cial Mobile wägte man die Vorteile von Chipkarten gegenüber statischen Benutzereinträgen im mobilen Endge-

rät ab.

Während Chipkarten zwar eine einmalige, erhöhte Investition seitens der Mobilfunknetzbetreiber bzw. Mobil-

funk-Dienstanbieter bedeuteten (die in Form einer Einrichtungsgebühr auf die Kunden umgelegt wurde), hätte

eine direkte Personalisierung der Endgeräte, auf lange Sicht betrachtet, sowohl für den Endverbraucher als auch

den Dienstanbieter einen weit höheren Aufwand erfordert. Des Weiteren wäre ein Teil der vorgesehenen Funkti-

onen insbesondere in Bezug auf die Datenintegrität, eine klare Kostenerfassung sowie eine sichere Verschlüsse-

lung der über die Luftschnittstelle Um zu übertragenden Daten nur mit erheblich größerem Aufwand und wahr-

scheinlich unzureichend realisierbar gewesen (ohne automatisch die Unsicherheit des Internets in das GSM-Netz

zu übernehmen). Protokollstandards für eine Kommunikation zwischen Chipkarten und Terminal gab es schon.

Es gibt eine Vielzahl von Argumenten, die im Mobilfunk für den Einsatz von Chipkarten sprechen:

1

Kapitel 1.1: Der Einsatz von Chipkarten im Mobilfunk ________________________________________________________________

• Ein absoluter Schreibschutz für abrechnungsrelevante Benutzerdaten ist wirtschaftlich umsetzbar. Wä-

ren die Daten ebenso unveränderlich im Endgerät gespeichert, müsste sich der Benutzer bei jeder Ver-

tragsmodifikation ein neues Endgerät anschaffen, ohne das Alte veräußern zu können.

• Eine einfache Übernahme aller auf der Chipkarte gespeicherten persönlichen Daten bei einem Wechsel

des Endgeräts ist durch ein einfaches Umsetzen der Chipkarte möglich.

• Es entstehen relativ geringe Verwaltungskosten seitens der Netzbetreiber bei Vertrags- oder Endgeräte-

wechsel. Da die Chipkarten im Gegensatz zu den Endgeräten von den Netzbetreibern selbst vertrieben

werden, können die relevanten Daten bereits vor dem Vertrieb erfasst und später mit dem abgeschlosse-

nen Vertrag personalisiert (den Vertragsdaten verknüpft) werden. Wären die Daten Bestandteil der

Endgerätesoftware, müsste sich jeder Kunde nach dem Erwerb eines (neuen) Endgeräts zunächst zu ei-

ner offiziellen Stelle begeben, um es personalisieren zu lassen.

• Neue, softwaregebundene Dienste einzuführen erfordert seitens der Netzbetreiber durch schrittweisen

Austausch der Karten einen verhältnismäßig geringen Aufwand. Es ist weit schwieriger, die ME-

Hersteller zu mobilisieren, den Dienst auf ihren Endgeräten zu integrieren und zusätzlich noch den

Kunden zum Neukauf eines Endgeräts zu bewegen.

• Der Verschlüsselungsprozess kann auf Schlüsseln, die auf der Karte gespeichert sind basieren. Würden

die Schlüssel statt dessen im Endgerät gespeichert, wäre dies ein Sicherheitsrisiko, da die „geheimen“

Daten (Schlüssel, IMSI, etc.) aus dem Endgerät von Dritten weit einfacher auszulesen wären als aus der

Chipkarte.

• Durch die Speicherung einer temporären Identifikationsnummer (TMSI) auf der Karte ist ein sicherer,

Endgeräte-unabhängiger Authentisierungsprozess zum Aufbau einer Verbindung ohne die Übertragung

persönlicher Daten im Klartext realisierbar. Dies wäre z.B. im Internet nicht möglich, ohne bereits eine

bestehende Verbindung ins Internet aufgebaut zu haben; die Einwahl zum Service Provider wird in der

Regel unverschlüsselt durchgeführt und ist unabhängig von den Telefongebühren*1.

• Dadurch dass die Endgerätehersteller sich an die Standards der Chipkarten halten müssen, um eine

Funktionsfähigkeit ihrer Endgeräte im Wirknetz gewährleisten zu können, ist automatisch auch gesi-

chert, dass alle Endgeräte über das eigene physikalische Netz hinaus funktionieren.

• Das Endgerät zu wechseln und dennoch den „alten“ Vertrag beizubehalten erfordert für den Endkunden

einen geringen Aufwand und ermöglicht somit eine erhöhte Bereitschaft zur Akzeptanz neuer Techno-

logien und Dienste*2.

• Eine Sichere Speicherung von persönlichen Daten durch den Benutzer ist möglich, denn die persönli-

chen Daten können auf der Chipkarte abgelegt werden, auf die von außerhalb des Endgerätes nur unter

erheblichem Aufwand (physikalisch) zugegriffen werden kann.

• Benutzerspezifische Daten, wie z.B. das Adressbuch können beim Endgerätewechsel einfach ins neue

Endgerät übernommen werden.

• Benutzer und Endgerät können unabhängig voneinander seitens des Netzes gesperrt werden.

• (UMTS) Integration der Qualifizierten Signatur nach dem Signatur Gesetz ist umsetzbar.

• (UMTS) Erweiterte Nutzungsmöglichkeiten des Endgeräts durch Mobile Payment (M-Payment) sind

realisierbar. *1 Es erfolgt i.d.R. kein zeitabhängiges Billing, wodurch die Sicherheitsanforderungen deutlich niedriger sind. *2 durch einfach durchzuführenden Austausch der Karte vom alten in das neue Gerät

2

Kapitel 1.2: Aufgabenstellung und Eingrenzung ________________________________________________________________

1.2 Aufgabenstellung und Eingrenzung Aufgabenstellung:

Die Arbeit „Chipkarten im Mobilfunk“ hat das Ziel, die bestehenden Spezifikationen von 3GPP und ETSI in ei-

ner Weise aufzuarbeiten, die den Mobilfunk aus einer Systemsicht betrachtet und die Rolle der Chipkarte in die-

sem System verdeutlicht und analysiert.

In der Standardliteratur findet man zwar Schrifttum zum Thema GSM (z.B. [A]), wie auch zum Thema Chip-

karten (z.B. [B]), allerdings findet man keine Literatur, die beides direkt miteinander in Verbindung bringt und

im Zusammenhang betrachtet. Wenn ein Buch zum Thema Chipkarten beispielsweise auch die Chipkarten des

Mobilfunks behandelt, wird das Netz des Mobilfunks ebenso wie das Terminal stets als Blackbox dargestellt, in

die Daten übermittelt werden und aus der wieder Daten zurückkommen.

Die Fragestellung, welche Aufgaben die Chipkarte erfüllen soll und wie sie ihnen gerecht wird, steht im Mittel-

punkt dieser Arbeit. Anhand dieser Fragestellung wird der Migrationspfad von der ersten SIM-Karte im Jahr

1991 (GSM Phase1) zur zukünftigen UICC-Karte (GSM Phase 2+) im UMTS-Netz (2003) aufgezeigt und fach-

lich kritisch bewertet, so dass weitere Entwicklungstrends für die Zukunft diskutiert werden können.

Eingrenzung:

Die zum GSM gehörigen Komponenten des Festnetzes, wie Basisstationen, Mobile Switching Center, Home Lo-

cation Register und weitere werden nur so weit vorgestellt, als dies erforderlich ist, um ihre für diese Arbeit rele-

vanten Funktionen in Bezug auf Transponder und Chipkarte sinnvoll einordnen zu können. Sie sind jedoch kein

Schwerpunkt der Arbeit. Die explizite Darstellung der grundlegenden Chipkartenprotokolle „T=0“ und „T=1“

und die Basisfunktionen von kontaktbehafteten Chipkarten und Terminal sind ebenfalls kein Schwerpunkt dieser

Arbeit und werden nur einführend behandelt. Zusätzlich wird sowohl im Text als auch in der kommentierten

Quellenangabe auf entsprechende Literatur verwiesen.

Der nachrichtentechnische Hintergrund (Frequenzmanagement, Kanalcodierung, Modulationsverfahren) sowie

das intelligente Netz, das primär zur Abwicklung der Abrechnungsroutinen (Billing) verwendet wird, werden in

dieser Arbeit nicht behandelt.

1.3 Erläuterungen zum Aufbau der Arbeit und der Vorgehensweise Kapitel 2 erläutert die wesentlichen und für das Verständnis dieser Arbeit erforderlichen Zusammenhänge

bezüglich der Einzelkomponenten des GSM-Umfelds. So wird in Kapitel 2, Unterkapitel 1 (wird im Folgenden

verkürzt als Kapitel 2.1 bezeichnet) der Festnetzanteil von GSM im Überblick betrachtet und gemäß den Aufga-

ben der Einzelkomponenten eine funktionale Einordnung ermöglicht. In Kapitel 2.2 werden GPRS und UMTS

im Ansatz erläutert und in Kapitel 2.3 werden allgemein die grundlegenden Funktionen von kontaktbehafteten

Speicherchipkarten insbesondere in Bezug auf ihr Dateimanagement erörtert.

Kapitel 2.4 betrachtet etwas ausführlicher - da es dafür abgesehen von den Spezifikationen keine adäquate Lite-

ratur gibt - die Anforderungen an das mobile Endgerät (Mobile Equipment, ME oder Mobile Terminal, MT) hin

3

Kapitel 1.3: Erläuterungen zum Aufbau der Arbeit und der Vorgehensweise ________________________________________________________________ sichtlich der für die Chipkarte relevanten Funktionen. Des Weiteren werden die mit den GSM-Phasenwechseln

verbundenen, veränderten Anforderungen an die Endgeräte in diesem Kapitel vergleichend analysiert.

In Kapitel 3 wird der Leistungs- (Funktions-) umfang der Chipkarten der ersten GSM-Phase im Detail betrachtet.

Kapitel 3.2 enthält eine Betrachtung der sicherheitsrelevanten Funktionen der SIM-Karte unter anderem in Be-

zug auf die Einbuchungs-Prozedur und die Verschlüsselung auf der Luftschnittstelle.

In Kapitel 4 wird die Erweiterung des SIM-Befehlssatzes mit der Einführung von SAT beschrieben und in seinen

Konsequenzen erläutert. Am Ende dieses Kapitels steht in Kapitel 4.3 die Analyse eines Traces, in dem die

Funktionsabläufe, an denen die Chipkarte maßgeblich beteiligt ist beispielhaft demonstriert werden. Der zur A-

nalyse vorliegende Hex-Dump ist eine Aufzeichnung der Kommunikation zwischen einem Phase 2 Endgerät und

einer Phase 2 SIM-Karte.

Die (für Europa) als Smart Card spezifizierte Mobilfunk-Chipkarte der dritten Generation (Phase 2+), die bei

UMTS eingesetzt werden wird, ist das Thema von Kapitel 5. Diese Multi-Applikations-Karte ist im Gegensatz

zur SIM-Karte modular aufgebaut und verfügt über eine Programmierschnittstelle auf die Anwendungen zugrei-

fen können. Die Beschreibung der Anwendungen beschränkt sich hauptsächlich auf die mit dem SIM der Phasen

1 und 2 vergleichbaren Anwendungen. In Kapitel 5.2 wird das in Relation zur SIM-Karte stark erweiterte Si-

cherheitskonzept und seine Umsetzung erläutert. In Kapitel 6 werden die einzelnen Module und Mechanismen

der Phasen 1 - 2+ vergleichend analysiert. Am Ende dieses Kapitel steht zugleich das Fazit der Arbeit. Im sieb-

ten Kapitel werden abschließend Entwicklungstrends für die Zukunft aufgezeigt.

Von den untersuchten Spezifikationen wurde grundsätzlich nur die neueste Version von Release 99 verwendet.

Lediglich zur Analyse der zeitlichen Entwicklung der Spezifikationen aufgrund gestiegener Anforderungen wur-

den auch ältere Releases herangezogen (Kapitel 2.4).

Von Zitaten in englischer Sprache wurde weitestgehend abgesehen, da es sich bei dieser Arbeit um einen

deutschsprachigen Text handelt. Statt dessen wird auf entsprechende Stellen in den Spezifikationen verwiesen,

an denen die Informationen bei Bedarf nachgelesen werden können.

Die Daten zu den einzelnen Grafiken und Tabellen wurden teilweise aus mehreren Spezifikationen und unter-

schiedlichsten Kapiteln der Spezifikationen abgeleitet, so dass ein detailliertes Verweisen auf die Einzelquellen

je Eintrag kaum der Übersicht dienlich wäre. Statt dessen werden die Spezifikationen angegeben (teils zu Beginn

des Kapitels), anhand derer die Grafiken und Tabellen erstellt wurden. Manche Grafiken wurden zwar über-

nommen aber durch Anpassungen in ihrer Aussage konkretisiert. In diesen Fällen wird darauf hingewiesen.

Bei Fragestellungen, die nicht vollständig anhand der Spezifikationen geklärt werden konnten, stand mir freund-

licherweise Herr Stefan Kaliner von der T-Mobile International beratend zur Seite.

Der schriftlichen Arbeit liegt zusätzlich eine CD-Rom bei. Sie enthält die Arbeit selbst in digitaler Form (*.pdf)

alle öffentlich zugänglichen (kostenfreien) verwendeten Spezifikationen und Kopien der referenzierten Websei-

ten, sowie den in der Arbeit diskutierten Trace.

Zusätzlich liegt der Arbeit noch ein Faltblatt bei, auf dem die Sicherheitsmechanismen von SIM und UICC über-

sichtlich gegenüber gestellt wurden. Es trägt die Abbildungsnummer 49 und wurde aus Informationen der Spezi-

fikationen [15], [16], [17] und [18] zusammengestellt.

4

Kapitel 2: Funktionseinheiten des Mobilfunks ________________________________________________________________ 2 Funktionseinheiten des Mobilfunks Bevor die Funktionen der Chipkarten des Mobilfunks im Zusammenhang mit dem bestehenden Netz betrachtet

werden, werden zunächst die beteiligten Funktionseinheiten des Netzes beschrieben, zu denen auch die Karten

selbst, ebenso wie das mobile Endgerät in seiner Funktion als Terminal gehören. Nur so ist eine Abgrenzung

vom Restsystem möglich, ohne den Blick auf das Gesamtbild zu vernachlässigen.

Welche Funktionen übernimmt welche Funktionseinheit im Netz? Diese Frage ist essentiell für ein umfassendes

Verständnis, wenn es darum geht, Daten, die von der Chipkarte versendet bzw. zur Weiterverarbeitung empfan-

gen werden, zu analysieren.

Die folgenden Unterkapitel vermitteln einen Überblick über die im bestehenden GSM-Netz (Kap. 2.1) und

GPRS/UMTS-Netz (Kap. 2.2) beteiligten Subsysteme und Komponenten (Kap. 2.3: kontaktbehaftete Speicher-

chipkarten und Kap. 2.4: Mobile Equipment). Die Einführung beschränkt sich auf die zum Verständnis dieser

Arbeit erforderlichen Grundkenntnisse.

2.1 Subsysteme von GSM Für dieses Unterkapitel wurden die Quellen [10], [A], [C] und [D] verwendet.

Das in Europa realisierte GSM-Netz besteht funktional aus 4 Komplexen, die sich jeweils wieder in Untereinhei-

ten aufteilen lassen, jedoch nicht zwangsläufig auch in der Umsetzung aus physikalisch unterschiedlichen Ein-

heiten (Rechnern) bestehen:

1. Das Base Station Subsystem, BSS

2. Das Network Switching Subsystem, NSS

3. Das Operation Subsystem, OSS

4. Short Message Service Einheit*1

Das Base Station Subsystem, im Deutschen auch als „Funkteilsystem“ bezeichnet, besteht aus

• allen zur Zeit im PLMN (Public Land Mobile Network, das Netz eines Betreibers) eingebuch-

ten Mobilstationen (oder Mobile Station, MS), die sich jeweils aus dem Mobile Equipment

(ME) und der Chipkarte (SIM) zusammensetzen,

• den Empfangs- und Sendestationen (Base Transceiver Station, BTS), die als einzige eine direk-

te Verbindung zu den Mobilstationen über die Luftschnittstelle Um realisieren können,

• und den Koordinatoren der Funkstationen, den Base Station Controllern (BSC), die Daten

mehrerer BTS an das übrige Netz weiterreichen (und umgekehrt) und die u.a. auch für die Fre-

quenzzuweisung an die MS verantwortlich sind.

Bekanntlich handelt es sich bei dem GSM-Netz um ein zellulares System. Jede Zelle beinhaltet eine Funkstation

BTS, die für das netzseitige Senden und Empfangen über die Luftschnittstelle verantwortlich ist. Sie befindet

*1 Wird in der Regel nicht als eigenständiges Subsystem bezeichnet, der Übersicht halber aber in dieser Arbeit als solches definiert. Tatsächlich wird es in der Fachwelt keinem der Subsysteme zugeordnet und steht als Kom-ponente alleine im Raum.

5

Kapitel 2.1: Subsysteme des GSM Netzes ___________________________________________________________________________ sich in der Regel im Zentrum einer jeden Zelle, kann aber je nach geographischen Besonderheiten des Geländes

auch an einer anderen (günstigeren) Stelle angesiedelt sein. Sie speist (laut GSM-Spezifikation) ein Gebiet von

maximal 35 km Radius. Ebenfalls ein Bestandteil jeder Zelle sind die in ihr befindlichen Mobilstationen. Mehre-

re Zellen werden zu einer größeren Funktionseinheit, dem Cluster verbunden. Alle Funkstationen eines Clusters

werden von einem Base Station Controller organisiert. Eine Clustergröße von 7 Zellen hat sich bezüglich des

Frequenzmanagements in der Praxis als sinnvoll herausgestellt und wird in Deutschland überwiegend verwendet.

Es gibt jedoch auch Clustergrößen von 3 bzw. 12 Zellen.

Jede Zelle innerhalb eines solchen Clusters verwendet einen eigenen Satz von Frequenzen, die erst in einer grö-

ßeren Entfernung wiederverwendet werden können, da der Funkverkehr ansonsten aufgrund von Überlagerungen

stark gestört würde. Die Größe der gewählten Cluster ist daher unter anderem von der Anzahl der verfügbaren

Frequenzen (aber auch von der Zellgröße, der Sendeleistung, etc.) und dem erwarteten Verkehrsaufkommen ab-

hängig.

Das Base Station Subsystem besteht aus allen Funktionseinheiten innerhalb aller Cluster eines PLMN zzgl. der

Base Station Controller. Außerhalb der Cluster werden die Daten im ISDN-Netz übertragen (teilweise auch

schon zwischen BTS und BSC; hier gibt es jedoch auch häufig Funkverbindungen).

Das Network Switching Subsystem oder auch Vermittlungs-Teilsystem besteht aus Funktionseinheiten, deren

wesentliche Aufgabe Routing (Wegefindung) und Vermittlung sind. Zu diesen Funktionseinheiten zählen das (es

gibt ggf. mehrere innerhalb eines PLMN) Mobile Switching Center (MSC), welches alle Funktionen einer Ver-

mittlungsstation umfasst, und die Kundendatenbanken Home Location Register (HLR) und Visitor Location Re-

gister (VLR).

BTS

BSC

MSC

BTS

BSC

Jede Zelle hat ihre eigene Basisstation. 7 Zellen zusammen ergeben einen Cluster, der von ei-nem BSC verwaltet wird. Ein oder mehrere BSC werden von einem MSC verwaltet.

Die Zellen im GSM Netz:

Abbildung 1: Die Zellen im GSM Netz

Das Mobile Switching Center hat neben der Vermittlung auch die Koordination und Verschaltung der BSCs als

Aufgabe, dient allerdings auch als Schnittstelle zu den Verwaltungseinheiten des Betreiber-Teilsystems (OSS)

6

Kapitel 2.1: Subsysteme des GSM Netzes ___________________________________________________________________________ und zu den Datenbanken und ist an weiteren Vorgängen, wie z.B. dem Handover maßgeblich beteiligt. Spezielle

MSCs, sogenannte Gateway-MSCs (GMSC), verbinden GSM-Netze unterschiedlicher Anbieter (PLMNs, Funk-

netze) miteinander. Das Home Location Register ist eine reine Datenbank, aus der Daten ausgelesen und in die

ebenfalls Daten eingetragen werden können. In dieser Datenbank sind alle zur Abrechnung erforderlichen Kun-

dendaten enthalten, wie z.B. die mobile Rufnummer des Kunden (MSISDN), der Wohnsitz, die einmalige Kar-

tennummer seiner SIM-Karte (IMSI) sowie ein Eintrag, der angibt, in welchem Bereich des Teilnetzes (Verwal-

tungsbereich eines VLR), der Kunde zuletzt angemeldet war, damit er bei einem eingehenden Anruf möglichst

schnell lokalisiert (Paging) werden kann. Das VLR schließlich enthält eine Kopie des HLR und zusätzlich Daten

bzgl. des Clusters, in dem der Kunde zur Zeit eingebucht ist, bzw. zuletzt eingebucht war. Die genaue Zelle, in

der er sich aufhält wird nicht festgehalten. Das VLR ist insbesondere dafür verantwortlich, dass eingehende An-

rufe vermittelt werden können (das Netz also weiß, wo in etwa sich der Benutzer aufhält).

Die Anzahl der in einem Netz (PLMN) angesiedelten MSCs sowie HLRs und VLRs variiert von Anbieter zu

Anbieter beträchtlich und ist u.a. abhängig von dem Verkehrsaufkommen in einzelnen, geografischen Bereichen.

Es kann durchaus sein, dass ein kleiner Mobilfunknetzbetreiber nur ein einziges MSC (Gleiches gilt für HLR

und VLR) besitzt, ebenso wäre es aber auch möglich, dass er 30 Vermittlungsstationen gleichzeitig einsetzt.

Die Datenbank HLR hat im Wesentlichen drei Aufgaben: Bei der erstmaligen Einbuchung wird der Kunde in

dem für die aktuelle Region verantwortlichen HLR permanent eingetragen. Dieses gilt dann als das für ihn zu-

ständige HLR unabhängig davon, ob sein tatsächlicher Wohnort auch in dessen Zuständigkeitsbereich fällt. Des

Weiteren speichert das HLR Informationen darüber ab, bei welchem VLR er zuletzt registriert war, die es bei

eingehenden Anrufen als Routinginformation an das anfragende MSC weiter gibt. Schließlich werden auch die

für das Billing notwendigen Daten dort abgespeichert, also die Gesprächseinheiten und Verbindungsdaten für

evtl. Anfechtungen und zu erstellende Einzelnachweise.

Das Visitor Location Register ist in der Regel keine eigenständige physikalische Funktionseinheit (was aber

möglich wäre), sondern wird in einem MSC bzw. GMSC integriert. Das ist sinnvoll, weil dort die zur Vermitt-

lung notwendigen Kundendaten gespeichert sind und eine Ausgliederung zwangsläufig das Verkehrsaufkommen

im umliegenden Netz vervielfachen würde.

Das Operation Subsystem (OSS) besteht aus den Funktionseinheiten Operation and Maintenance Center (OMC),

Authorisation Center (AC oder AuC) und dem Equipment Identity Register (EIR). Alle diese Funktionseinheiten

sind in der Regel auf sinnvolle Weise in andere Netzbausteine integriert, könnten theoretisch aber auch einzeln

in Hardware realisiert sein.

Das Authorisation Center ist die Funktionseinheit, die beim Einbuchungsvorgang die Legitimation des Netz-

zugriffs durch den Benutzer überprüft (es verifiziert den Benutzer anhand von signierten Daten) und ihm dann

entsprechend den Zugang gewährt oder verweigert. Darüber hinaus ist es für die Aushandlung von temporären

Schlüsseln mitverantwortlich. Es findet seinen Platz gewöhnlich innerhalb der Maschine, die auch das HLR be-

herbergt, da dieses ohnehin die Kundendaten enthält und somit den Lieferanten für die Daten zur Verifikation im

AC darstellt. Das Equipment Identity Register wird in der Praxis innerhalb einer (jeden) MSC angesiedelt und

enthält u.a. die Listen gestohlen gemeldeter Endgeräte und SIM-Karten. Diese Listen sind in Black-, Grey- und

White-Lists unterteilt, die jeweils Verweigerungen des Netzzugangs, Einschränkungen für bestimmte Geräte

(bzw. Karten) oder auch nur die Registrierung von Endgeräten enthalten. Das OMC ist eine übergeordnete Ü-

berwachungseinheit des Netzbetreibers. Von hier aus kann der Netzbetreiber das gesamte GSM Netz (PLMN)

7

Kapitel 2.1: Subsysteme des GSM Netzes ___________________________________________________________________________ überwachen und per Fernzugriff steuern. Es führt ständig Messungen u.a. der Netzlast durch, bereitet im Netz

gesammelte Informationen auf, etc. Letztlich ist es die administrative Einheit für den Netzbetreiber.

Die Short Message Service (SMS) Einheit wird üblicherweise nicht als eigenständige Funktionseinheit im GSM-

Netz angesehen. Der besseren Übersicht wegen wird es in dieser Arbeit aber getan, da es keine logischen Über-

legungen gibt, sie irgendeiner anderen Funktionseinheit zuzuschreiben. Sie besteht aus zwei Komponenten, dem

SMS-SC (SMS-Service Center) und einer speziellen Vermittlungsstelle, dem Gateway Interworking MSC

(GW/IWMSC). Im SMS-SC werden Kurznachrichten bis zur entgültigen Zustellung zwischengespeichert. Es

dient als Verwaltungs- und Vermittlungsstelle für Kurznachrichten. SMS können direkt von Mailsystemen des

Internets an das SMS-SC adressiert werden. Das GW/IWMSC ist eine Einheit, die als Schnittstelle zwischen

Mobilfunknetz und SMS-SC dient, und somit auch als Schnittstelle zum restlichen Festnetz fungiert. Es führt

zwar einzelne vermittlungstechnische Aufgaben aus, wird jedoch nicht als eine vollwertige Vermittlungseinrich-

tung angesehen, da es keine Verkehrskanäle schaltet. Beide Einheiten, GW/IWMSC und SMS-SC werden in der

Regel in einer einzigen SMS-Einheit zusammengefasst.

Um das Zusammenspiel der Einzelkomponenten beispielhaft zu demonstrieren werden nun das Handover, Pa-

ging und die erstmalige Einbuchung in das PLMN aus der Sicht des Netzes erläutert.

Das Handover am Beispiel eines Inter MSC Handover vgl. [22]: Beim Handover (HO) handelt es sich um das Weiterreichen einer bestehenden Verbindung an eine andere Zelle

ohne die bestehende Verbindung zu trennen. Es gibt aus der Sicht des Netzes drei unterschiedliche Arten von

Situationen für die Realisierung eines HO. Diese werden je nach der Art des vom Benutzer durch seine Ortsver-

änderung gewechselten Verwaltungsbereichs ausgewählt.

• BSC gesteuertes Handover (Intra-BSC-HO): In dieser Situation gehören die alte und die neue Zelle zum

selben BSC. Das Handover wird nur vom BSC durchgeführt, das MSC wird von dem BSC über das

Handover informiert.

• Handover innerhalb des Verwaltungsbereichs eines MSC (Intra-MSC-HO): Sowohl die alte als auch die

neue BTS werden von demselben MSC verwaltet, jedoch von unterschiedlichen BSCs.

• Handover zwischen zwei MSCs (Inter-MSC-HO): Die alte und die neue BTS werden von unterschiedli-

chen MSCs verwaltet.

Im Folgenden wird zunächst der Verlauf des Handovers allgemein beschrieben und schließlich anhand eines

konkreten Beispiels (Intra-MSC-Handover) verdeutlicht.

Die Aufforderung zum Handover: Der Base Station Controller (BSC) wertet die Ergebnisse seiner Feldstär-

kemessungen und die der MS aus. Stellt er fest, dass das Signal zu schwach wird und eine andere Zelle existiert,

die ein stärkeres Signal liefern kann, fordert der BSC die MS auf, ein Handover durchzuführen.

Zuteilung einer Verbindungsleitung: Unabhängig davon, ob es sich um ein Inter- oder ein Intra-MSC-HO

handelt, übernimmt das MSC die Steuerung (und die Zuteilung der Ressourcen), bei dem das Gespräch aufge-

baut wurde. Dieses MSC wird auch Anker-MSC genannt.

8

Kapitel 2.1: Subsysteme des GSM Netzes ___________________________________________________________________________ Veranlassung zur Ausführung des Handover: Solange, bis der Verkehrskanal in der neuen Zelle aufgebaut ist,

verwendet die MS den alten Kanal, wodurch kurzfristig zwei Kanäle geöffnet sind. Erst wenn die Verbindung

sicher steht, wird die MS aufgefordert, auf den anderen Kanal umzuschalten.

Der Abschluss des Handover: Die MS kann nun über den neuen Kanal kommunizieren. Der alte Kanal wird

wieder freigegeben. Die Aktualisierung der Daten (Location Update) im HLR ist nur nach einem LA-Wechsel

notwendig und erfolgt - von der MS ausgelöst - erst nach Beendigung der bestehenden Verbindung.

Bei dem Szenario in Abbildung 2 handelt es sich um ein Intra-MSC-HO. Der mobile Teilnehmer wechselt wäh-

rend einer bestehenden Gesprächsverbindung vom Zuständigkeitsbereich des BSC-A in den Zuständigkeitsbe-

reich des BSC-B. Das Sendesignal seiner anfänglich zuständigen BTS wird schwächer, und so erhält er die Auf-

forderung vom BSC-A ein Handover durchzuführen. Beide Base Station Controller (A und B) werden von dem-

selben MSC verwaltet.

MS

BSC-A MSC BSC-B

MS

A-HO-Request

A-HO-Request-Ack A-HO-Required

A-HO-Command RI-HO-Command

A-HO-Complete

A-Clear-Command

A-Clear-Complete

A-HO-Detect

RI-HO-Complete

RI-HO-Access

Abbildung 2: Intra-MSC-Handover (HO = Handover, RI = Radio Interface)

Wenn der Base Station Controller BSC-A erkennt, dass die in seinem Verwaltungsbereich befindliche MS eine

Handover Prozedur durchführen muss (es gibt 4 signifikante Messwerte), schickt er an sein zuständiges MSC ein

A-Handover-Required Kommando ab. Dieses Kommando enthält als Parameter eine Liste mit verfügbaren Zel-

len, zu denen die MS überführt werden kann. Das MSC gibt die Anweisung an den entsprechenden BSC-B (A-

HO-Request) weiter, der nun die nötigen Schritte einleiten muss, um der MS die Frequenzen zuzuteilen, und bes-

tätigt BSC-A im Anschluss mit einem A-HO-Request-Ack, dass dies erfolgt ist. Die entsprechende Aufforderung

an die MS kann abgesetzt werden. BSC-A schickt nach erfolgter Anweisung durch das MSC ein RI-HO-

Command an die MS. Dieses enthält eine Handover Nummer die von BSC-B mitgeliefert wurde. Anhand dieser

Nummer passt die MS ihre Frequenz an die neue Zelle an und schickt die Nummer (RI-HO-Access) an BSC-B.

Hat BSC-B die HO Nummern verglichen und festgestellt, dass es sich tatsächlich um die erwartete MS handelt,

teilt er dem MSC mit, dass eine aktive Handover Prozedur erkannt wurde (A-HO-Detect). Steht die Verbindung

von der MS zu BSC-B, schickt die MS dem BSC-B eine RI-HO-Complete Nachricht, der diese an das MSC wei-

9

Kapitel 2.1: Subsysteme des GSM Netzes ___________________________________________________________________________ terreicht. Nun fordert das MSC den BSC-A auf, den alten Verkehrskanal wieder freizugeben, der dies nach er-

folgter Durchführung bestätigt. Das Handover ist abgeschlossen.

Das doppelte Auftreten ein und derselben MS in der Grafik erscheint auf den ersten Blick etwas verwirrend,

symbolisiert aber den Wechsel der Kommunikationsbeziehungen. Zu Anfang befindet sich die MS noch in einer

Kommunikationsbeziehung zu BSC-A, später dann zu BSC-B.

Paging:

Beim Paging handelt es sich um den Vorgang, bei dem ein mobiler Teilnehmer ohne exakte Kenntnis seines ak-

tuellen Aufenthaltsorts erreicht werden soll. Wird ein Mobiles Endgerät z.B. Beispiel aus dem Festnetz heraus

adressiert, so muss das Netz zunächst erkennen, dass es bei der gewählten Nummer um ein Mobilfunknetz han-

delt. Dies geschieht anhand der Network Detection Number (NDC, z.B. 171 für D1-Netz). Der Anruf wird an

eine spezielle Übergangsvermittlungsstelle (GMSC, Gateway-MSC) weitergeleitet, die eine Verbindung zwi-

schen Festnetz und Mobilfunknetz herstellen kann. Das GMSC ermittelt anhand der MSISDN des gewünschten

Gesprächspartners das HLR, in dem dieser eingetragen ist. Im Datensatz dieses HLR befindet sich für diesen

Vorgang lediglich die Information, welches VLR zuletzt für den gewünschten Kommunikationspartner verant-

wortlich war. Das HLR fordert das VLR auf, sowohl die Roaming Number (MSRN) als auch die notwendigen

Routinginformationen zu ermitteln und zurückzuschicken. Die Informationen werden nun an das HLR und von

dort aus an das GMSC weitergeleitet. Im Folgenden baut das GMSC die Verbindung (Signalisierungs- und

Sprachverbindung) zu dem gewünschten Gesprächspartner bzw. zu dem für seinen Standort verantwortlichen

MSC Stück für Stück (link by link) auf. Das MSC signalisiert nun allen BSCs der Location Area, dass sie ein Pa-

ging durchführen sollen. Beim Paging selbst wird die TMSI (Temporary Mobile Station Subscriber Identity) o-

der ggf. die IMSI (International Mobile Station Subscriber Identity) über den Paging Channel (PCH) als Broad-

castsignal an alle in der LA eingebuchten MS gesendet. Die MS mit der gesendeten Nummer meldet sich dann

über den RACH (Random Access Channel) zurück, falls sie eingeschaltet ist. Der MS wird nun ein dedizierter

Kanal (Stand Alone Dedicated Channel, SDCCH) zugewiesen, über den zunächst die Authentisierung abgewi-

ckelt wird. Gilt die Identität der MS (genau genommen der Chipkarte) als gesichert, wird der dedizierte Steuer-

kanal wieder abgebaut und statt dessen ein Verkehrskanal (Traffic Channel, TCH) aufgebaut. Zuvor wurde dem

mobilen Benutzer ggf. noch eine neue TMSI zugewiesen, die er abspeichert und im weiteren Verlauf als Ken-

nung verwendet. Nach der Kanalumschaltung (von SDCCH auf TCH) wird das ankommende Gespräch an den

mobilen Empfänger weitergeleitet. Das mobile Endgerät klingelt. Nimmt der Benutzer das Gespräch an, d.h.

hebt er ab, so signalisiert das Endgerät dem zuständigen MSC, dass der Ruf angekommen ist. Das MSC gibt die-

se Information nun an das GMSC und dieses wiederum an das Festnetz weiter, so dass beim Anrufer das Frei-

zeichen ertönt.

Die Login-Prozedur am Beispiel des erstmaligen Einbuchens ins PLMN:

Der Benutzer hat ein neues Endgerät erworben, sowie einen neuen Kartenvertrag abgeschlossen. Der neue Kar-

tenvertrag wurde von dem Kartenherausgeber bereits im HLR registriert und der Benutzer schaltet sein Endgerät

nun erstmalig ein. Er gibt nach der entsprechenden Aufforderung seine PIN ein und hört nach einer Weile einen

Piepton, der ihm das erfolgreiche Einbuchen im Mobilfunk-Netz signalisiert. Auf seinem Display erscheint ggf.

eine Willkommensnachricht.

10

Kapitel 2.1: Subsysteme des GSM Netzes ___________________________________________________________________________ Unmittelbar nach dem Einschalten des Endgeräts baut es eine Verbindung zum Netz auf, um seinen aktuellen

Standort bekannt zu geben. Dabei schickt es seine IMSI und die aus dem Broadcastkanal ermittelte Location A-

rea Identity (LAI) über Zwischenstationen (BTS, BSC, MSC) an das für die Region zuständige VLR (Location

Update Request). Da im VLR noch keine Ortsinformationen (LA) bzgl. dieser Karte enthalten sind und im emp-

fangenen Location Update Request eine LA eingetragen ist, weiß das VLR, dass es sich um eine erstmalige Ein-

buchung handelt. Anderenfalls wäre es lediglich eine Anforderung an das VLR, die in ihm gespeicherten Ortsin-

formationen zu aktualisieren, also ein Location Update, bei dem jedoch nicht die IMSI, sondern die TMSI zur

Kennung verschickt wird.

Da es sich um die erstmalige Einbuchung handelt, fordert das VLR vom AC die Authentisierungsparameter an,

mit denen eine Überprüfung auf korrekte Funktionsweise und Echtheit der SIM Karte vorgenommen werden

kann. Außerdem ermöglichen erst diese Parameter eine Verschlüsselung von Nachrichten.

Das Endgerät erhält vom Netz (AC) eine Zufallszahl aus der es mit Hilfe der Algorithmen A3 und A8 eine unter-

schriebene Rückantwort an das Netz (zur Authentisierung) und einen Schlüssel KC zur Verschlüsselung der zu

übertragenden Daten generiert (Weiteres dazu in Kapitel 3.2). Ist die Authentisierung im Netz erfolgreich verlau-

fen, wird der relative Aufenthaltsort des Endgeräts (LAI, LAC) anhand der VLR-Nummer an das HLR weiterge-

leitet, das die Daten in seiner Datenbank einträgt. Anschließend erhält das VLR vom HLR/AC Informationen zu

den für diese Karte verfügbaren Dienste, trägt diese Daten in seiner Datenbank ein und bestätigt deren Empfang.

Das VLR meldet dem MSC, dass das Location Update durchgeführt wurde, aktiviert die Verschlüsselung und

übergibt dem MS seine (neue) TMSI. Nachdem das Endgerät den Empfang der TMSI bestätigt hat, wird die

Verbindung seitens des Netzes freigegeben: Ab diesem Moment ist das ME betriebsbereit.

2.2 Subsysteme von GPRS und UMTS Sowohl der Dienst General Packet Radio Services (GPRS) als auch Universal Mobile Telecommunication Sys-

tem (UMTS) unterscheiden sich grundlegend von GSM. Zwar sind alle drei Systeme für mobile Endgeräte kon-

zipiert, jedoch werden GPRS- und UMTS-Daten-Dienste im Gegensatz zu GSM weder verbindungsorientiert

übertragen noch nach Verbindungsminuten für geschaltete Kanäle abgerechnet: Sie werden paketorientiert über-

tragen und nach angefallenem Datenvolumen abgerechnet. Beide Techniken wurden entwickelt, um eine deut-

lich höhere Datenübertragungsrate als die 9,6 kbps von GSM zu ermöglichen und somit insbesondere eine Er-

weiterung der zur Zeit in GSM verfügbaren multimedialen Dienste umzusetzen. Während sich UMTS weitestge-

hend (s. Abbildung 4, S.15) einer neuen Netzinfrastruktur und neuer Funkfrequenzen bedient, verwendet GPRS

die Netzarchitektur und die Funkfrequenzen von GSM, benötigt jedoch einige zusätzliche Komponenten für die

dienstspezifischen Funktionen. GPRS kann in Hinblick auf UMTS als Übergangstechnik zur dritten Mobilfunk-

generation angesehen werden, wenn es ursprünglich auch nicht als solche konzipiert war.

GPRS: Bei GPRS wird dem Benutzer für Datendienste nicht wie bei GSM ein exklusiver Verkehrskanal zugewiesen,

sondern mehrere Kanäle parallel: Man spricht bei solch einem System von Kanalbündelung. Die Datenübertra-

gung findet paketorientiert statt, so dass mehreren Benutzern gleichzeitig dieselben Kanalbündel zugewiesen

werden können, auf denen sie dann ohne eine feste Verbindung zu einem speziellen Empfänger ihre Datenpakete

11

Kapitel 2.2: Subsysteme von GPRS und UMTS ________________________________________________________________ speichervermittelt verschicken und empfangen.

Je nach verwendetem Zeitmultiplexverfahren (synchron, statistisch), das festlegt, wann ein Benutzer seine Da-

tenpakete versenden darf, findet eine wesentlich bessere Auslastung der verfügbaren Bandbreite statt, da weniger

Leerlaufzeiten entstehen als bei einer festen Verbindung. Um solch ein System realisieren zu können, muss die

Netz-Infrastruktur um Paketfilter und Paketvermittlungsstellen erweitert werden (siehe Abb. 3).

Jeder BSC wird um eine Einheit erweitert, die Datenpakete von Sprachdaten trennen und weiterreichen kann.

Eine solche Paketsteuerungseinheit wird PCU (Packet Control Unit) genannt. Sie „erweitert die Funkbasissteue-

rung (BSC) hin zur GPRS-Funktionalität und stellt die Sicherungsschicht auf der Luftschnittstelle bereit“ (vgl.

[a]).

Die Vermittlung der Pakete übernimmt der GSN (GPRS Support Node). Der GSN besteht aus zwei Untereinhei-

ten, dem SGSN (Serving GSN) und dem GGSN (Gateway GSN). Der SGSN ist verantwortlich für Adressmana-

gement (Mobility Management), Sessionmanagement, Authentisierung und Verschlüsselung sowie die Verbin-

dung zu HLR, VLR und MSC. Bei GPRS wird jedem Benutzer eine temporäre Adresse zugeordnet (vgl. [b]) an-

hand derer der SGSN jeden Teilnehmer eindeutig identifizieren kann. Der SGSN betrachtet die dynamische Ad-

resse als Netz- bzw. IP-Adresse und führt den Regeln von IP-Netzen folgend die Adressierung durch.

Der GGSN übernimmt die Gateway Funktionen und ist somit die Schnittstelle zwischen den am Internet ange-

schlossenen RADIUS-Servern und dem Mobilfunknetz. Er verwaltet die IP-Adressen aller Teilnehmer, die durch

das GPRS Netz bedient werden. Bei RADIUS (Remote Authentification Dial-In User) handelt es sich um ein

„Client/Server basiertes Sicherheits-Protokoll zur Benutzerauthentifizierung und zur Kontrolle der Netzzugangs-

berechtigung. RADIUS arbeitet mit Challenge-Response-Technik und unterstützt die zentrale Administration

von Benutzerdaten wie Benutzerkennung, Passwörter, Rufnummern, Zugriffsrechte und auch Account-Daten

und besteht aus einem Accounting- und Authentisierungsprotokoll.“ (vgl. [d]).

IP-Network

PSTN

.......

.......

Packet Switched GPRS nodes

Mobile Station

Radio Access Network

PCU BSC

BTS

BTS

BTS Base Transceiver StationBSC Base Station ControllGSN GPRS Support Node HLR Home Location RegiPCU Packet Control Unit SMS- Short Message Service CenVLR Visitor Location Register

BTS Base Transceiver Station BSC Base Station Controller GSN GPRS Support Node HLR Home Location Register PCU Packet Control Unit SMS-SC Short Message Service Center VLR Visitor Location Register PSTN Public Switched Telephone Netw.

er

ster

SC ter

BTS

BTS

GGSN SGSN

SMS-SC

Gateway MSC

HLR Circuit switched

Visited MSC/VLR

GSM/GPRS Core Network

Abbildung 3: Veränderungen der Netzinfrastruktur auf dem Weg von GSM zu GPRS (rot)

RADIUS wird bereits seit WAP zur Authentisierung eingesetzt und ist in RFC 2058 und 2059 spezifiziert.

Zusätzlich zur Einführung der Einheiten PCU und GSN werden bei GPRS in Ballungsgebieten die Zellgrößen

verkleinert. Während bei GPRS alle Datendienste über das an IP angelehnte, paketvermittelte System abgewi-

ckelt werden, wird die reine Mobiltelefonie nach wie vor über die bekannten GSM-Systeme kanalvermittelt rea-

lisiert. Die einem Benutzer zugänglichen IP-Netze werden über ihren jeweiligen APN (Access Point Name) ad-

ressiert.

12

Kapitel 2.2: Subsysteme von GPRS und UMTS ________________________________________________________________ Die Datenübertragungsraten bei GPRS sind je nach verwendetem Codierungsverfahren CS1-CS4 je Kanal von

(CS1) 9,05 bis (CS4) 21,4 kbps spezifiziert. Bei der Kanalbündelung werden maximal 8 Kanäle gleichzeitig

verwendet, so dass dem Benutzer im Idealfall eine Datenübertragungsrate von 171,2 kbps zur Verfügung steht.

Die Netzbetreiber erwarten eine mittlere Datenübertragungsrate bei einer Schaltung von 4 GSM-TDM (Time

Division Multiplex) Kanälen von 58 kbps (vgl.[e]). Mit höheren Übertragungsraten wird gleichzeitig der Auf-

wand für die Fehlerkorrektur und somit die Datenqualität verringert. Daher müssen Übertragungsrate und Über-

tragungsqualität gegeneinander abgewogen werden.

Für GPRS sind sowohl Punkt-zu-Punkt-Dienste (PP) als auch Punkt-zu-Mehrpunkt-Dienste (PMP) vorgesehen.

Während Punkt-zu-Punkt-Verbindungen der klassischen Telefonie oder FTP Verbindungen entsprechen, kann

der Benutzer bei Punkt-zu-Mehrpunkt-Verbindungen nicht nur multicasten sondern auch geschlossene Benut-

zergruppen (Group call) adressieren. In jedem Fall muss er sich für die Nutzung der jeweiligen Dienste beim

Netzbetreiber bzw. Dienstanbieter anmelden.

Die entsprechenden GPRS Endgeräte gibt es auf dem Markt in zwei unterschiedlichen Klassen: Klasse A ermög-

licht das gleichzeitige Senden bzw. Empfangen von Daten und die Nutzung von GSM-Telefondiensten, Geräte

der Klasse B unterstützen nur jeweils einen Dienst zu einem bestimmten Zeitpunkt: Die Verbindung zu einem

Dienst (Daten oder Telefonie) muss getrennt werden, bevor ein Dienst des anderen Typs genutzt werden kann.

Besondere Anwendungen für GPRS-Daten-Dienste sind Bildtelefonie, Web Browsing, Streaming Audio, Unter-

stützung von Verkehrsleitsystemen, u.a.

UMTS:

Die Hauptmotivation zur Entwicklung von UMTS war die Erkenntnis, dass GPRS den allgemeinen Bedarf des

Kunden an mobiler Bandbreite zur Nutzung multimedialer Dienste nach wie vor nicht zufrieden stellen kann.

UMTS soll primär eine Erweiterung der verfügbaren Bandbreite ermöglichen, um eine Technik zu realisieren,

die auch künftigen Anforderungen standhalten und mit der insbesondere eine bestimmte Dienstgüte (QoS) garan-

tiert werden kann. Dies ist letztlich eine Grundvoraussetzung für ein flächendeckendes Umsetzen von Voice over

IP. Um die Bandbreite über die Luftschnittstelle weiter vergrößern zu können, muss zum einen das Frequenz-

spektrum erhöht und zum anderen die Zellgröße verringert werden. Durch die Entwicklung der grundlegend

neuen Technologie wurde von der Regulierungsbehörde eine Freigabe weiterer Frequenzen erwirkt.

Weltweit wurden über 100 UMTS Lizenzen vergeben, die teilweise versteigert aber andernorts auch ohne weite-

re Vergütung ausgegeben wurden. In Deutschland wurden 6 (Doppel-) Lizenzen zu den weltweit höchsten Kon-

ditionen versteigert (vgl. UMTS Forum, Licensing, [f]) und brachten insgesamt pro 10 MHz (5 MHz je Up- und

Downlink) 4,270 Milliarden Euro ein. Bei einer Pro-Einwohner Betrachtung waren die 5 englischen Lizenzen

jedoch um 7,90 € teurer als die deutschen Lizenzen.

Mit dem Erwerb der Lizenzen übernahmen die Auktionsgewinner gleichzeitig eine Versorgungspflicht, nach der

bis Ende 2003 25 % und bis Ende 2005 50 % der Bevölkerung mit den für UMTS notwendigen Frequenzen ver-

sorgt sein müssen. In Bezug auf die Gesamtfläche der Bundesrepublik Deutschland macht das letztlich nur 3-7%

aus. Dünn besiedelte Teile von Deutschland werden wohl auch in Zukunft nicht mit UMTS versorgt sein. Aus

diesem Grund werden alle UMTS-Endgeräte auch GSM (GPRS) als Fallback-Technik unterstützen (vgl. [g]).

13

Kapitel 2.2: Subsysteme von GPRS und UMTS ________________________________________________________________ Modulationsverfahren, Multiplexverfahren:

Dem Dienst UMTS (insbesondere UTRAN, S.15) stehen insgesamt 2*60 MHz zur Verfügung (jeweils Upstream

und Downstream). In Relation dazu nimmt das Frequenzspektrum, das GSM zur Verfügung steht nicht einmal

die Hälfte des Frequenzspektrums ein, nämlich 25 MHz Upstream und 25 MHz Downstream.

Im Gegensatz zu GSM wird bei UMTS kein aus TDM und FDM kombiniertes Verfahren zur Bildung der Funk-

kanäle verwendet, sondern WCDMA (Codemultiplex, W:= Wide Band) eingesetzt. Bei diesem Verfahren wird

jedem Benutzer ein individuelles Codewort zugewiesen, das linear unabhängig von allen anderen ausgegeben

Codewörtern ist. Mit diesem Spreizwort werden die zu übertragenden Einzelbits aufgespreizt. Alle zu übertra-

genden gespreizten Bits werden übereinandergelegt (mit der XOR Funktion addiert) und anhand der jeweiligen

Spreizfolgen auf Empfängerseite wieder subtrahiert, was nur aufgrund der linearen Unabhängigkeit eindeutig

erfolgen kann. Durch eine Senkung der Übertragungsraten kann bei UMTS im Gegensatz zu GSM einer Netz-

überlastung dynamisch entgegengewirkt werden. Durch die minimal benötigten 9,6 kbps für Sprachdienste ist

die Anzahl der Teilnehmer bei GSM auf die Anzahl der verfügbaren Kanäle starr begrenzt.

Als Modulationsverfahren werden bei UMTS FDD (Frequency Division Duplex) und TDD (Time Division

Duplex) zur Generierung der Duplexkanäle verwendet und zusätzlich für die Überbrückung der ersten Jahre für

die Sprachübertragung das TDMA Verfahren, das zur Zeit bei GSM eingesetzt wird.

Zellgrößen und Übertragungsraten:

Auch bei UMTS handelt es sich um ein zellulares System. Im Gegensatz zu GSM werden die Zellen bei UMTS

jedoch nicht (relativ) gleich groß sein, sondern es wurden von vorne herein vier unterschiedliche Zellgrößen mit

unterschiedlichen Übertragungsraten definiert (je kleiner die Zelle, desto größer die Übertragungsrate):

• Zone 1: In Building - Pico Cell - bis maximal 10 Meter Reichweite, niedrige Fortbewegungsge-

schwindigkeit <10km/h, erwartete Datenübertragung von bis zu 2 Mbps

• Zone 2: Urban - Micro Cell – 50 bis maximal 300 Meter Reichweite, mittlere Fortbewegungsge-

schwindigkeit >10km/h, typische Übertragungsraten bis zu 384 kbps

• Zone 3: Suburban - Macro Cell – 350 m bis 20 Km Reichweite, hohe Fortbewegungsgeschwindigkeit,

wie sie mit motorisierten Fahrzeugen erreicht wird und maximale Übertragungsraten von 144 kbps

• Zone 4: Global - World Cell - Diese Zone ist z.Z. nur rein theoretischer Natur. Es ist (Fa. Siemens)

geplant, diese Zone durch Satellitenkommunikation zur realisieren.

Zur Adressierung der Teilnehmer im UMTS Umfeld wurden in Deutschland von der Regulierungsbehörde be-

reits die 015 Nummern freigegeben. Im Rahmen des QoS werden die zur Verfügung stehenden Übertragungsra-

ten vertragsabhängig garantiert werden. Laut www.umts-report.com [h] sind drei Vertragsmodelle geplant:

• Gold User: maximale Bitrate von 384 kbps, garantierte Bitrate von 144 kbps und Vorzugsbehandlung

bei der Vergabe von Kanälen

• Silver User: maximale Bitrate von 144 kbps, garantierte Bitrate von 64 kbps

• Brown User*1: maximale Bitrate von 144 kbps, und garantierte Bitrate von 16 kbps

Das ganze System wird outband implementiert, d.h. die Kanäle zur Netzsteuerung und die Transportkanäle wer

*1 möglicherweise hat sich der Autor dort verschrieben und es sollte „Bronze User“ lauten

14

Kapitel 2.2: Subsysteme von GPRS und UMTS ________________________________________________________________ den wie bereits bei ISDN und GSM realisiert, getrennt sein. Als Verbindungspunkte dieser zwei Ebenen werden

sogenannte Mediagateways fungieren. Das UMTS Netz kennt sowohl die kanalvermittelte, als auch die paket-

vermittelte Datenübertragung. Eine ausschließliche Implementierung von Gesprächsverbindungen auf der Ebene

von paketvermittelter Datenübertragung (Voice over IP) ist vor der generellen Einführung von UMTS-Phase2

(und IPv6) kaum zu erwarten. Das Langzeitziel von UMTS ist die Verwirklichung eines All-IP-Netzes.

Netzarchitektur:

Anstelle des Funkteilsystems BSS im GSM wird in UMTS das System UTRAN (UMTS Terrestrial Radio Ac-

cess Network) als Funkschnittstelle eingesetzt (vgl. [g]). UTRAN setzt sich aus zwei Funktionseinheiten zu-

sammen, dem Node B und dem Radio Network Controller (RNC), die jeweils in ihrer Funktion den GSM-

Pendants BTS und BSC entsprechen. Ein wesentlicher Unterschied zur GSM-Architektur ist die Verbindung der

RNCs untereinander (BSCs sind im GSM nicht miteinander verbunden). Der Vorteil dieser Vollverkabelung be-

steht darin, dass das Handover bei UMTS allein vom UTRAN durchgeführt werden kann, während beim GSM

noch das MSC involviert werden muss. Ein Node B ist in der Lage eine oder auch mehrere Zellen zu versorgen,

und ein RNC verwaltet mehrere Node B. In der ersten implementierten Phase von UMTS werden voraussichtlich

immer 3 Zellen von einem Node B verwaltet, die Zellen werden auch als Sektoren bezeichnet, wobei jeder dieser

Sektoren über eine individuelle Zellen-Identifikationsnummer verfügt. Zur Sicherung der Übertragungsraten

über die Funkschnittstelle UTRAN hinaus sind die Node B direkt mit ATM-Netzen verbunden. Um trotzdem ei-

nen Netzübergang zu den MSCs realisieren zu können, bedarf es einer weiteren Schnittstelle, die einerseits das

WCDMA Verfahren von UTRAN unterstützt, andererseits aber auch das Datenformat von der ATM-Welt (A-

synchronous Transfer Mode) auf die PCM30-Welt des MSC´s übersetzt (bei Pulse Code Modulation werden 30

Nutzkanäle durch Zeitmultiplex realisiert). Diese Einheit wird TRAU (Transcoder and Rate Adaption Unit) ge-

nannt und dient als Netzübergang vom Backbone zum UTRAN. Da die Node B direkt (mit Hilfe von TRAU) an

ATM-Netze angeschlossen werden können, wird in UMTS keine PCU benötigt. Die RNC können direkt mit dem

SGSN vom Core Network (Backbone) verknüpft werden. Während UMTS Phase 1 werden nach wie vor zwei

separate Netze für die mobile Telefonie und Datendienste parallel betrieben.

Abbildung 4 stellt schematisch ein UMTS Netz der ersten Generation dar:

RNC2 Node B2

RNC1 Node B1

UE

UE

Backbone

Packet Domain

X 25 IP

GPRS Backb-one SGSN SGSN

TRAU PSTN

HLR/AC

VLR

MSC

Circuit Domain

Abbildung 4: Das UMTS Netz der ersten Generation, vgl. [h], aus Präzisionsgründen modifiziert

15

Kapitel 2.2: Subsysteme von GPRS und UMTS ________________________________________________________________ Soft Handover:

Da bei UMTS ein CDMA (Code Division Multiple Access) Verfahren verwendet wird, ergibt sich in den Über-

lappungsbereichen zwischen den ohnehin schon kleineren Zellen ein größeres Störpotential und somit eine we-

sentlich höhere Fehleranfälligkeit, denn mehrere Endgeräte verwenden dieselbe Frequenz und unterscheiden sich

nur durch ihre individuellen Codewörter, mit denen ihre Daten nach dem Empfangen wieder voneinander ge-

trennt werden. Um zu vermeiden, dass die erforderliche Sendeleistung der Mobilstationen aufgrund der erhöhten

Fehlerrate immer weiter ansteigt, wurde ein neues Handover-System eingeführt, das Soft-Handover. Befindet

sich eine MS im Grenzbereich zwischen zwei Zellen, und damit relativ weit entfernt von dem eigenen Node B,

so erhöht sie nicht die Sendeleistung, sondern eröffnet einen zusätzlichen Kanal zum benachbarten Node B und

sendet die gleichen Informationen an beide Node B. Die Node B übertragen ihre jeweiligen Informationen nun

an den RNC, der die (ggf. vereinzelt gestörten) Informationen dann wieder zusammensetzt (Combining) und ent-

sprechend als einzelnes korrektes Datum weiterleitet. Umgekehrt sendet der RNC auch die gleichen Informatio-

nen an beide Node B (Splitting)*1, die sie dann an das Endgerät weiterreichen. Da bei einem Überschreiten der

Zellgrenze bereits ein Funkkanal zum Node B der anderen Zelle aufgebaut wurde, muss der Kanal der alten Zel-

le nur noch abgebaut werden. Für das Soft-Handover gibt es drei unterschiedliche Szenarien:

• Softer Handover: Beide Zellen gehören zum gleichen Node B. Der Node B führt das Combining und

Splitting durch.

• Intra-RNC Soft-Handover: Die Zellen gehören zu unterschiedlichen Node B, das Soft-Handover wird

vom verantwortlichen RNC durchgeführt.

• Inter RNC Soft-Handover: Der eine RNC, Serving RNC (SRNC) genannt übernimmt Splitting und

Combining, während der andere RNC, Drift RNC (DRNC) genannt, die Informationen an den SRNC

weiterleitet und die an ihm angeschlossenen Node B verwaltet.

2.3 Kontaktbehaftete Chipkarten In diesem Unterkapitel werden die in ISO/IEC 7816 allgemein spezifizierten Funktionen von (kontaktbehafteten)

Chipkarten beschrieben, aber nicht die speziellen Anforderungen, die laut 3GPP-Standard für das SIM festgelegt

wurden. Diese werden in Kapitel 3ff unter Bezugnahme auf die einzelnen GSM-Phasen ausführlich behandelt.

Darüber hinaus gehende Informationen können den Quellen [12], [13], und [B] entnommen werden.

Physikalische Charakteristika:

Speicherchipkarten bestehen physikalisch betrachtet aus einem permanenten (EEPROM) Datenspeicher, einer

logischen Einheit, die Kommandos abarbeiten und Verschlüsselungen durchführen kann, sowie einer genormten

Schnittstelle zum Terminal. Je nach technischer Ausstattung der Chipkarte gibt es zusätzlich einen flüchtigen

Speicher (RAM), den ein (dann vorhandener) Prozessor auf der Chipkarte als Arbeitsspeicher nutzt. Kontaktbe-

haftete Chipkarten kommen in zwei unterschiedlichen Bauarten vor, dem Plug-In Format und dem ID1 Format.

Das ID1 Format ist das Standardformat einer jeden Kreditkarte, während das Plug-In Format wesentlich kleiner

*1 Der Begriff „Splitting“ erscheint in diesem Zusammenhang verwirrend, „Double-ing“ wäre passender gewe-sen, da die Daten tatsächlich verdoppelt und jeweils an separate Node-B geschickt werden.

16

Kapitel 2.3: Kontaktbehaftete Chipkarten ________________________________________________________________ ist und sich auf die Größe der funktionalen Hardware beschränkt (Kontakte, Prozessor, Speicher, Leitungen).

Kontaktbehaftete Chipkarten besitzen 8 Kontakte C1 – C8, von denen 2 Kontakte nicht notwendig dem Terminal

zur Verfügung stehen müssen (u.a. die Programmierschnittstelle). Um ein falsches Einlegen der Plug-In-Karte in

das mobile Endgerät zu vermeiden, ist die linke obere Ecke auf eine Kantenlänge von 3 mm abzusetzen.

Die logische Dateistruktur:

Es wurden mehrere Protokolle definiert (ISO/IEC 7816-3), nach denen die Kommunikation zwischen Chipkarte

und Terminal realisiert wird. Zur Zeit gebräuchlich sind die Protokolle T=0 und T=1; in beiden Fällen wird die

Chipkarte als Slave definiert, und das Terminal hat die Rolle des Masters. Entsprechend kann die Chipkarte von

sich aus keine Kommandos an den Master absetzen, sondern der Master muss jegliche Aktion der Chipkarte an-

stoßen. Der wesentliche Unterschied zwischen T=0 und T=1 ist die Form der Datenübertragung: Bei T=0 werden

die Daten zeichenweise übertragen, bei T=1 blockweise.

Es gibt auf jeder Chipkarte eine vorgeschriebene Datenstruktur. Das erste Verzeichnis, das vom Terminal ange-

sprochen wird und immer vorhanden sein muss, ist das Master File (MF). Vom Master File aus können alle dar-

unter liegenden Files adressiert werden. Neben dem Masterfile gibt es noch Dedicated Files (DF), die wie das

MF auch Containerstrukturen sind, also Datenfiles oder wiederum Verzeichnisse enthalten. Die eigentlichen Da-

tenfiles der Chipkarte sind die Elementary Files (EF), die entweder direkt dem Masterfile oder einem Dedicated

File untergeordnet sind. Die Verzeichnisse sind so organisiert, dass eine direkte Adressierung immer nur von ei-

ner Ebene bis zur nächsten möglich ist. Ein Dedicated File kennt lediglich die Verzeichnisse und Dateien, die

ihm direkt unter- oder übergeordnet sind, dann die Verzeichnisse und Dateien, die sich auf gleicher Ebene (und

unter derselben Wurzel) befinden, und das Master File. Auf diese Weise ist eine eindeutige Adressierung aller

vorhandenen Files gewährleistet.

DF 1 DF 2

DF 4

EF 6

EF 4

EF 5

EF 3

EF 1

EF 2 DF 3

DF 5

Master File

EF 7 EF 8

Abbildung 5: Baumstruktur zur Erreichbarkeit von Files

Je nachdem, an welcher Stelle der Baumstruktur man sich gerade befindet, muss ein Backtracking durchgeführt

werden, um einen anderen Ast erreichen zu können. Eine direkte Adressierung von Files, die nicht nach obigen

Regeln erreichbar sind, ist nicht vorgesehen.

17

Kapitel 2.3: Kontaktbehaftete Chipkarten ________________________________________________________________ Jedes File (Daten oder Verzeichnis) auf einer Chipkarte hat eine Identifikationsnummer, über die es in Verbin-

dung mit seinem Pfad referenziert werden kann. Diese Nummern sind nur innerhalb der einem File direkt unter-

geordneten Files eindeutig. Es kann daher sein, dass die File-IDs zweier EFs, die unterschiedlichen DFs zuge-

ordnet sind, identisch sind. Die Identifikationsnummern werden in dem Moment zugewiesen, in dem ein File er-

zeugt wird.

Elementary Files gibt es in drei unterschiedlichen Formaten (vgl. dazu [15], [12], [B]):

• Transparent EF: Ein Transparent EF besteht aus einem Header und einem Body. Wenn etwas in ei-

nem solchen File geändert oder gelesen werden soll, muss die relative Adresse (Offset) des zu ändern-

den Datums angegeben werden, die aus der Startposition (in Bytes) und der Anzahl der zu lesenden o-

der zu verändernden Bytes besteht. Das erste Byte eines jeden Transparent EF hat die relative Adresse

’00 00’. Die Gesamtlänge des Bodys eines Transparent EF wird im Header festgehalten.

• Linear Fixed EF: Ein Linear Fixed EF besteht aus einem Header gefolgt von einer Anzahl von Re-

cords, die alle fester Länge sind. Der erste Record in der Liste trägt die Nummer 1. Der Header des Li-

near Fixed EF referenziert die Records anhand des Produkts aus ihrer Nummer und Länge. Es gibt di-

verse Methoden, Records auszulesen und zu verändern: Adressierung mit der Record Nummer, unter

Verwendung der NEXT und PREVIOUS Methoden, mit linearen Suchmethoden beginnend am Anfang

mit NEXT, am Ende mit PREVIOUS, bzw. unter Verwendung beider Methoden, wenn sich der Zeiger

bereits an einer anderen Stelle als am Anfang oder Ende befindet.

• Cyclic EF: Zyklische EFs werden insbesondere dann verwendet, wenn fortlaufend anfallende Informa-

tionen gespeichert werden sollen. Wenn die Kapazität des zyklischen EFs ausgelastet ist, wird immer

das älteste Datum (Record) überschrieben. Sowohl die Anzahl der Records als auch ihre Länge muss

fest vorgegeben sein. Der jüngste und der älteste Record sind derart miteinander verknüpft, dass der

jüngste Eintrag als Folgeeintrag zum ältesten angesehen wird und umgekehrt. Der zuletzt geschriebene

Eintrag, und damit der Jüngste, trägt immer die Nummer Eins. Um neue Daten einzutragen kann nur

das PREVIOUS Kommando verwendet werden. Ein Zugriff auf die einzelnen Records kann allerdings

mit NEXT, PREVIOUS, CURRENT und der absoluten Nummer des Eintrages erfolgen.

Nachdem das Terminal nach dem Einführen der Chipkarte das ATR (Answer to Reset) durchgeführt hat, wird

zunächst einmal das MF auf der Chipkarte angesprochen und ist somit das Current Directory. Wenn con diesem

Punkt aus auf ein DF gewechselt wird, so wird dieses zum Current Directory und damit zum Wurzelverzeichnis

des aktuellen Astes. In der Regel steht für jedes EF ein gemeinsamer Satz von Anweisungen (SELECT, PRE-

VIOUS, CURRENT, NEXT, etc.) zur Verfügung. Es ist es auch möglich, dass es anwendungsspezifische

Kommandos gibt, die nur auf bestimmte Dateien angewandt werden können.

Struktur der Application Protocol Data Units (APDUs)

Aus der Sicht des OSI Modells betrachtet, wurden bei der Kommunikation zwischen Chipkarte und Terminal nur

drei Schichten implementiert. Die Bitübertragungsschicht (Layer 1), auf der die Daten binär übermittelt werden,

der Data Link Layer (Leitungsschicht, Layer 2), auf der die TPDUs (Transport Protocol Data Units) übertragen

werden, und schließlich die Anwendungsschicht (Layer 7), auf der die APDUs übertragen werden.

18

Kapitel 2.3: Kontaktbehaftete Chipkarten ________________________________________________________________ APDUs werden weiter unterteilt in Command APDUs und Response APDUs, je nachdem, wo der Ursprung der

Nachricht liegt. Die APDUs sind unabhängig vom Übertragungsprotokoll aufgebaut und werden von der unteren

Schicht ohne Veränderung (des Schicht-3-Headers) uninterpretiert in kleinere versandfähige und durchnumme-

rierte Einheiten (TPDUs) aufgeteilt und weitergeleitet. Command APDUs bestehen aus einem Header und einem

Body. Response APDUs hingegen bestehen aus einem optionalen Body und einem Trailer. Der Trailer setzt sich

aus zwei Statusworten (HEX) zusammen (siehe Abb. 11), die dem Terminal signalisieren, in welchem Zustand

sich die Karte zur Zeit befindet, z.B. ob bei der Abarbeitung einer Anweisung Fehler aufgetreten sind oder die

Chipkarte weitere Daten erwartet (vgl. Kapitel 4).

Der Header einer Command APDU (vgl. Abb. 6) besteht aus 4 einzelnen Einheiten, dem Class Byte CLA, das

zumindest zur Zeit noch Anwendungstypen klassifiziert (vgl. [B] S. 378 oben), dem Instruction Byte INS, mit

dem die eigentlichen Kommandos codiert werden, und zwei Parametern (je ein Byte) P1 und P2, mit denen in

der Regel die Kommandos näher spezifiziert werden. Der Body wird aus einem zwischen zwei Längenfeldern

eingeschlossenen Datenfeld gebildet. Das Längenfeld Le, „Length expected“, bezeichnet die vom ME erwartete

Anzahl von Bytes in der Rückantwort der Chipkarte, und Lc, „Length command“, bezeichnet die Länge des Da-

tenfeldes, das an die Karte geschickt wird. Die genannten Teile des Body sind bis auf die Längenangabe le optio-

nal. Eine einzelne Command APDU enthält genau ein vollständiges Kommando. Die Response APDU der Chip-

karte kann auf die beiden Statusworte SW1 und SW2 beschränkt werden, wenn die vorangegangene Anweisung

keine Rückgabeantwort verlangt oder angeforderte Daten nicht verfügbar sind. Werden diese beiden Statusworte

auf z.B. ‚90 00’ gesetzt, so bedeutet dies für das Terminal, dass die vorangegangene Anweisung erfolgreich ab-

gearbeitet wurde.

Body (obligatorisch) Body (optional) Header (obligatorisch)

Command APDU

CLA INS P1 P2 Lc- Feld Datenfeld Le- Feld

Body (optional) Trailer (obligatorisch)

Datenfeld SW1 SW2

Response APDU

Abbildung 6: Der Aufbau von Command und Response APDU

Zum Abschluss dieses Kapitels wird noch kurz das Kommunikationsschema zwischen Terminal und Chipkarte

in Form eines Ablaufdiagramms dargestellt. Im Rahmen des Answer to Reset Ablaufs (ATR) einigen sich Ter-

minal und Chipkarte zunächst auf ein gemeinsames Protokoll (PTS, Protocol Type Selection). Ebenso wird beim

ATR ausgehandelt, ob die Daten in direct convention (+5V, bzw.+3V entsprechen der logischen 1) oder inverse

convention (umgekehrt) übertragen werden. In Abbildung 7 wird ein Szenario dargestellt, bei dem nach erfolg-

tem ATR zuerst das Protokoll ausgehandelt und am dann ein Kommando mit zugehöriger Antwort abgearbeitet

werden. Die PTS wird eingeleitet, wenn im Startzustand vom Terminal ein Protokoll verwendet wird, das die

Chipkarte nicht versteht oder umgekehrt. Nach erfolgtem Warmstart fährt die Karte mit dem entsprechend ande-

ren Protokoll (T=0, T=1) hoch.

19

Kapitel 2.3: Kontaktbehaftete Chipkarten ________________________________________________________________

Nein

Ja PTS notwendig?

Antwort 1

Command

PTS Antwort

PTS Anfrage

ATR

Reset (Kaltstart der Karte)

Terminal Chipkarte

Abbildung 7: ATR mit PTS und einem Command/Answer Paar, vgl. [B], S. 324

Ein entsprechender Zustandsautomat bzgl. des Kommunikationsablaufs bei T=0 (ohne Fehlerbehandlung) ist in

[B], Seite 358 dargestellt.

2.4 Mobile Equipment Mit Mobile Equipment (ME, dt.: Mobiles Endgerät) bezeichnet man das reine Endgerät, also die Mobilstation

(MS) ohne die SIM-Karte. Stellenweise wird es in den Spezifikationen auch als Mobile Terminal (MT) bezeich-

net. Die Bezeichnung ME überwiegt in den Spezifikationen, und so soll sie hier verwendet werden. In diesem

Kapitel werden die für diese Arbeit relevanten Funktionen des ME beschrieben.

Auf dem Markt sind Mobile Endgeräte erhältlich, die keine weiteren Funktionen als die reine Telefonie und den

SMS-Versand bereitstellen. Zugleich gibt es aber auch Geräte, die vollständige kleine Personal Computer mit

486er Prozessoren, 256 MB Festplatte und relativ großem Display enthalten. Mit ihnen werden nicht nur zusätz-

lich zu den mobilen Diensten Standard-Textverarbeitung und Tabellenkalkulation, sowie Terminplaner, Adress-

buch, etc. angeboten (wie bei einem vergleichbarer Handheld Computer), sondern zusätzlich ist ein internetfähi-

ger Browser enthalten, der über die Luftschnittstelle WWW-Seiten downloaden und in Farbe darstellen kann.

Der zuletzt erwähnte Typ von Endgeräten wird in dieser Arbeit nicht weiter berücksichtigt, da er nicht repräsen-

tativ für den Standard ist. In dieser Arbeit wird nicht weiter auf die unterschiedlichen Arten von Endgeräten ein-

gegangen, sondern der Standard, also die spezifizierten Mindestanforderungen, beschrieben.

Zunächst einmal enthält das ME die Benutzerschnittstelle. Der Benutzer kann z.B. mittels der auf dem Terminal

befindlichen Tastatur, Befehle eingeben und empfängt Antworten in Form von Geräuschen oder grafischen Aus-

gaben auf dem Display des Endgeräts. Des Weiteren dient das Mobile Endgerät auch als Datenspeicher.

Im Gegensatz zur SIM-Karte werden in dem Terminal keinerlei (auf GSM bezogene) sensible Daten wie z.B.

persönliche Nachrichten oder Benutzerdaten gespeichert, wohl aber aus dem Netz heruntergeladene Klingeltöne,

Logos und Spiele. Der WAP-Browser ist ebenso im Endgerät integriert, wie auch die Zugangsdaten für WAP,

evtl. abgespeicherte Passworte für eMail Clients und gespeicherte eMail-Adressen. Diese Inkonsequenz (es sind

teilweise persönliche Daten) resultiert daraus, dass bei der Einführung von WAP keine neuen SIM-Karten ver-

fügbar waren, wie sie für eine Speicherung dieser Daten auf der Karte erforderlich gewesen wären. Das ME ver-

einigt in sich drei Schnittstellen : Zum Netz, dem Benutzer und der SIM-Karte. Es muss also nicht nur in der

20

Kapitel 2.4: Mobile Equipment ________________________________________________________________ Lage sein, die Befehle des Benutzers zu interpretieren und auszuführen, sondern sie auch in der richtigen Form

der SIM-Karte bzw. dem Netz zu übergeben sowie auf deren Daten zuzugreifen und sie zu verstehen. Seit der

Einführung von SAT muss es zusätzlich auch noch regelmäßig die SIM-Karte befragen, ob sie evtl. Informatio-

nen bereit gestellt hat, die es abholen und weiterverarbeiten muss. Dieser Vorgang wird in Kapitel 4 noch im De-

tail behandelt. Die Benutzerschnittstelle (MMI, s.u.) und das ME werden in den Spezifikationen gemäß ihren

Schnittstellen zu Mensch oder Technik (SIM, Netz) zwar funktional unterschieden aber durch ein und dasselbe

Gerät realisiert.

Die Liste der funktionalen Mindestanforderungen an die Endgeräte änderte sich im Laufe der einzelnen Phasen

von GSM teilweise beträchtlich, was in Tabelle 1 verdeutlicht wird. In der Tabelle werden alle funktionalen An-

forderungen an die Endgeräte, wie sie in [3],[4] und [5] definiert wurden, gegenübergestellt.

Anmerkungen zur folgenden Tabelle 1 (S.22):

*1 Sofern eine direkte Schnittstelle zum Menschen besteht, ist das Feature obligatorisch. Es wäre aber möglich,

dass das ME von einem externen Eingabegerät gesteuert wird.

*2 Es ist nicht erforderlich, eine Tastatur zu haben, aber eine Möglichkeit der Eingabe muss bestehen.

*3 Wenn ein Endgerät Ressourcen für Autocalling bereit hält oder ein externes Gerät angeschlossen werden

kann, das ein Autocalling ermöglicht, muss es auch vom Endgerät aus aktivierbar sein.

*4 Es besteht zwar die Verpflichtung, sowohl den Empfang als auch die Speicherung von Kurznachrichten

(SMS) zu unterstützen, jedoch muss eine Kurznachricht nicht auf dem Display ausgegeben werden.

*5 nur in Verbindung mit Sprachdiensten

*6 gilt nur für Geräte, die GPRS unterstützen

M: Mandatory, obligatorisch

O: Optional

Gelber (oberer) Bereich der Tabelle: Basic MS Features, Basisdienste

Weißer (unterer) Bereich der Tabelle: Additional MS Features, zusätzliche Dienste

Die orange gefärbten Felder symbolisieren einen direkten Wechsel (von einer Phase zur folgenden) in der Be-

deutung eines Dienstes von Mandatory zu Optional oder umgekehrt. Ebenso wurden Felder mit dieser Farbe

markiert, wenn ein als Mandatory bezeichneter Dienst in der vorherigen Phase noch gar nicht existierte oder in

der Folgenden nicht mehr implementiert wurde.

Im Wechsel der Phasen sind zwei Entwicklungen zu erkennen: Die Anzahl der optionalen Funktionen der mobi-

len Endgeräte nimmt im Laufe der Weiterentwicklung ab, und die Anzahl der verpflichtend zu implementieren-

den Dienste nimmt zu. Im Wechsel von Phase 2 zu Phase 2+ nahm die Gesamtanzahl der verzeichneten optional

zu implementierenden Dienste im Verhältnis zum angekündigten Gesamtdienstumfang bei GPRS und UMTS

deutlich weniger zu, als zu erwarten wäre. Die zahlenmäßige Verringerung der optional zu implementierenden

Dienste ist wahrscheinlich darauf zurückzuführen, dass man bei einer neuen Technologie zunächst alle Eventua-

litäten einplant und bei einer folgenden Phase dann nur noch die Dienste berücksichtigt werden, die sich auch

wirklich durchgesetzt haben. Die Spezifizierung einer Reihe optionaler Dienste bedeutet für die Endgeräteher-

steller keine Beschränkung auf diese Dienste und somit ein Verbot darüber hinausgehende Dienste zu implemen-

tieren. Es handelt sich dabei vielmehr um eine Liste von Vorschlägen, welche Features zusätzlich zu den Min-

destanforderungen noch implementiert werden könnten.

21

Kapitel 2.4: Mobile Equipment ________________________________________________________________

Dienstart Phase1[3] Phase 2[4] Phase 2+[5] Display of Called Number M* 1 M* 1 M* 1

Indication of Call Process Signals M* 1 M* 1 M* 1

Country PLMN Indication M* 1 M* 1 M* 1

Country PLMN Selection M M M* 1

Subscription Identity Management M M M Invalid PIN Indicator M Keypad O* 2 O* 2 O* 2

IMEI M M M Short Message O M* 4 M* 4

Short Message Overflow Indication O M M DTE/DCE Interface O O O

O O O Analogue Interface O International Access Function (“+” key) O*2 O*2 O*2 On/Off Switch O O O Service Indicator M*1 M*1 M*1 Autocalling Restriction Capabilities *3 *3 *3 Emergency Calls Capabilities M M M Dual Tone Multi Frequency Function M*5 M*5 Subadress O O Support of Encryption A5/1 and A5/2 M M Short Message Service Cell Broadcast DRX O O Short Message Service Cell Broadcast M Service Provider Indication O Support of the Extended SMS CB Channel O Support of Additional Call Set-up MMI Procedures O Network Identity and Timezone O Ciphering Indicator M*1 Networks Indication of Alerting in the MS O Network indicated Mobile Originated Connection O Support of Localised Service Area O Support of GPRS Encryption M*6 Abbreviated Dialling O O O Fixed Destination Call O Number Repetition O Handsfree Operation O Barring of Outgoing Calls O O Prevention of Unauthorized Use O Earpiece Volume Control O Second Earpiece O Loudspeaker Operation O Reception Quality Indicator O Switch- Off Timer O Self Testing M External Alarm O Automatic Switch-on O Second Handset O Call Charge Units Meter O Additional MS- features Display Functions O Multi User Mobile Station O Fixed Number Dialling O O DTFM (Dual Tone FM) Control Digits Seperator O O Selection of Directory No in Short Messages O O Last Number Dialled O O Barring of Dialled Numbers O ME SIM Lock O Service Dialling Numbers O

ISDN “S” Interface

Tabelle 1: Die funktionalen Anforderungen an das ME im „Generationenwechsel“

22

Kapitel 2.4: Mobile Equipment ________________________________________________________________ Die in Phase 1 noch obligatorisch im Endgerät zu implementierende Anzeige einer falschen Eingabe der PIN

wurde in Phase 2 und 2+ nicht mehr gefordert. Man stellte fest, dass eine erneute Aufforderung, die PIN ein-

zugeben als Indikator für eine Fehleingabe ausreicht.

Kurznachrichten und die entsprechende Anzeige, dass eine zu versendende Kurznachricht zu viele Zeichen ent-

hält, waren in Phase 1 noch optional. In den folgende Phasen wurden sie obligatorisch. Mit Phase 2 wurde das

SIM Application Toolkit eingeführt, ein erweiterter Befehlssatz für die SIM-Karte, der als wesentliches Feature

Proactive SIM implementiert hat und damit ein Update aus dem Netz ermöglicht. Dieser Mechanismus nutzt den

Kurznachrichtendienst und wäre ohne Kurznachrichten nicht anwendbar. Die Dual Tone Option und die Option

zwischen unterschiedlichen Versionen des A5 Algorithmus zu wechseln gibt es auch erst seit der Einführung von

SAT in GSM-Phase-2.

Mit GPRS und UMTS kommen einige weitere neue Basisdienste hinzu. Das SMS Cell Broadcast ist obligato-

risch zu unterstützen, ebenso die Anzeige einer Datenverschlüsselung bei UMTS bzw. eine Unterstützung der

GPRS Verschlüsselung.

Mit den oben angegebenen Diensten ist nicht die Unterstützung aller Funktionen durch die Endgeräte abgedeckt.

Ein Teil der Funktionen, die ein Dienst erfordert, wird in einer dafür speziellen Spezifikation des Dienstes be-

schrieben. Als Beispiel sei hier Streaming Audio und Streaming Video im Bereich von GPRS und UMTS ge-

nannt. Auch ist in den Spezifikationen nicht festgelegt, ob z.B. ein GPRS-Endgerät über ein Farben darstellendes

Display zu verfügen hat. Diese Entscheidungen werden den Herstellern von Endgeräten überlassen.

Die Schnittstelle des ME zum Benutzer (Man Machine Interface, MMI):

In Tabelle 1 werden die Funktionen, die das ME dem Netz zur Verfügung stellen muss, aufgezählt. Im Folgen-

den wird die Schnittstelle des ME zum Benutzer betrachtet. Diesen Zusammenhang behandeln die Man Machine

Interface (MMI) Spezifikationen, die in den Quellenangaben unter [6], [7] und [8] zu finden sind. Es handelt sich

dabei um die entsprechenden Dokumente der GSM Phasen 1, 2 und 2+.

Die erste Funktion, die eine MS dem Benutzer zur Verfügung stellen muss, ist die Möglichkeit das Endgerät ein-

zuschalten und die Abarbeitung der damit verbundenen Prozeduren. Da eben dieser Prozesskomplex bzgl. der

SIM-Karte in einem späteren Kapitel noch anhand eines Traces (Kommunikation SIM-ME) eingehend diskutiert

wird, soll an dieser Stelle nur das wesentliche Konzept des Vorganges aus Sicht des ME betrachtet werden. Zwi-

schen den einzelnen GSM-Phasen hat sich an diesem Konzept nichts geändert. Der auf Seite 24 folgende Zu-

standsautomat (Abbildung 8) wurde dem Sinne nach aus den Spezifikationen [6], [7], [8], jeweils Annex A, ü-

bernommen, jedoch stilistisch etwas aufgearbeitet (im Original werden Zustände und Handlungen vermischt).

Neben der europaweit (ETSI) spezifizierten Einbuchungsprozedur sind bezüglich des MMI auch noch andere

Abläufe (s.S.24/25) spezifiziert. Generell gilt, dass sich die beteiligten Gremien bei der Spezifizierung auf ein

Minimum an Anforderungen geeinigt haben, um den Herstellern von Endgeräten eine maximale Entwicklungs-

freiheit zu bewahren. So zählen zu den spezifizierten Funktionen u.a. der oben beschriebene Vorgang des Einbu-

chens, der 112 Notruf, der Verbindungsaufbau, die Art der Töne (vom Netz angestoßener Output an den Benut-

zer), u.a. Die Art des Outputs (Codenummern) wird in der MMI Spezifikation, Annex B und C, beschrieben, die

Frequenzen der einzelnen Töne, die vom Netz her auf bestimmte „Handlungen“ der MS hin beim Benutzer aus-

gegeben werden, sowie die Tastenanordnung und Belegung mit Zeichen in GSM 02.07. Dadurch das nur das Er-

23

Kapitel 2.4: Mobile Equipment ________________________________________________________________ gebnis als solches durch Spezifikationen vereinheitlicht wird, unterscheiden sich die Tastenbelegungen bei un-

terschiedlichen Endgeräten insbesondere bei Sonderzeichen massiv voneinander.

s

K L

I

H

G

F

E

D

C

B

A

Enter card

3

Failure- Treatment

5

Enter PIN

4

WAIT

2

Serv - AV

7

Enter- PLMN

6

MS-OFF

1 1: Die MS ist nicht in einem PLMN

eingebucht 2: MS wartet auf die vollständigeAbarbeitung einer Anforderung 3: Wartet auf Einlegen des SIM 4: Wartet auf PIN Eingabe 5: Wartet auf Fehlerbeseitigung 6: MS erwartet Eingabe des zuverwendenden PLMN7: Das MS ist eingebucht und kannnun verwendet werden A: ON, Endgerät wird aktiviert B: REQ, Aufforderung zum Einle-gen der Karte an Benutzer C: IOC, Insertion of Card mit SIM- Modul D: REQ, Aufforderung PIN ein-zugeben E: Complete, PIN wird eingegeben F: Failure, es ist in einem anderen Zustand ein Fehler aufgetreten G: DONE, Fehler wurde beseitigt H: REQ, Eingabeaufforderung Netz I: Entered, PLMN ausgewählt K: OK, alle Bedingungen erfüllt L: Conditional, alle geforderten Pa-rameter wurden übergeben

Abbildung 8: Zustandsautomat „Mobile Equipment“

Beispiele: Der Benutzer muss, selbst ohne eingelegte SIM-Karte, die 112 wählen können und dann mit der ent-

sprechenden Rettungsleitstelle verbunden werden. Wie das Netz oder die MS diese Funktion tatsächlich reali-

siert, obliegt dem Netzbetreiber bzw. Hersteller.

Für die Eingabe der internationalen Nummern-Wahl ist das „+“ Zeichen als Startzeichen vorgesehen. Wo auf

dem Endgerät der Benutzer dieses Zeichen zur Eingabe tatsächlich findet (z.B. im Tastenblock oder über ein

Menü), ist nicht spezifiziert worden. Spezifiziert wurde jedoch, dass die Null anstelle des „+“ vor der Länder-

kennung verwendet werden kann, was im Falle von Roaming während eines Gesprächs zu Schwierigkeiten füh-

ren könnte, da der Type of Number (TON) bei einer Null im Ländercode nicht wie beim „+“ auf international

format sondern auf Unknown gesetzt wird. Dieser Umstand erklärt sich daraus, dass das Plus-Zeichen in den

Vermittlungseinrichtungen als Platzhalter dient, der entsprechend umgesetzt wird, während die Null nur als eine

Ziffer interpretiert wird. Das „+“ signalisiert eindeutig eine internationale Nummer, zu der im besuchten Netz

automatisch die richtige Vorwahl hinzugefügt wird: In einem deutschen Netz wird eine englische Zielnummer

+31XXX zu 0031XXX umgesetzt, in einem österreichischen Netz zu 0931XXX und in einem englischen Netz

zu XXX (keine Ländervorwahl erforderlich, um von englischem Boden aus in England anzurufen). Mit der 0

funktioniert das nicht, weil sie als Bestandteil der Nummer interpretiert wird.

Neben oder anstelle der Eingabe durch Tasten besteht für den Endgerätehersteller laut Spezifikation auch die

Möglichkeit, eine Spracheingabe zu realisieren. Ebenso lässt die Spezifikation die Existenz von Endgeräten of-

fen, die als eigenständiger Baustein ausschließlich der Einwahl ins Netz dienen, aber über keine direkt steuerbare

24

Kapitel 2.4: Mobile Equipment ________________________________________________________________ Eingabefunktionen verfügen. Diese müssen dann von externen Geräten gesteuert werden. Hierbei dachte man

zunächst an internetfähige Handhelds und Notebooks.

Das MMI ist für die Abwicklung der folgenden Prozeduren verantwortlich (vgl. [15], Kapitel 11):

• Der gesamte Card Holder Verification (CHV) Bereich: Überprüfung der PIN, Aktivierung / Deaktivie-

rung einer erzwungenen PIN-Eingabe, Reaktivierung der erzwungenen CHV nach zuvor evtl. erfolgter

Deaktivierung

• Kurznachrichten

• Kostenanzeige

• Auswahl des Netzes unter Berücksichtigung von Einbuchungsvoraussetzungen des Anbieters oder Be-

nutzers (Übergabe eines Passwortes)

• Menüauswahl

• Erzeugung und Ausgabe von Short Message Status Reports

Eine größere Anzahl von Prozeduren werden sowohl vom ME als auch von der Benutzerschnittstelle MMI ge-

steuert. Hierzu zählen u.a. die Rufnummernwahl und die Anforderung von Bilddaten aus dem SIM. Wenn z.B.

der Benutzer eine bestimmte Eingabe getätigt hat, soll auf dem Display ein Bild dargestellt werden. Die Mittei-

lung, dass die Eingabe erfolgt ist, wird vom MMI ans ME weitergereicht, das dann die Bilddatei vom SIM an-

fordert und dem MMI zur Ausgabe auf dem Display übergibt. Ebenso gibt es Prozeduren, die in Zusammenar-

beit von Netz, ME und MMI durchgeführt werden.

Für den Verbindungsaufbau, -abbau und die Annahme eines Verbindungswunsches müssen dem Benutzer 4

Funktionen bereit gestellt werden:

• ACCEPT realisiert die Annahme eines eingehenden Anrufes.

• SELECT ermöglicht die Eingabe von Informationen, die aus einem Menü ausgewählt oder direkt ein-

gegeben (z.B. ein Eintrag im Adressbuch oder die PIN) werden.

• SEND übermittelt die vom Benutzer eingegebenen Informationen (Parameter) an das Netz.

• END beendet eine eingehende oder selbst aufgebaute Verbindung. Diese Funktion muss jeder beteilig-

ten Instanz zur Verfügung stehen, da eine Trennung von Verbindungen nicht zwangsläufig auf Wunsch

der Beteiligten erfolgen muss (z.B. wenn das Konto einer Prepaid-Karte leer ist).

Die Verifikation eines neu zu vergebenden Passwortes (PIN) durch den Benutzer wird ebenfalls durch das ME

realisiert (Eingabe der alten PIN und doppelte Eingabe der neuen PIN). Erst am Ende dieser Prozedur wird das

Passwort in dem SIM tatsächlich überschrieben.

Unterschiede zwischen den Spezifikationen von Phase 1, 2 und 2+ bestehen ausschließlich im Bereich der SS,

also derjenigen Dienste, deren Implementierung in der GSM-Spezifikation nicht obligatorisch ist. Die SS werden

in dieser Arbeit nicht weiter behandelt. Das Kapitel der Supplementary Services in der Spezifikation wächst mit

jeder höheren Versionsnummer stetig an.

Die IMEI:

Die IMEI (International Mobile Station Equipment Identity) muss dem Benutzer durch die Eingabe der Tasten-

kombination *#06# ausgegeben werden können.

25

Kapitel 2.4: Mobile Equipment ________________________________________________________________ Die IMEI ist eine eindeutige Nummer, mit der das Endgerät jederzeit international identifiziert werden kann.

Wird ein Endgerät z.B. gestohlen, so kann der Benutzer die IMEI sperren lassen, was dann in der Gerätedaten-

bank EIR (vgl. Kapitel 2.1) durch einen Eintrag in der Blacklist realisiert wird. Weil die IMEI international ver-

standen werden muss, wurde sie fest spezifiziert [9]. Sie wird vom Endgerätehersteller vergeben. Bedauerli-

cherweise ist es den Netzbetreibern freigestellt, in ihrem PLMN eine entsprechende Datenbank (EIR) zu führen,

wodurch gestohlene Endgeräte in manchen PLMNs trotz Sperrung der IMEI noch verwendet werden können.

Die Überprüfung der IMEI muss gemäß [9] jedem Netz bei jedem Verbindungsaufbau und auch während beste-

hender Verbindungen möglich sein, so dass ein Eintrag in einer Blacklist die sofortige Sperrung in dem PLMN

zur Folge hat. Zusätzlich soll dadurch eine eventuelle Strafverfolgung von wiederholt missbräuchlich abgesetz-

ten Notrufen ermöglicht werden. Die IMEI ist eine aus 14 Ziffern bestehende Nummer, die sich aus 3 eigenstän-

digen Nummern zusammensetzt:

• TAC: Type Aproval Code (6 Ziffern)

• FAC: Final Assembly Code (2 Ziffern)

• SNR: Serial Number (6 Ziffern)

Tatsächlich wird die IMEI ausschließlich in Verbindung mit der SVN (Software Version Number, 2 Ziffern) ü-

bertragen und daher als IMEISV (IMEI and Software Version Number) bezeichnet.

Die Schnittstelle zur Chipkarte SIM:

Diese Schnittstelle wird ausschließlich aus der Sicht der Chipkarte, also aus der Sicht vom SIM (SAT) in der TS

11.11 [15] und TS 11.14 [16] spezifiziert. Sie wird in dieser Arbeit in den Kapiteln 3 (SIM) bzw. 4 (SAT) aus-

führlich behandelt. Im Folgenden werden die Basisfunktionen bzgl. dieser Schnittstelle erläutert, wie sie in Kapi-

tel 11 der Spezifikation TS 11.11 [15] unter dem Titel „Application Protocol“ definiert sind.

Eine Nachricht, die zwischen ME und SIM ausgetauscht wird, ist entweder eine Anweisung (COMMAND) oder

eine Antwort (RESPONSE). Eine Prozedur ist eine Folge von einem oder mehreren Paaren solcher Anweisungen

und den zugehörigen Antworten. Man unterscheidet zwischen gestellten Aufgaben („Tasks“) und den zu ihrer

Erfüllung abzuarbeitenden Prozeduren. Erst wenn eine zur Erfüllung einer gestellten Aufgabe gestartete Proze-

dur vollständig abgearbeitet wurde, gilt die entsprechende Aufgabe als ausgeführt. Andernfalls wird die Prozedur

erneut angestoßen, bis sie entweder erfolgreich abgearbeitet wurde, oder z.B. nach einem Timeout eine Fehler-

meldung erfolgt ist, die ein Erfüllung der gestellten Aufgabe als unmöglich bezeichnet. Es ist eine der Aufgaben

des ME zu gewährleisten, dass die Abarbeitung aller angestoßenen Prozeduren vollständig erfolgt. Wie noch ge-

zeigt wird, erfordern einige Prozeduren als Parameter eine Eingabe seitens des Benutzers (MMI Interface).

Der Zugriff auf die Daten der Chipkarte und die Durchführung von Modifikationen werden mit den Kommandos

READ, UPDATE und INCREASE realisiert (vgl. TS 11.11, Kapitel 11.1 [15]). Um eine Datei auf dem SIM z.B.

mit dem READ-Kommando lesen zu können, muss sie zunächst mit SELECT ausgewählt werden. Die erfolgrei-

che Abarbeitung aller Kommandos an das SIM setzt voraus, dass das ME die Berechtigung hat, die jeweiligen

Kommandos bzgl. einer bestimmten Datei zu erteilen. Für jede Datei auf dem SIM sind dafür individuell feste

Parameter vorgegeben (siehe Kapitel 3.1), die zugelassene Befehle definieren. Wurden seitens des ME alle Be-

dingungen für z.B. einen Lesezugriff erfüllt, erfolgt schließlich durch das SIM die Übermittlung der geforderten

Daten an das ME. Wurden die Zugriffsvoraussetzungen vom ME nicht erfüllt, gibt das SIM die Daten nicht wei-

ter.

26

Kapitel 2.4: Mobile Equipment ________________________________________________________________ Mit dem Kommando UPDATE, werden alle Daten der betroffenen Datei auf dem SIM mit dem in der Anwei-

sung enthaltenen neuen Inhalt überschrieben. Der ursprüngliche Inhalt der Datei ist somit gleichzeitig auch ge-

löscht worden. Die INCREASE-Anweisung hängt die mit dem Kommando übergebenen Daten am Ende einer

bestehenden Datei an. Falls die Zugriffsbedingungen durch das ME nicht erfüllt wurden, werden keine Daten im

SIM verändert und es wird eine Fehlermeldung an das ME ausgegeben. Neben den oben beschriebenen Basis-

funktionen gibt es eine Reihe von Management-Prozeduren, die sich an das SIM richten und vom ME angesto-

ßen werden (vgl. TS 11.11, Kapitel 11 [15]):

• Initialisierung des SIM: Nach Einführen der Chipkarte und Einschalten des Endgeräts werden eine Rei-

he von Prozeduren abgearbeitet.

• GSM Session Terminierung: Dies umfasst den Abbau einer Verbindung und das endgültige Eintragen

der LAI auf der Chipkarte z.B. nach einem LU.

• Anforderung der Notrufnummern: Falls spezielle Notrufnummern im SIM enthalten sind und das SIM

eingelegt ist, werden sie dort ausgelesen.

• Abfrage der im Display zu verwendenden Sprache (allgemein und GSM – spezifisch)

• Anforderung von administrativen Informationen

• Abruf des „SIM-Dienstverzeichnisses“ (EFSST - Service Table)

• Abfrage der GSM-Phase des SIM

• Abfrage des zu verwendenden Dienstanbieters

2.5 Zusammenfassung Netz und Endgerät decken bereits ohne Chipkarte prinzipiell alle notwendigen Funktionen für ein „funktionie-

rendes“ Telefonnetz zur mobilen Telefonie ab, in dem eine Verbindung zu einem anderen Teilnehmer aufgebaut

und auch wieder abgebaut wird. Nur so ist die vorgeschriebene Möglichkeit zum Absetzen eines Notrufs ohne

eingelegte Chipkarte realisierbar.

Alle Funktionen, wie Frequenzmanagement, Anrufannahme, Verbindungsauslösung, Anrufvermittlung, etc. wer-

den ebenfalls durch das Netz und das Mobile Equipment vollständig abgedeckt.

Der Bereich der Kostenerfassung wird vom Netz abgedeckt und vom SIM unterstützt.

Die Verschlüsselung und die Speicherung kundensensitiver Daten*1 sowie die Einbuchung (Identifikation, Au-

thentisierung) in das Netz sind ausschließlich in Verbindung mit dem SIM möglich, das im folgenden Kapitel

eingehend behandelt wird.

*1 von WAP-Passworten, E-Mails und im Endgerät gespeicherten persönlichen Telefonnummern abgesehen

27

Kapitel 3: SIM: Phase 1 – Die Chipkarte des GSM ________________________________________________________________

3 SIM: Phase 1 - Die Chipkarte des GSM Diesem Kapitel liegen die Quellen [14] und insbesondere [15] zugrunde. Die Spezifikation des Subscriber Iden-

tity Module ist weitestgehend ISO/IEC 7816 konform. Die in diesem Kapitel primär verwendete Spezifikation

ist die SIM TS 11.11 Release 99 [15]. Da das Release-Datum nach der Einführung von SAT anzusiedeln ist, sind

diverse, im Dokument enthaltene Informationen nicht in der ursprünglichen SIM-Spezifikation enthalten und

verweisen bereits auf SAT-Anwendungen. Sie werden folglich erst im Kapitel 4 behandelt.

Die Geschichte der GSM-Chipkarten beginnt 1991 mit dem SIM (Subscriber Identity Module). Das SIM wurde

gemäß der 3GPP-Spezifikation TS 11.11 in Form einer Chipkarte realisiert und ermöglicht die Erfüllung der für

GSM geforderten Sicherheitsparameter. Mit der Umsetzung diverser Mehrwertdienste (VAS: Value Added Ser-

vices) stieß man jedoch bereits an die Grenzen des damals Machbaren, und so wurde es notwendig die Karte,

bzw. die darauf befindliche Software anzupassen. Änderungen an der Software konnten nicht einfach durchge-

führt werden, da ein servergesteuertes Aktualisieren in der Urform der Spezifikation TS 11.11 nicht vorgesehen

und mit dem implementierten Befehlssatz auch nicht realisierbar war. Also wurden 1994 neue, mit einem erwei-

terten Befehlssatz (SAT: SIM Application Toolkit, siehe Kapitel 4) ausgestattete Karten produziert und nach und

nach ausgegeben. Es gab keine generelle Umtauschaktion. Die neuen Karten lösten zum einen das Problem der

serverseitigen Aktualisierbarkeit der Daten auf der Karte und zum anderen stellten sie eine Plattform für eine

Vielzahl weiterer Mehrwertdienste bereit. Im Laufe der Zeit kristallisierte sich heraus, dass der Bedarf an mobi-

len multimedialen Anwendungen stark zunahm. Einer Einführung dieser technisch aufwändigeren Dienste und

einer daraus potentiell resultierenden Umsatzsteigerung standen jedoch die Beschränkungen der mobilen Endge-

räte im Wege.

Ein Großteil der Netzbetreiber und Endgerätehersteller vereinigte sich 1999 zu einem Konsortium, dem WAP-

Forum (WAP: Wireless Application Protokoll) und spezifizierte WAP, seine Unterprotokolle und die zugehörige

Textbeschreibungssprache WML (Wireless Markup Language) als mobilen Datendienst. Dieser De-facto-

Standard ermöglichte die Implementierung von Diensten, wie e-Mail-Abruf, Web-Browsing auf speziellen

WML-Seiten, Chat und eine Reihe personalisierter Dienste. Die letztlich größte Hürde für darüber hinaus gehen-

de Dienste war die geringe GSM zur Verfügung stehende Bandbreite von 9,6 kbps. Um diese Hürde zu meistern,

wurde 2001 GPRS ins Leben gerufen. Bei diesem Dienst (vgl. Kapitel 2.2) wurde dem Benutzer durch Kanal-

bündelung und paketorientierte Datenübertragung eine größere Bandbreite versprochen. Bereits Feldtests vor

Einführung der GPRS-Dienste, die im Wesentlichen immer noch die Infrastruktur und insbesondere das schmale

Frequenzband des GSM-Dienstes nutzten zeigten, dass die erhofften Ergebnisse insbesondere aufgrund des zu

geringen zur Verfügung stehenden Frequenzbandes nicht realisierbar waren. Die Steigerung der Übertragungsra-

ten gegenüber WAP war dennoch enorm, so dass z.B. farbige Bilder aus dem WWW heruntergeladen werden

konnten und ein Laden von HTML-Seiten anstelle der WML-Decks möglich war. Die Chipkarte wurde weder

bei der Einführung von WAP-Diensten, noch bei der Einführung von GPRS angepasst, was zur Folge hatte, dass

das Sicherheitskonzept, welches u.a. beinhaltete alle personalisierten Daten sicher auf der Karte unterzubringen,

gebrochen wurde. E-Mail-Adressen, Internet-Passworte, e-Mails selber und andere wurden in dem leicht mani-

pulierbaren Endgerät abgespeichert. Um angekündigte Dienste wie Streaming Audio und Streaming Video sinn-

voll nutzen zu können musste die Bandbreite erhöht werden. Dies konnte zum einen durch eine Zellverkleine-

rung realisiert werden, wie sie in Ballungszentren bereits bei GPRS durchgeführt wurde, zum anderen war drin-

gend auch eine Erweiterung des Frequenzbandes notwendig um eine konsequente Verkleinerung der Zellen auf

28

Kapitel 3: SIM: Phase 1 – Die Chipkarte des GSM ________________________________________________________________ sinnvolle Weise durchführen zu können. Für die Erhöhung der Sicherheit in Bezug auf Benutzerdaten war auch

eine neue Chipkarte im Endgerät erforderlich.

Eine Vergabe zusätzlicher Frequenzen (in Deutschland ist dafür die Regulierungsbehörde für Telekommunikati-

on und Post, RegTP verantwortlich) konnte jedoch nur anhand einer neuen Technologie erwirkt werden. Also

wurde zunächst wieder ein Konsortium gebildet, das UMTS-Forum und ein neuer Dienst (UMTS) wurde entwi-

ckelt. Auf der neuen Multi-Applikations-Chipkarte UICC (Universal Integrated Circuid Card, vgl. Kapitel 5)

wurden die UMTS-Pendants zur SIM-Karte und zur SAT-Anwendung als eigenständige Module implementiert:

USIM (Universal SIM) und USAT (Universal SIM Application Toolkit).

Besondere Leistungen von UMTS sind neben der erheblich größeren, nutzbaren Bandbreite die Garantie von

Dienstgüte (QoS: Quality of Service) und die damit verbundene (theoretische) Möglichkeit, Telefoniedienste ü-

ber das IP-Netz zu realisieren, also die Einführung eines All-IP-Netzes.

3.1 Das Trägersystem Physikalische Besonderheiten:

Das SIM war die Chipkarte, die 1991 in der ersten GSM-Phase eingesetzt wurde. Sie kann sowohl im Plug-In

Format als auch im ID-1 Format verwendet werden. Das Plug-In Format entspricht dem ausgelösten Chip des

ID-1 Formats und ist in der Regel bereits vorgestanzt. Während in Deutschland nur Endgeräte auf den Markt

kommen, die das Plug-In Format unterstützen, finden z.B. in Frankreich Endgeräte Anwendung, in die vollstän-

dige ID-1 Karten eingeführt werden können. Um zu gewährleisten, dass das Plug-In SIM nicht falsch eingelegt

werden kann, ist an der rechten, unteren Ecke ein Dreieck mit einer Schenkellänge von 3 mm abzusetzen.

Die PINs C4 und C8 sind für die GSM Anwendung nicht spezifiziert, können jedoch optional verwendet werden.

C6 (Vpp, Programmierspannung) braucht beim Plug-In-SIM vom Transponder gar nicht angesprochen werden.

Sollte das ME den Kontakt C6 unterstützen, so ist er mit Vcc (Grundspannung) zu verknüpfen und auf keinen

Fall mit der Masse zu verbinden.

Das SIM kann zwei Zustände annehmen: Entweder arbeitet es gerade ein Kommando ab oder es befindet sich im

Ruhestand. Der Takt wird vom ME angegeben und kann auch von ihm angehalten werden. Das SIM muss Takt-

raten von 1 und 5 MHz unterstützen. Die GSM Karte kann über einen eigenen Prozessor verfügen, es ist jedoch

nicht vorgeschrieben. *1

Die Dateihierarchie:

Die grundlegende Dateihierarchie entspricht weitgehend der in ISO/IEC 7816 beschriebenen. Ein Unterschied

sind die Second Level Dedicated Files, die im Folgenden noch näher beschrieben werden. Es gibt einige Kon-

ventionen bzgl. der Adressnomenklatur von Verzeichnissen und Dateien:

Das erste Byte eines jeden Files auf dem SIM definiert den Typ des Files:

• Das Master File beginnt mit ’3F’

• Level 1 Dedicated Files beginnen mit ’7F’

*1 Laut Auskunft von Herrn Kaliner, T-Mobile International, verfügt die von D1 eingesetzte Karte über einen solchen.

29

Kapitel 3.1: Das Trägersystem ________________________________________________________________

• Level 2 Dedicated Files beginnen mit ’5F’

• Elementary Files die unmittelbar unter einem Master File liegen, beginnen mit ’2F’

• Elementary Files unter einem Level 1 DF beginnen mit ’6F’ Level 2 Dedicated Files Typ ID DFIRIDIUM ’5F30’ DFGLOBALSTAR ’5F31’ DFICO ’5F32’ DFACeS ’5F33’ DFMExE ’5F3C’ DFEIA/TIA-553 ’5F40’ DFCTS ’5F60’ DFSoLSA ‘5F70’

• Elementary Files unter einem Level 2 DF beginnen mit ’4F’

Es sind genau 4 Typen von Level 1 Dedicated Files definiert:

• DFGSM enthält die Anwendungen für GSM und Digital Cel-

lular System (DCS)

• DFIS41 enthält die in ANSI-TIPI definierten Anwendungen

für IS-41 Tabelle 2: Lv.2-DF-Typen

• DFTELEKOM beinhaltet Telekommunikations-Dienste

• DFFP-CTS beinhaltet die Anwendungen für Cordless Telefony System (CTS)

Diese 4 Typen von Lv.1 Dedicated Files sind unmittelbare Kinder des Master Files und können auf einer Multi-

applikations-Karte koexistieren (vgl. [15], Kapitel 6.6).

Die Level 2 Dedicated Files sind alle unmittelbare Kinder des Level 1 DFGSM, sie werden in Tabelle 3 darge-

stellt. In der TS 11.11 Spezifikation wurden allerdings nur zwei dieser 2d Level DFs näher spezifiziert, sie sind in

der Tabelle in magenta unterlegt. In der folgenden Abbildung 9 wird die Verzeichnis-Hierarchie auf dem SIM

grafisch dargestellt.

EF EF

Lv2 DF EF

Lv2 DF

EF EF

Lv1 DF (DFGSM) Lv1 DF EF

EF

EF

Lv1 DF

Master File (MF)

EF EF EF

Abbildung 9: Die Verzeichnis-Struktur des SIM, vgl. [15], Kapitel 6.1 und 6.5

Diverse IDs sind bereits im Vorfeld für GSM reserviert worden und stehen daher der Adressvergabe für neue

Files nicht zur Verfügung. Diese Adressen können im Bedarfsfalle in der 3GPP Spezifikation [15] TS 11.11 im

Kapitel 6.6 „Reservation of File IDs“ nachgelesen werden.

Im Folgenden wird zunächst anhand von Tabelle 3 ein Überblick über alle vordefinierten DFs und EFs geschaf-

fen, und anschließend werden die in blau unterlegten Zeilen bzgl. ihres Inhaltes vorgestellt. Sie wurden nach ih-

rer Wichtigkeit für grundlegende Prozesse oder Einzigartigkeit in ihrer Struktur ausgewählt. Diverse Files wur-

den erst mit höheren Release-Nummern der Spezifikation eingeführt, so z.B. die für GPRS relevanten Files, die

dem Funktionsumfang des SIM zuzuordnen sind, jedoch in der ursprünglichen Fassung von TS 11.11, 1991 noch

nicht enthalten waren. Die Dedicated Files (rot, magenta) und das Master File (dunkelrot) sind zur Hervorhebung

farbig unterlegt. Die blau unterlegten Files können in der Anlage A in grafischer Form betrachtet werden.

30

Kapitel 3.1: Das Trägersystem ________________________________________________________________

≥

≥

Dateityp File ID

Struktur des Files, Länge

vgl. TS 11.11 Kapitel

MF 3F 00 Wurzelverzeichnis EFICCID 2F E2 transparent, 10 bytes 10.1.1 ID Nummer der Chipkarte EFELP 2F 05 transparent, 2n bytes 10.1.2 Extended Language Preference (allgemein) DFGSM 10.2 GSM spezifische Dateien EFLP 6F 05 transparent, x bytes 10.3.1 bevorzugte Spracheinstellung innerhalb GSM EFIMSI 6F 07 transparent, 9 bytes 10.3.2 enthält die IMSI EFKc 6F 20 transparent, 9 bytes 10.3.3 enthält den Schlüssel Kc EFPLMNsel 6F 30 transparent, 3n (n 8) EFHPLMN 6F 31 transparent, 1 byte 10.3.5 max. Suchzeit für HPLMN EFACMmax 6F 37 transparent, 3 bytes 10.3.6 ACM max. Wert EFSST 6F 38 transparent, min. 2 byte 10.3.7 SIM Service Table (verfügbare Dienste) EFACM 6F 39 cyclic, 3 bytes 10.3.8 Accumulated Call Meter EFGIDI 6F 3E transparent, 1-n bytes 10.3.9 Group Identifier Level 1 EFGIDI2 6F 3F transparent, 1-n bytes 10.3.10 Group Identifier Level 2 EFSPN 6F 46 transparent, 17 bytes 10.3.11 Service Provider Name EFPUCT 6F 41 transparent, 5 bytes 10.3.12 Preis je Einheiten und Währung EFCBMI 6F 45 transparent, 2n bytes 10.3.13 Cell Broadcast Message Identifier Select. EFBCCH 6F 74 transparent, 16 bytes 10.3.14 Broadcast Control Channels EFACC 6F 78 transparent, 2 bytes 10.3.15 Access Control Class EFFPLMN 6F 7B transparent, 12 bytes 10.3.16 Forbidden PLMNs EFLOCI 6F 7E transparent, 11 byte 10.3.17 TMSI + Ortsinformation EFAD 6F AD transparent, 3+x bytes 10.3.18 Administrative Data EFPhase 6F AE transparent, 1 byte 10.3.19 Phaseninformation über GSM EFVGCS 6F B1 transparent, 4n ≤ 50 10.3.20 Voice Group Call Service EFVGCSS 6FB2 transparent, 7 bytes 10.3.21 Voice Group Call Service Status EFVBS 6F B3 transparent, 4n ≤ 50 10.3.22 Voice Broadcast Service EFVBSS 6F B4 transparent, 7 bytes 10.3.23 Voice Broadcast Service Status EFeMLPP 6F B5 transparent, 2 bytes 10.3.24 enhanced Multi Level Pre Emption & Priority EFAAeM 6F B6 transparent, 1 byte 10.3.25 Automatic Answer for eMLPP Services EFCBMID 6F 48 transparent, 2n bytes 10.3.26 Cell Broadcast Message Identifier for Data

Download EFECC 6F B7 transparent, 3n, (n ≤ 5) 10.3.27 Emergency Call Codes EFCBMIR 6F 50 transparent, 4n bytes 10.3.28 Cell Broadcast Message Identifier Range Selec-

tion EFDCK 6F 2C transparent, 16 byte 10.3.29 De-Personalisation Control Keys EFCNL 6F 32 transparent, 6n bytes 10.3.30 Co- operative Network List EFNIA 6F 51 linear fixed, x+1 bytes 10.3.31 Networks Indication of Alerting EFKcGPRS 6F 52 transparent, 9 bytes 10.3.32 GPRS Ciphering Key KcGPRS EFLOCIGPRS 6F 53 transparent, 14 bytes 10.3.33 GPRS Location Information EFSUME 6F 54 transparent, x+y bytes 10.3.34 SetUpMenu Elements E-FPLMNwAcT

6F 60 transparent, 5n, (n ≥ 8) bytes

10.3.35 User Control PLMN Selection with Access Technology

EFOL-

MNwAcT

6F 61 transparent, 4n, (n ≥ 8) 10.3.36 Operator Called PLMN Selector w. Ac. T.

EFHPLMNwAcT

6F 62 transparent, 5n bytes 10.3.37 HPLMN Selector with Access Technology

EFCPBCCH 6F 63 transparent, 2n bytes 10.3.38 CPBCCH Information EFInvScan 6F 64 transparent, 1 byte 10.3.39 Investigation Scan E-FRPLMNAcT

6F 5F transparent, 2*x bytes 10.3.40 RPLMN Last used Access Technology

DFSoLSA 5F 70 10.4.1 SoLSA spezifische Dateien EFSAI 4F 30 transparent, x+1 bytes 10.4.1.1 SoLSA Access Indicator EFSLL 4F 31 lin. fixed, x+10 bytes 10.4.1.2 SoLSA LSA List DFMExE 5F 3C 10.4.2 MexE spezifische Dateien EFMExE-ST 4F 40 transparent, x byte, x 1 10.4.2.1 MExE Service Table EFORPK 4F 41 lin. Fixed, x+10 bytes 10.4.2.2 Operator Root Public Key EFARPK 4F 42 lin. fixed, x+10 bytes 10.4.2.3 Administrator Root Public Key EFTPRPK 4F 43 lin. Fixed, x+10 bytes 10.4.2.4 Third Party Root Public Key

zur Auswahl stehende PLMNs 10.3.4

Beschreibung, Zweck

Tabelle 3a: Die in der SIM Spezifikation vordefinierten Dateien der SIM Karte

31

Kapitel 3.1: Das Trägersystem ________________________________________________________________

Die im DFTELEKOM enthaltenen Dateien enthalten alle für diem Telekommunikationsdienste notwendigen Infor-

mationen, nicht aber die Informationen, die für Vermittlungszwecke benötigt werden. Letztere findet man im

DFGSM. Dort werden unter anderem Gruppenzugehörigkeiten, Identifikationsdaten und Daten zu nutzbaren

Dateityp File ID Struktur des Files, Län-ge

vgl. TS 11.11 Kapitel

Beschreibung, Zweck

DFTELECOM 7F 10 10.5 dienstspezifische Informationen EFADN 6F 3A lin. fixed, x+14 bytes 10.5.1 Kurzrufnummern (ADN) EFFDN 6F 3B lin. fixed, x+14 bytes 10.5.2 Festrufnummern (FDN) EFSMS 6F 3C lin. fixed, 176 bytes 10.5.3 Speicherplatz für Short Messages EFCCP 6F 3D lin. fixed, 14 bytes 10.5.4.1 Capability Configuration Parameters EFECCP 6F 4F lin. fixed, 14 bytes 10.5.4.2 Extended CCP EFMSISDN 6F 40 lin. fixed, x+14 bytes 10.5.5 die eigene Rufnummer EFSMSP 6F 42 lin. fixed, 28+y bytes 10.5.6 Short Message Service Parameter EFSMSS 6F 43 transparent, 2+x bytes 10.5.7 Short Message Status EFLND 6F 44 cyclic, x+14 bytes 10.5.8 Last Number Dialled (für Wahlwiederholung) EFSDN 6F 49 lin. fixed, x+14 bytes 10.5.9 Service Dialling Numbers EFEXT1 6F 4A lin. fixed, 13 bytes 10.5.10 Extension 1 EFEXT2 6F 4B lin. fixed, 13 bytes 10.5.11 Extension 2 EFEXT3 6F 4C lin. fixed, 13 bytes 10.5.12 Extension 3 EFBDN 6F 4D lin. fixed, x+15 bytes 10.5.13 Barred Dialling Numbers EFEXT4 6F 4E lin. fixed, 13 bytes 10.5.14 Extension 4 EFSMSR 6F 47 lin. fixed, 30 bytes 10.5.15 Short Message Status Reports EFCMI 6F 58 lin. fixed, x+1 bytes 10.5.16 Comparison Method Information DFGraphics 5F 50 EFIMG 4F 20 lin. fixed, 9n+2 bytes 10.6.1.1 Image

Tabelle 3b: Die in der SIM Spezifikation vordefinierten Dateien der SIM Karte (DFTELECOM). Die Daten der Tabelle 3 wurden aus der unterschiedlichen Bereichen der Spec. [15] zusammengetragen

Entgegen der auf Seite 31 (vgl. [15], Kapitel 6.3, letzter Satz) getroffenen Behauptung, dass sämtliche Second

Level DFs unmittelbare Kinder des DFGSM seien, gibt es eine Ausnahme: Das DFGraphics, in dem Bilder (Icons)

abgelegt werden ist ein 2d Level DF des DFTELECOM. Dies stellt eine Inkonsistenz der Spezifikation dar: Wahr-

scheinlich vergaß man bei Einführung des DFGraphics, diesen Satz zu entfernen. Das DFGraphics wird auf Seite 40

noch genauer untersucht. Ferner gibt es noch in den Tabellen nicht aufgeführte, aber teilspezifizierte Klassen von

EFs. Für diese Klassen sind feste Befehle vordefiniert, sowie das erste Byte der Adresse. Ein Beispiel für eine

solche Klasse ist die Gruppe der Image Instance Data Files. Unter Anderem werden mit deren Hilfe neue Bilder

instanziert. Die in EFIMG spezifizierten Parameter sind einzuhalten. Dies wird auf Seite 39 näher beschrieben.

Der SIM Karte bzw. dem ME stehen eine bestimmte Anzahl an Befehlen zur Verfügung, die abhängig von der

Struktur des Files während einer GSM Session auf die Daten des SIM angewendet werden dürfen. Die folgende

Tabelle (vgl. [15], Kapitel 8, Tabelle 8, „Functions on Files in GSM Session“) gibt Aufschluss über die anwend-

baren Befehle je File-Typus. Anschließend sollen die einzelnen Befehle erläutert werden:

File

Function MF DF EF transparent EF linear fixed EF cyclic SELECT X X X X X

STATUS X X X X X

READ BINARY X

UPDATE BINARY X

READ RECORD X X

UPDATE RECORD X X

SEEK X

INCREASE X

INVALIDATE X X X

REHABILITATE X X X

Tabelle 4: Auf Dateien ausführbare Funktionen während einer GSM Session [15]

32

Kapitel 3.1: Das Trägersystem ________________________________________________________________

• SELECT: Mit dem SELECT Kommando wird vom ME ein bestimmtes File ausgewählt und ein Zeiger

wird im File gesetzt. Während die Position des Zeigers in einer Datei mit dem Attribut „Linear Fixed“

undefiniert ist, steht der Zeiger bei einer zyklischen Datei auf dem zuletzt geänderten Eintrag. Als Ü-

bergabeparameter erwartet das SIM die ID der Datei. Die Ausgabe unterscheidet sich danach, ob ein

Verzeichnis (MF bzw. DF) ausgewählt wurde, oder eine Datei (EF). Im ersten Fall werden die File ID,

der für dieses Verzeichnis insgesamt verfügbare Speicherplatz, Daten bzgl. der CHV und zusätzlich

GSM-spezifische Daten ausgegeben. Ist das ausgewählte File eine Datei, werden neben der File ID

noch die Größe der Datei, die Zugriffsbedingungen, die Struktur der Datei und entsprechend, wenn es

sich um eine Datei der Typen linear fixed oder cyclic handelt, die Länge der Records an das ME zurück

geliefert (vgl. [15], 8.1).

• STATUS: Dieses Kommando bekommt als Rückgabewert Informationen bzgl. des Verzeichnisses, in

dem sich der Zeiger gerade befindet. Es ist rein informativ und liefert bei Anwendung auf Dateien kei-

nen Rückgabewert. Wird sie auf Verzeichnisse angewandt, so liefert sie die selben Rückgabewerte wie

SELECT (vgl. [15], 8.2).

• READ BINARY: Mit diesem Kommando wird ein String von Bytes zur Übergabe an das ME angefor-

dert. Da nur das transparente EF Einträge enthält, die in Sequenzen von Einzelbits codiert sind, ist die-

ses Kommando auch ausschließlich auf diese anzuwenden. Gleiches gilt für das folgende Kommando

UPDATE BINARY. Das Kommando READ BINARY darf nur dann ausgeführt werden, wenn die

Zugriffsbedingungen für das READ Kommando erfüllt wurden. Als Eingabe erwartet das transparente

EF die relative Adressierung und die Länge des Strings (vgl. [15], 8.3).

• UPDATE BINARY: Wie bei READ BINARY kann dieser Befehl auch ausschließlich auf transparen-

ten EFs ausgeführt werden. Als Eingabe wird die relative Adresse und Länge des zu verändernden

Strings sowie der neue String erwartet. Es erfolgt keine Ausgabe. Die Zugriffsbedingungen für UP-

DATE müssen erfüllt sein (vgl. [15], 8.4).

• READ RECORD: Dieser Befehl ist das Pendant von READ BINARY für Dateien vom Typ cyclic

bzw. linear fixed. Der Record-Zeiger darf nur dann in seiner Position versetzt werden, wenn der Zugriff

erfolgreich war. Bei READ RECORD werden als Eingabeparameter der Modus und ggf. die absolute

Nummer des Records und die Länge des Records erwartet. Zurück geliefert wird der Record selbst (vgl.

[15], 8.5).

• UPDATE RECORD: erwartet zum Einen dieselben Eingabeparameter wie READ RECORD und zu-

sätzlich den neuen Record, der den Alten ersetzen soll. Eine Rückgabe erfolgt nicht. Sowohl bei READ

RECORD als auch bei UPDATE RECORD müssen die jeweiligen Zugriffsparameter erfüllt werden

(vgl. [15], 8.6).

• SEEK: Die SEEK Anweisung kann nur auf EFs vom Typ linear fixed angewandt werden. Es wird nur

dann ausgeführt, wenn das ME die Zugriffsbedingungen für das READ Kommando erfüllt. Zwei unter-

schiedliche Typen dieses Kommandos sind definiert: Typ 1, die einzige Phase-1-SIMs zur Verfügung

stehende Variante, setzt den Zeiger auf den gesuchten Eintrag und liefert keinen Rückgabewert. Typ 2

setzt ebenfalls den Zeiger auf den gewünschten Eintrag, liefert aber zusätzlich den Status und die

Nummer des Records zurück. Für das Suchkommando selbst sind 4 Modi definiert: Die Suche vom An-

fang bis zum Ende, die umgekehrte Suche, von der folgenden Position des Zeigers an vorwärts und von

33

Kapitel 3.1: Das Trägersystem ________________________________________________________________

der Vorgängerposition des Zeigers an rückwärts. Als Eingabe werden in beiden Fällen Typ, Modus, ein

Suchmuster (Folge von Bytes) und die Länge des Suchmusters erwartet (vgl. [15], 8.7).

• INCREASE: Das INCREASE Kommando setzt voraus, dass Zugriffsbedingungen für das Kommando

definiert sind und erfüllt wurden. Es ist auf zyklische EFs beschränkt. Als Eingabe wird der hinzuzufü-

gende Wert erwartet, und als Rückgabe werden der Wert des erweiterten Records und der hinzugefügte

Wert ausgegeben. Der einzufügende Wert wird direkt hinter dem jüngsten enthaltenen Wert angesiedelt

und erhält die Record-Nummer 1 (vgl. [15], 8.8).

• INVALIDATE: INVALIDATE und REHABILIDATE heben sich gegenseitig auf und unterliegen an-

sonsten denselben Bedingungen.. Mit INVALIDATE kann ein EF deaktiviert werden, während es mit

REHABILITATE wieder aktiviert wird. Beide erfordern weder Eingabeparameter, noch liefern sie

Ausgaben an das ME zurück. Die Berechtigung zur Ausführung dieses Kommandos wird geprüft. Nach

der Ausführung der INVALIDATE Anweisung besteht das EF zwar weiterhin auf dem SIM, ausge-

nommen des SELECT Kommandos kann jedoch keine andere Anweisung auf das EF ausgeführt wer-

den, selbst dann nicht, wenn explizit READ und UPDATE für diese Datei zugelassen sind (vgl. [15],

8.14). Um eine entsprechende Handlung auf eine invalidierte Datei vornehmen zu können, muss erst

das REHABILITATE Kommando ausgesprochen werden.

• REHABILITATE: siehe INVALIDATE (vgl. [15], 8.15).

Weitere Anweisungen, die an die SIM Karte bzw. spezielle EFs erteilt werden können, werden im Kapitel 5

(SAT) behandelt. Für die einzelnen ausführbaren Befehle bestehen für das ME jeweils separate Zugriffsbedin-

gungen je Datei, die es im Vorfeld erfüllen muss. Die folgende Tabelle 5 vereinigt die in der Spec. [15] enthalte-

nen Tabellen 7 in Kapitel 7.3 und 10 in Kapitel 9.3 und gibt Aufschluss über die einzelnen Abstufungen der

Zugriffsrechte und Kodierung:

Level Inhalt Kodierung 0 ALWays ‘0’ 1 CHV 1 ‘1’ 2 CHV 2 ‘2’ 3 Reserviert für zuk. Anw. ‚3’ 4 bis 14 ADM ‘4’ – ‘E’ 15 NEVer ‘F’

Tabelle 5: Zugriffsbedingungen auf Dateien nach Si-cherheitslevel

• ALWays: Für das ME gibt es keine Einschränkungen, diesen Befehl auszuführen

• CHV 1: (Card Holder Verification 1) Anweisungen, die innerhalb der EFs mit diesem Attribut versehen

sind, müssen um ausgeführt werden zu dürfen, mindestens einer der drei folgenden Bedingungen genü-

gen:

a) während der bestehenden Session wurde dem SIM bereits ein gültiger CHV 1 Wert übergeben.

b) der CHV 1 enabled/disabled Schalter wurde zuvor bereits auf disabled gesetzt.

c) während der bestehenden Session wurde das UNBLOCK CHV 1 Kommando bereits erfolgreich aus-

geführt. Die Nummer CHV1 entspricht der mit der Karte an den Kunden übergebenen PIN 1.

• CHV 2: Hier gibt es zwei Erfüllungskriterien für das ME:

a) CHV 2 wurde in der Session bereits erfolgreich übergeben

b) Das UNBLOCK CHV 2 Kommando wurde innerhalb der bestehenden Session bereits erfolgreich

ausgeführt. Die CHV2 entspricht der mit der Karte ausgegebenen PIN 2.

34

Kapitel 3.1: Das Trägersystem ________________________________________________________________

• ADM: Diese Sicherheitsstufen stehen ausschließlich der Administration zur Verfügung und spielen für

das ME bzw. den Benutzer keinerlei Rolle. Mit Administration oder ADM wird in der Regel der Kar-

tenhersteller bzw. der Netzbetreiber (Service Provider) bezeichnet.

• NEVer: Diese Anweisungen können unter keinen Umständen über die SIM/ME Schnittstelle ausge-

führt werden. Es wäre möglich, dass das SIM diese Anweisungen ohne Anstoß durch das ME intern

selber ausführt.

Dateien auf der SIM Karte:

Es folgt die Diskussion der in Tabelle 3 blau unterlegten EFs. Die angegebenen Größen beziehen sich auf das

Datenfeld. Hinzu kommt ein ca. 16 Byte langer Overhead je Datenfeld und File-Header*1. Die Größen der Da-

tenfelder sind entweder durch die Spezifikation oder den Kartenherausgeber festgelegt. Sie können vom ME

nicht verändert werden. Die File Header Daten können durch das STATUS Kommando ermittelt werden. Seit

der Einführung von SAT gibt es zu diesem Zweck ein weiteres Kommando, das in Kapitel 3.2 beschrieben wird.

EFICCID (siehe Annex A, Seite a, Nr.1)

Im EFICCID ist als einziges Datum die international eindeutige Identifikationsnummer der Chipkarte enthalten. Es

ist unabhängig von GSM und direkt unter dem MF angesiedelt. Seine Struktur ist transparent, es muss auf jeder

GSM-SIM-Karte enthalten sein und darf jederzeit ausgelesen, aber nicht modifiziert werden. ADM darf die

Nummer bzw. die Datei sperren und wieder frei geben. Die Größe des EFs beträgt 10 Bytes. Die Identifikations-

nummer kann bis zu maximal 20 Digits à 4 Bit lang sein. Die Ziffern der Nummer sind im BCD (Binary Code

Decimal) gespeichert. Die ICCID wird vom Kartenhersteller (Personalisierer) auf die Karte geschrieben und ist

weltweit eindeutig. Die festgelegten (international von der ITU, national der RegTP) Elemente, aus der sich die

Nummer zusammensetzt bezeichnen den Kartenhersteller und eine eigens zu vergebende Kartenseriennummer.

EFLP (siehe Annex A, Seite a, Nr.2)

Das EFLP (Language Preference) ist ein Kind des DFGSM und enthält, wie auch das direkt unter dem MF angesie-

delte EFELP einen oder mehrere Sprachcodes. Die Spracheinstellung für die erste Sprache ist obligatorisch, wäh-

rend alle weiteren Spracheinträge optional sind. Sind keine weiteren Sprachen in der Datei eingetragen, so ent-

hält ihr Datenteil genau ein Byte, was der Länge eines Sprachcodeeintrags entspricht. Der Datenteil darf jeder-

zeit vom ME ausgelesen werden, aber nur nach der Eingabe von CHV 1 überschrieben werden. Das Invalidieren

bzw. Rehabilitieren der Datei obliegt ausschließlich ADM (Netzbetreiber, Kartenherausgeber oder Kartenher-

steller). Der Spracheintrag mit der niedrigsten Nummer ist jeweils der höchst bewertete Eintrag und erhält somit

die höchste Priorität. Folgeeinträge werden nur dann verwendet, wenn das ME diese Sprache nicht unterstützt.

EFIMSI (siehe Annex A, Seite a, Nr.3)

Das EFIMSI dient der Speicherung der International Mobile Subscriber Identity, die den Besitzer des zugehörigen

Kartenvertrages identifiziert und anhand derer der Kunde im Netz identifiziert und abgerechnet wird. Die Num-

mer kann nur mit der entsprechenden Autorisierung (CHV 1) gelesen werden. Eine Veränderung bzw. die Sper-

rung der Nummer obliegt ADM. Sie kann dann vom Benutzer unter Eingabe der CHV 1 reaktiviert werden. Das

EF hat eine transparente Struktur und ein 9 Bytes langes Datenfeld. Auf einem Byte wird die Länge der IMSI

und den restlichen die IMSI selbst codiert. Die IMSI wird vom Netzbetreiber (Kartenherausgeber) festgelegt. Er

*1 Nach Auskunft von Herrn Kaliner, T-Mobile International, ist der Overhead kartenabhängig und nicht näher spezifiziert.

35

Kapitel 3.1: Das Trägersystem ________________________________________________________________ muss allerdings ihm fest zugewiesene Elemente zur eindeutigen Netzkennzeichnung (Mobile Network Code,

MNC und Mobile Country Code, MCC) verwenden. Diese festen Codes werden von der GSM Association in

Dublin verwaltet.

EFKC (siehe Annex A, Seite b, Nr.4)

Im Datenfeld des EFKC sind der 8 Byte lange Schlüssel KC mit seiner 1 Bit langen Sequenznummer enthalten.

Dieser Schlüssel wird für die RUN_GSM_ALGORITHM-Funktion verwendet, die in Kapitel 4.2 gründlich er-

läutert wird. Der Schlüssel wird bei jeder Session aufs Neue zwischen Netz und SIM ausgehandelt und daher

häufig aktualisiert. Er darf nur vom ME ausgelesen oder nach Aushandeln mit dem Netz erneuert werden, wenn

der Benutzer die CHV 1 eingegeben hat. Die Invalidierung des EFs und die Rehabilitierung obliegen ADM.

EFPLMN (siehe Annex A, Seite b, Nr.5)

In dem transparenten EFPLMN werden die zu verwendenden PLMNs gespeichert, wobei das erste PLMN der Lis-

te die höchste Priorität hat und nur dann ein anderes gewählt wird, wenn dieses nicht verfügbar ist. Die Datei ist

optional. Ist sie vorhanden, so muss sie über mindestens 8 Einträge verfügen. Das EF darf vom ME nach der

Eingabe der CHV 1 sowohl gelesen als auch aktualisiert werden.

EFSST (siehe Annex A, Seite b, Nr.6)

Das EFSST (SIM Service Table) hat eine transparente Struktur. Anhand der enthaltenen Liste kann ein ME wäh-

rend des Initialisierungsprozesses feststellen, welche Dienste von der SIM-Karte unterstützt werden. Die Num-

mern der Dienste sind von ETSI vorgegeben und werden in Tabelle 6 ausschnittweise vorgestellt. Die Datei ist

obligatorisch und muss, selbst wenn es sich um ein Phase-2-SIM handelt zumindest auf 2 Byte codiert für Phase

1 kompatible Anwendungen enthalten. Jeder einzelne Dienst ist in 2 Bit codiert: Das erste Bit gibt an, ob er zu-

gewiesen wurde, und das zweite, ob er aktiv nutzbar ist. Wegen der festgelegten Reihenfolge der ist nicht mög-

lich, die Dienste 17-24 in die Liste aufzunehmen ohne die Dienste 9-16 integriert zu haben. Nach Eingabe der

CHV1 kann das ME die Datei einlesen. Veränderungen, bzw. Invalidierung und Rehabilitierung obliegen ADM.

Tabelle 6: Ausschnitt aus der Dienst Nummerierungs-Liste; RFU: Reserved for Future Use

Ausschnitt aus der Dienste–Tabelle der ETSI Service n° 1: CHV 1, disable function Service n° 13: Last Number Dialled (LND) Service n° 2: Abbreviated Dialling Numbers (ADN) Service n° 14: Cell Broadcast Message Identifier Service n° 3: Fixed Dialling Numbers (FDN) Service n° 15: Group Identifier Level 1 Service n° 4: Short Message Storage (SMS) Service n° 16: Group Identifier Level 2 Service n° 5: Advice of Charge (AoC) Service n° 17: Service Provider Name Service n° 6: Capability Configuration Parameters Service n° 18: Service Dialling Numbers (SDN) Service n° 7: PLMN Selector Service n° 19: Extension 3 Service n° 8: RFU Service n° 20: RFU Service n° 9: MSISDN Service n° 21: VGSC Group Identifier List Service n° 10: Extension 1 Service n° 22: VBS Group Identifier List Service n° 11: Extension 2 ………………………….. Service n° 12: SMS Parameters Service n° 50: RPLMN last used Access Technology:

ETSI hat in der Tabelle 50 Dienste mit Dienstnummern versehen, die in linearer Abfolge zu Vierergruppen (je-

der Dienst wird in 2 Bit codiert) je Byte im SST codiert sein können. Die ersten 8 Dienste entsprechen den in

Phase 1 definierten Mindestanforderungen.

EFSPN (siehe Annex A, Seite c, Nr.7)

Das transparente, optionale EFSPN (Service Provider Name) enthält den Namen des Dienstanbieters, bei dem der

Kunde den Mobilfunkvertrag abgeschlossen hat. Zusätzlich wird mit dem ersten Bit des ersten Bytes codiert, ob

36

Kapitel 3.1: Das Trägersystem ________________________________________________________________ das entsprechend registrierte PLMN im Display angezeigt werden soll. Die restlichen 7 Bit sind in diesem Byte

für zukünftige Anwendungen reserviert. Der Lesezugriff kann ohne Einschränkung durchgeführt werden. Alle

restlichen Zugriffe obliegen ADM.

EFPUCT (siehe Annex A, Seite c, Nr.8) und EFACM (siehe Annex A, Seite c, Nr.9)

Das transparente EFPUCT (Price per Unit and Currency Table) wird benötigt, wenn sich der Kunde seine Ge-

sprächskosten auf dem Display anzeigen lassen will. Die Datei wird nur in Verbindung mit dem zyklischen E-

FACM (Accumulated Call Meter) verwendet und ist bei Existenz des EFACM auf dem SIM obligatorisch. Während

in EFACM die Summe der angefallenen Gesprächseinheiten gespeichert wird, repräsentiert das EFPUCT die zur Be-

rechnung der Kosten notwendigen Rohdaten. Nach Eingabe des Passworts können beide von der MS jederzeit

gelesen und aktualisiert werden, wobei EFACM durch seine zyklische Struktur bedingt (bis es voll ist) erweitert

werden kann. Die Invalidierung bzw. Rehabilitierung der EFs obliegt ADM. Während der Preis pro Einheit (in

EFPUCT) selten verändert wird, werden die angefallenen Gesprächseinheiten oft aktualisiert: Entsprechend ist der

Eintrag im Feld „Update activity“ auch in beiden EFs unterschiedlich.

EFLOCI (siehe Annex A, Seite c, Nr.10)

Das transparente EFLOCI beinhaltet die Orts-Informationen bzgl. des aktuellen Aufenthaltsortes des eingeschalte-

ten Endgeräts bzw. die zuletzt vor dem Ausschalten des Endgerätes registrierte LA. Neben der Location Area

Information (LAI) beinhaltet es auch die TMSI, die zur Anonymisierung des Benutzers während einer Session

verwendet wird, sowie den Zeitpunkt, wann sie zuletzt geändert wurde. Sie wird unabhängig von der Session

nach Ablauf eines bestimmten Zeitintervalls geändert. Im Feld des Location Update Status steht ob ein Location

Update schon durchgeführt wurde oder das gerade besuchte PLMN bzw. die LA für ein Update gesperrt ist.

EFPhase (siehe Annex A, Seite d, Nr.11)

Das transparente Elementary File „Phase“ enthält die GSM Phase, aus der die SIM-Karte stammt. Es dient dem

ME als Informationsquelle, damit es „weiß“, welche Befehle an das SIM abgesetzt werden dürfen und welche

Befehle vom SIM nicht bzw. fehlinterpretiert würden. Die Größe des Datenfelds ist 1 Byte und wird als hexade-

zimaler Wert gespeichert. Bis auf die Werte 01, 02 und 03, die die Phasen 1, 2 und 2+ repräsentieren, sind alle

sonst möglichen Werte gesperrt. Die Werte von 04 bis 0F definieren eine eingeschränkte Funktionsfähigkeit des

SIM. Auf das EF kann das ME ohne Einschränkung aber ausschließlich lesend zugreifen.

EFFDN (siehe Annex A, Seite d, Nr.12)

Im EFFDN (Fixed Dialling Numbers) sind voreingestellte Rufnummern und zusätzliche Dienst-Kontroll-Strings

enthalten. Sie können nach der Übergabe des CHV 1 gelesen und (CHV 2) aktualisiert werden. Die Struktur ist

linear fixed. Nicht belegte Datenfelder werden mit Platzhaltern (’F’) aufgefüllt. Einzelne Records können ge-

löscht oder eingefügt werden. Mit dem Alpha Identifier werden die im Adressbuch eingetragenen, alphanumeri-

schen Namen codiert. Das EFFDN kann auch für individuelle Telefonnummern des Benutzers verwendet werden.

Überlange Nummern werden im EFEXT2 gespeichert, auf das dann ggf. das letzte Byte X+14 verweist. Das EFFDN

ist dafür gedacht, einen Benutzer auf den Zugriff bestimmter Rufnummern zu beschränken. Wenn z.B. Eltern

ihren Kindern ein MS übergeben, das ausschließlich das EFFDN zur Nummernwahl zulässt und ihnen auch nur

die CHV1 übergeben, so können ausschließlich sie selber diese Liste mit der CHV2 modifizieren und dennoch

bleibt gewährleistet, dass ein Verwenden des Endgeräts allein durch die Eingabe der PIN1 möglich ist. Theore-

tisch können bis zu 255 Records und damit bis zu 255 Nummern gespeichert werden, wenn dies nicht vom Kar-

tenherausgeber eingeschränkt wird. In jedem Record wird eine Nummer und ein Alpha Identifier gespeichert.

37

Kapitel 3.1: Das Trägersystem ________________________________________________________________ Zusätzlich zum EFFDN gibt es noch ein fast gleichförmiges EFSDN (Service Dialling Numbers), in dem die Servi-

cenummern des Dienstanbieters verzeichnet sind. Bei EFSDN ist ein Update nur durch ADM möglich.

EFSMS (siehe Annex A, Seite d, Nr.13)

Der Datenteil des EFSMS (Short Message Services) mit der Struktur „linear fixed besteht aus einem 1 byte langen

Statuswort und einem 175 byte langen „Remainder“, der die Kurznachrichten in 7Bit ASCII Codierung je Zei-

chen enthält. Das Statuswort soll unter anderem das SEEK Kommando des ME unterstützen, aber auch geändert

werden, wenn ein neuer Statusbericht eingeht (nicht der Bericht selbst wird hier gespeichert, sondern ein Ver-

weis auf einen neuen Bericht, der in der Datei EFSMSR gespeichert wurde.). Das Remainder-Feld enthält weiter-

gehende Informationen zu Kurznachrichten (s.u.). Zwischen aus dem Netz empfangenen (SMS Mobile Termina-

ted, MT) und von der MS aus verschickten Kurznachrichten wird unterschieden (SMS Mobile Originated, MO).

Bei empfangenen Kurznachrichten wird dokumentiert, ob sie bereits gelesen wurden oder nicht. Zu versendende

Kurznachrichten erhalten das Attribut „to be sent“, bis sie versendet wurden. MO-Kurznachrichten können aus

dem Netz mit einem Statusbericht beantwortet werden. In dem Reminder wird bei MO-Kurznachrichten fest-

gehalten, ob ein Statusbericht angefordert wurde und er eingegangen ist, nicht angefordert wurde, oder angefor-

dert wurde und nicht eingegangen ist.

EFMSISDN (siehe Annex A, Seite e, Nr.14)

Bei diesem EF mit der Struktur Linear fixed handelt es sich um das persönliche Telefonbuch des Benutzers, in

das er seine telefonischen Kontakte einträgt. Es ist in der Form ebenso äquivalent zu EFFDN wie zu EFADN. Der

einzige Unterschied liegt bei den Berechtigungsparametern (siehe Tabelle 7):

EFADN EFFDN EFMSISDN

READ CHV 1 CHV 1 CHV 1 UPDATE CHV 1 CHV 2 CHV 1 INVALIDATE CHV 2 ADM ADM REHABILITATE CHV 2 ADM ADM

Tabelle 7: Unterschiede in der Zugriffsberechtigung bei Rufnummernverzeichnissen

Während das Kurzrufnummernverzeichnis EFADN vollständig vom Benutzer (Eingabe CHV 1, bzw. CHV 2)

verwaltet werden kann, sind die Eingriffsmöglichkeiten des Benutzers bei dem Festrufnummernverzeichnis

EFFDN und dem persönlichen Telefonbuch EFMSISDN auf Lesen und Aktualisieren beschränkt. Ein weiterer Unter-

schied zwischen den Dateien ist das Erweiterungsfile auf das verwiesen wird. Ausschließlich EFFDN verweist auf

EFEXT2, die anderen Dateien verweisen alle auf EFEXT1.

EFLND (siehe Annex A, Seite e, Nr.15)

Während der Aufbau der Datei EFLND optisch den in Tabelle 7 aufgeführten Telefonverzeichnissen gleicht, ist

die Struktur der Datei zyklisch. Die Datei EFLND wird vom Endgerät für die Wahlwiederholung verwendet. In

zyklischen Dateien ist der jüngste Eintrag immer auch der Eintrag mit der niedrigsten Nummer und somit der

Eintrag, auf dem der Zeiger bei einem Aufruf zu Beginn steht. Dadurch wird ein prompter Zugriff auf die zuletzt

gewählte Nummer gesichert. Ein weiterer Unterschied ist die explizite Ablehnung des Befehls INCREASE. Es

erscheint verwunderlich, dass für eine Datei, die ihrem Sinn gemäß genau einen Datensatz aufnehmen soll, näm-

lich die zuletzt gewählte Nummer und die dafür zusätzlich nötigen Daten, entsprechend viel Speicherplatz reser-

viert wird. Tatsächlich merkt die Spezifikation an, dass das X (vgl. Annex A) nicht zwangsläufig dieselbe Größe

haben muss, wie das X in EFADN, EFFDN und EFMSISDN. Wenn nun der Hersteller das File intern auf die Größe

einer einzigen Nummer und somit den dieser Datei zur Verfügung stehenden Speicherplatz beschränkt, so darf

38

Kapitel 3.1: Das Trägersystem ________________________________________________________________ das INCREASE Kommando keinen Speicherfehler herbeiführen können. Durch die getroffene Wahl der Gestalt

des EFs besteht die Möglichkeit, eine beliebige Anzahl von gewählten Nummern abzuspeichern (max. 255).

Sollte eine Nummer inkl. dem zugehörigen Namensstring größer als 20 Digits (10 Byte) sein, verweist der Ex-

tension 1 Record Identifier auf ein Feld im EFEXT1, wo die restlichen benötigten Daten abgelegt sind.

Bei den Instanzen des DFGraphics handelt es sich insofern um eine Kuriosität im Rahmen der auf dem SIM enthal-

tenen Dateien, als hier zwar eine feste Struktur für die einzelnen EFs verzeichnet, aber keine Beschränkung be-

züglich der Anzahl der tatsächlich instanziierten Dateien vorgegeben ist. Es ist theoretisch also möglich, den sehr

beschränkten Speicherplatz der Karte auf diese Weise zu füllen. Letztlich hat nur der Kartenherausgeber (Netz-

betreiber) die Möglichkeit diese Instanzen zu erzeugen. Die Logos anderer Netzbetreiber und auch die, die ein

Benutzer selbst aus dem Netz herunterladen kann, werden im ME gespeichert.

EFIMG (siehe Annex A, Seite f, Nr.16)

Mit Hilfe des EFIMG kann der Netzbetreiber z.B. sein Firmenlogo auf dem SIM ablegen, das dem Benutzer beim

Aktivieren des SIM, im Display angezeigt werden soll. Die Grafik kann in unterschiedlichen Auflösungen oder

Formen auf der Karte gespeichert werden, wofür die einzelnen optionalen Beschreibungsfelder verwendet wer-

den. Das EFIMG enthält nicht die Grafiken selbst, sondern lediglich die notwendigen Steuerdaten (z.B. Auflö-

sung), aus denen das ME dann die richtigen Grafiken auswählt. Die Grafiken selbst werden in den Instanzen des

DFGRAPHICS abgelegt. Das EFIMG kann vom ME nur gelesen werden. Alle Veränderungen obliegen ADM.

EFXYZ , Image Instance Data Files (siehe Annex A, Seite f, Nr.17)

Die Instanzen des DFGRAPHICS enthalten jeweils genau ein Bild, weswegen auch ein einziges Datenfeld ohne wei-

tere Beschreibungen (Beschreibungen stehen in EFIMG) ausreicht. Die Größe der Grafik ist nicht fest vorgegeben.

Die Grafikdatei kann vom Benutzer bzw. dem ME nur gelesen werden.

Weitere Befehle an die Chipkarte

Neben den auf den Seiten 33-34 beschriebenen Anweisungen, die während einer GSM-Session vom ME ausge-

führt werden können, gibt es noch weitere Anweisungen, die in [15] aufgeführt sind und der MS außerhalb einer

GSM Session zusätzlich zum in ISO/IEC 7816 definierten Befehlssatz zur Verfügung stehen.

VERIFY CHV: Wenn die Card Holder Verification Number nicht zuvor deaktiviert oder geblockt wurde, wird

diese Funktion dafür verwendet, sie nach der Eingabe, mit dem Muster auf der Chipkarte zu vergleichen. Bei fal-

scher Eingabe der PIN, unabhängig davon, ob es sich um PIN1 oder PIN2 handelt, wird ein Zähler herunterge-

zählt. Wurde die PIN drei mal falsch eingegeben, soll die CHV-Eingabe geblockt und durch die Eingabe einer

geheimen Nummer (PUK) freigeschaltet werden. Wird die PIN vor dem dritten Fehlversuch korrekt eingegeben,

so wird der Zähler zurück auf den Anfangswert „3“ gesetzt. Wurde die CHV durch dreimalige Fehleingabe ge-

blockt, kann die Zugriffsbedingung CHV1 bzw. CHV2 so lange nicht erfüllt werden, bis der Zähler wieder zu-

rück gesetzt wurde. Als Eingabe erwartet VERIFY CHV kontextabhängig die Übergabe der Nummern CHV1

(PIN1) oder CHV2 (PIN2), es erfolgt keine Ausgabe (vgl. [15], Kapitel 8.9).

CHANGE CHV: Für dieses Kommando, mit dem der Benutzer seine PIN ändern kann, gilt als Bedingung, dass

die CHV-Eingabe weder geblockt noch deaktiviert wurde. Wurde die alte CHV korrekt übergeben, wird der Zäh-

ler auf sein Ursprungsniveau (3) gesetzt und Die neue PIN wird nach Eingabe erst dann aktiviert, wenn sie von

39

Kapitel 3.1: Das Trägersystem ________________________________________________________________ der alten bestätigt wurde. Bei Falscheingabe der alten PIN wird der Zähler herunter gezählt und die CHV wird

nicht verändert. Es gibt keinen Output und als Eingaben werden die alte und die neue PIN, sowie eine Angabe

welche CHV geändert werden soll, erwartet (vgl. [15], Kapitel 8.10).

DISABLE CHV: Dieses Kommando kann nur auf CHV1 angewendet werden. Die Deaktivierung der PIN1-

Eingabe bewirkt, dass auf alle Dateien die als Zugriffvoraussetzung die Eingabe der CHV1 erfordern ohne Ein-

schränkungen zugegriffen werden kann, als stünde dort ALWAYS als Zugriffsbedingung. Die Funktion wird

nicht ausgeführt, wenn die CHV1 bereits deaktiviert oder durch Fehleingabe blockiert wurde. Nach erfolgreicher

Bestätigung mit der CHV1 wird die erzwungene Eingabe der CHV1 deaktiviert, anderenfalls wird der Zähler

heruntergezählt. Eine Ausgabe erfolgt nicht (vgl. [15], Kapitel 8.11).

ENABLE CHV: Dies ist die Umkehrfunktion zu DISABLE CHV1. Es gelten dieselben Bedingungen (vgl. [15],

Kapitel 8.12).

UNBLOCK CHV: Wurde die CHV durch drei Fehleingaben geblockt, ist sie wieder frei zu schalten. Die Un-

block CHV Nummer entspricht bei D1 der sogenannten PUK. Je nachdem ob CHV1 oder CHV2 freigeschaltet

werden müssen, wird PUK1 oder PUK2 verwendet. Ist die Eingabe der PUK korrekt, so wird der CHV Zähler

wieder auf 3 gesetzt. Ist sie nicht korrekt, so wird ein Zähler, der bei 10 initialisiert wurde, je Fehlversuch um 1

(permanent) heruntergezählt. Nachdem die PUK 10 mal falsch eingegeben wurde, wird sie auf Dauer gesperrt.

Der Kartenherausgeber muss eine neue Karte herausgeben. Eine geblockte PUK wirkt sich nicht auf eine unge-

blockte CHV aus, kann jedoch nicht mehr zum Freischalten einer geblockten CHV verwendet werden. Als Ein-

gabe werden die Angabe, welche CHV freigeschaltet werden soll und die Eingabe der entsprechenden PUK

erwartet, sowie eine anschließende Eingabe der neuen CHV, die auch mit der Alten übereinstimmen darf. Eine

Ausgabe erfolgt nicht. (vgl. [15], Kapitel 8.13)

RUN GSM ALGORITHM: Der wesentliche Teil der GSM-Login-Prozedur, wird durch diese Funktion reali-

siert. Sie dient der Authentisierung der SIM-Karte gegenüber dem Netz und gleichzeitig zur Berechnung des

Schlüssels Kc. Die Eingabe erfolgt aus dem Netz und ist eine 16 Bit Zufallszahl und als Ausgabe werden der

Schlüssel Kc eine unterschriebene Antwort vom SIM an das Netz mit der Bezeichnung SRES (Signed Response)

erzeugt. Bevor diese Funktion ausgeführt werden kann, muss das ME entweder das DFGSM , oder eine Unterdatei

dieses DF aufgerufen haben, und die CHV1 muss eingegeben worden sein (vgl. [15], Kapitel 8.16).

SLEEP: SLEEP ist ein veraltetes Kommando, dass ausschließlich von Phase-1-SIMs verwendet wird. Das

Kommando versetzt das ME in einen Wartezustand um das SIM aktiv zu halten, obwohl es nichts tut. Als Ersatz

zu dem Kommando, hat SAT eine vergleichbare Funktionalität mit der Proactive SIM-Anweisung MORE TIME.

TERMINAL PROFILE: Dieses Kommandos zeigt dem SIM an, welche SAT-Features das ME unterstützt. Als

Eingabe wird das ME-Profil erwartet, eine Rückgabe vom SIM gibt es nicht (vgl. [15] 8.18).

ENVELOPE: Anhand der ENVELOPE Anweisung leitet das ME dem SIM Daten weiter, die für das SAT be-

stimmt sind. SAT ist zwar nur ein erweiterter Befehlssatz im SIM, wird aber als eigenständige Einheit betrachtet.

In der Konsequenz werden SAT-spezifische Anweisungen auch an das SAT adressiert. Die Eingabe ist ein Da-

tenstring und die Ausgabe entspricht der in TS 11.14 (siehe Kapitel 4) spezifizierten Form (vgl. dazu [15], 8.19).

FETCH: Mit FETCH holt das ME vom SIM eine SAT-Anweisung ab (siehe Kapitel 4). Es werden keine weite-

ren Parameter übergeben. Die Rückgabe ist eine Anweisung vom SIM (vgl. [15], Kapitel 8.20).

TERMINAL RESPONSE: TERMINAL RESPONSE ist die Bestätigung an das SIM, dass eine mit FETCH

abgeholte Anweisung abgearbeitet wurde. Als Input liefert das ME einen String, der die Antwort enthält, eine

Rückgabe vom SIM gibt es nicht. (vgl. [15], 8,21).

40

Kapitel 3.1: Das Trägersystem ________________________________________________________________ Befehlsstruktur:

Im Folgenden werden die Applikation Protocol Data Units in ihrer Struktur analysiert. Sie entsprechen der in

ISO/IEC 7816-3 spezifizierten Form (vgl. dazu [15], Kapitel 9). Kommando APDUs bestehen aus einem Klas-

senbyte, einem Anweisungsbyte, drei Parametern und einem Datenfeld (vgl. Kapitel 2.3):

In dem Klassenbyte steht der Typ der Anweisung. Jede GSM-Anwendung wird in diesem Feld mit dem Wert

’A0’ angezeigt. Das Anweisungs-Feld „INS“ enthält die eigentliche Anweisung, z.B. für SEEK, ’A2’.

COMMAND INS P1 P2 P3 S/R SELECT ’A4’ ‘00’ ‘00’ ‘02’ S/R STATUS ’F2’ ’00’ ’00’ lgth R READ BINARY ’B0’ offset high offset low lgth R UPDATE BINARY ’D6’ offset high offset low lgth S READ RECORD ’B2’ rec. No mode lgth R UPDATE RECORD ‘DC’ rec. No mode lgth S SEEK ’A2’ `00` type/mode lgth S/R INCREASE ‘32’ `00` `00` `03` S/R VERIFY CHV ‘20’ `00` CHV No `08` S CHANGE CHV ‘24’ `00` CHV No `10` S DISABLE CHV ‘26’ `00` `01` `08` S ENABLE CHV ‘28’ `00` `01` `08` S UNBLOCK CHV ‘2C’ `00` `00` / `02`, CHV1/2 `10` S INVALIDATE ‘04’ `00` `00` `00` - REHABILITATE ‘44’ `00` `00` `00` - RUN GSM ALGORITHM ‘88’ `00` `00` `10` S/R SLEEP ‘FA’ `00` `00` `00` - GET RESPONSE ‘C0’ `00` `00` lgth R TERMINAL PROFILE ‘10’ `00` `00` lgth S ENVELOPE ‘C2’ `00` `00` lgth S/R FETCH ‘12’ `00` `00` lgth R TERMINAL RESPONSE ‘14’ `00` `00` lgth S

Tabelle 8: Kodierung der einzelnen Kommandos (vgl. Tabelle 9 in [15], Kapitel 9.2)

Anmerkung zur obigen Tabelle 8: S (send), S/R und R (receive) stehen für die Senderichtungen aus Sicht des

ME. Mit S bezeichnete Datenpakete werden vom ME aus versendet (siehe [15], Kapitel 9.2, 1. Satz)

Die Response APDU des SIM besteht aus den in Kapitel 2.3 beschriebenen drei Teilen: Einem Datenfeld, in dem

die Antwortdaten an das ME enthalten sind (z.B. der Inhalt eines EFs oder der berechnete Schlüssel Kc), sowie

zwei Statusworten.

Mit Hilfe der Statusworte signalisiert das SIM dem ME primär die erfolgreiche Abarbeitung der in der vorange-

gangenen Kommando APDU codierten Anweisung, bzw. den Grund des Fehlers (nach ISO/IEC 7816-3). Seit

der Einführung von SAT werden die Statusworte auch dazu genutzt mitzuteilen, dass das SIM Daten für das ME

bereithält, und Letzteres sich diese mit dem FETCH Kommando abholen soll (siehe Kapitel 5).

Die Beschreibungen der einzelnen Befehle gemäß ihrer zu übertragenden APDUs steht in [15] Kapitel 9.2.

Eine vollständige Liste aller möglichen Statusworte, die in einer Response APDU übergeben werden können,

sind in [15] Kapitel 9.4 aufgelistet.

41

Kapitel 3.2: Sicherheitsrelevante Prozesse des SIM ________________________________________________________________

3.2 Sicherheitsrelevante Prozesse des SIM Anforderungen*1:

• Sicherung insbesondere kundenspezifischer Daten vor unberechtigter Veränderung, Löschung und un-

berechtigtem Zugriff durch Speicherung dieser Daten auf dem SIM und Realisierung unterschiedlicher

Abstufungen von Zugriffsrechten (siehe. Kapitel 3.1)

• Sicherung von geheimen Schlüsseln durch eingeschränkte Zugriffsrechte (EFKC siehe 3.1)

• Sicherstellung der Zugriffsberechtigung durch Authentisierung des Benutzers gegenüber SIM und Netz

• Sichere Datenübertragung über die Luftschnittstelle

• Sicherung des Endgeräts vor Missbrauch (CHV1, CHV2 Prozeduren, siehe Kapitel 3.1)

• Sicherung des SIM vor Entfernung der Karte aus dem ME nach erfolgter Login-Prozedur

• Sicherstellung der Anonymität des Benutzers während bestehender Verbindungen (durch Verwendung

der TMSI zur Identifikation anstelle der IMSI, siehe Kapitel 2.1)

Implementierung:

Die SIM-Initialisierungsprozedur: An dieser Stelle wird die SIM-Initialisierungsprozedur erläutert, wie sie zwischen ME und SIM-Karte stattfindet

und in TS 11.11 [15], Kapitel 11.3 beschrieben wird. Eine Reihe weiterer Instanzen des GSM-Netzes spielen da-

bei eine wesentliche Rolle, insbesondere bei den Prozessen zur Authentisierung und Verschlüsselung, die in den

Absätzen weiter unten erläutert werden. Da der Schwerpunkt dieser Arbeit nicht auf den Netzprozessen allge-

mein liegt, werden die weiteren Netzkomponenten nur am Rande behandelt.

Die SIM-Initialisierung beginnt mit dem Einlegen der Chipkarte und dem darauf folgenden Anschalten des End-

geräts. Der Benutzer muss (wenn dies nicht in einer vorherigen Sitzung deaktiviert wurde) seine PIN eingeben

und hört dann etwas zeitverzögert einen durch den Lautsprecher des ME ausgegebenen Piepton. Mit diesem

Piepton ist die MS (ME + SIM) erfolgreich in das PLMN eingebucht.

Unmittelbar nach dem Einschalten der MS liest das ME die Notfallnummern des EFECC aus, falls es verfügbar

sind und wählt (SELECT) im nächsten Schritt das Verzeichnis DFGSM. Im Verzeichnisbaum des DFGSM lässt sich

das ME zunächst die Daten des EFELP übergeben und stellt ggf. seine Spracheinstellungen entsprechend um. Die

Datei EFLP im Wurzelverzeichnisses des SIM wird zu selbem Zwecke nur dann angefordert, wenn das EFELP

entweder keine verwertbaren Daten enthält, nicht vorhanden ist oder das ME keine in dieser Datei verzeichnete

Sprache unterstützt. Sind beide Dateien (EFELP und EFLP) nicht vorhanden oder das ME unterstützt keine der

vorgegebenen Sprachen, so verwendet es seine eigene Standardsprache (i.d.R. Englisch).

Nun wird die CHV1 (PIN 1) Prozedur gestartet. War die Verifizierung erfolgreich - die vom Benutzer eingege-

bene PIN war korrekt oder die Abfrage der CHV 1 wurde zuvor deaktiviert - fordert das ME die Daten des

EFPHASE an, um die Phase des SIM herauszufinden. Handelt es sich dabei um ein Phase-2-SIM und verlangt es

einen PROFILE DOWNLOAD, so wird dieser zunächst durchgeführt und das SIM wird über die Fähigkeiten

des ME unterrichtet.

Sind die Dateien EFIMSI und EFLOKI nicht invalidiert, so wird die Prozedur weitergeführt. Sind sie invalidiert, so

werden sie zunächst rehabilitiert, sofern das ME über die entsprechende Autorisierung (s.u.) verfügt. Konnte die

*1 Die Anforderungsliste wurde aus den in [15], Kapitel 7 beschriebenen Funktionen abgeleitet.

42

Kapitel 3.2: Sicherheitsrelevante Prozesse des SIM ________________________________________________________________ CHV 1 nicht rehabilitiert werden, so wird die Prozedur abgebrochen und es kommt zu keiner GSM Session.

Liegt ein Phase-1-SIM vor, werd der PROFILE DOWNLOAD übersprungen.

Des Weiteren laufen folgende Prozeduren ab:

• Administrative Information request: das ME liest die Datei EFAD aus

• SIM Service Table request: die READ Prozedur auf das EFSST wird ausgeführt

• IMSI request: EFIMSI wird gelesen

• Access Control request: EFACC wird gelesen

• HPLMN Search Period request: EFHPLMN wird gelesen

• Investigation scan request: wenn Dienst Nr. 47 aktiviert ist, wird EFInvScan gelesen

• PLMN selector request: wenn im EFSST Dienst Nr. 7 aktiviert ist, wird EFPLMN gelesen

• HPLMN selector with Access Technology request: wenn Dienst Nr. 45 aktiviert ist, wird EFHPLMNAcT

gelesen

• User Control PLMN selector with Access Technology request: wenn Dienst Nr. 43 aktiv ist, wird

EFPLMNwAcT gelesen

• Operator controlled PLMN selector with Access Technology request: Dienst Nr. 44, EFOPLMNwAcT

• RPLMN last used access technology request: Dienst Nr. 50, EFRPLMNAcT

• Location Information request: EFLOCI wird gelesen

• Cipher key request: das ME führt erst die READ Anweisung und dann die UPDATE Prozedur mit

dem EFKc durch

• BCCH information request: nach READ folgt UPDATE Prozedur mit dem EFBCCH, der ggf. neue

Broadcastkanal wird eingetragen

• CPBCCH information request: wenn Dienst 46 aktiv ist, wird EFCPBCCH gelesen

• Forbidden PLMN request: das EFPLMN wird zunächst gelesen und dann aktualisiert

• LSA information request: das ME liest zunächst die Dateien EFSAI und EFSLL sowie die zugehörigen

beschreibenden LSA (was ist LSA?) Dateien und führt dann die UPDATE Prozedur auf dem EFSLL

durch

• CBMID request: falls Dienst Nr. 14 aktiv ist, wird der Cell broadcast message identifier im EFCBMI

ausgelesen

• Depersonalisation Control Keys request: sofern der Dienst Nr. 33 aktiv ist, wird EFDCK gelesen

• Network’s indication of alerting request: wenn Dienst Nr.36 aktiv ist, wird EFNIA gelesen

Nachdem diese Prozeduren erfolgreich abgelaufen sind, gilt das Endgerät als aktiviert und ist im Netz einge-

bucht. Ist laut SIM Service Table (EFSST) Proactive SIM aktiviert worden und unterstützt das ME diesen Dienst,

so muss das ME mindestens alle 30 Sekunden eine Abfrage nach Anweisungen (STATUS) an das SIM richten.

Dies geschieht unabhängig davon, ob gerade eine Gesprächsverbindung besteht oder das SIM sich im Ruhezu-

stand befindet. Die Zeitdauer für die Statusabfrage kann insbesondere im Ruhezustand des SIM verkürzt werden.

Der Authentisierungsprozess und die Verschlüsselungsprozedur (vgl. Abbildung 49): Der Authentisierungsprozess beinhaltet eine Reihe von einzelnen Funktionen und ist fester Bestandteil der SIM

Initialisierungsprozedur. An dieser Stelle wird die Methode diskutiert, mit deren Hilfe sich die SIM Karte bei der

43

Kapitel 3.2: Sicherheitsrelevante Prozesse des SIM ________________________________________________________________ Einwahl gegenüber dem Netz authentisiert. Die Methode, mit der sich der Benutzer gegenüber der SIM Karte

authentisiert wurde bereits im Kapitel 3.1 anhand der Funktionen VERIFY CHV, CHANGE CHV, DISABLE

CHV, ENABLE CHV und UNBLOCK CHV eingehend erläutert.

Einleitend wählt das ME zunächst das DFGSM und verwendet dann die RUN GSM ALGORITHM Funktion (vgl.

Kapitel 3.1). Bei der Ermittlung des Schlüssels KC und der unterschriebenen Rückantwort SRES wird als Initiali-

sierungsvektor ein auf der Chipkarte fest gespeicherter, geheimer aber fester Schlüssel Ki (128 Bit) verwendet,

der auch dem Ac vorliegt. Das Netz (AC) schickt, nachdem es vom ME die TMSI (aus der TMSI kann netzintern

die IMSI abgeleitet werden) bzw. IMSI erhalten hat, eine Zufallszahl RAND an das ME, die es an das SIM wei-

terreicht. Das SIM wendet die Algorithmen A3 und A8 auf diese Zufallszahl an, wobei es die Zufallszahl als

Klartextblock betrachtet und den Initialisierungsvektor Ki verwendet. Das SIM ermittelt auf diese Weise den ak-

tuellen Schlüssel KC (Algorithmus A8) sowie eine unterschriebene Antwort SRES (Algorithmus A3), die wieder

an das Netz zurückgeschickt wird. Das Netz seinerseits berechnet ebenfalls und mit gleicher Vorschrift SRES

und KC aus der Zufallszahl und dem Initialisierungsvektor Ki. Sobald die unterschriebene Antwort SRES vom

ME im Netz eingegangen ist, werden die beiden individuell berechneten Werte auf Übereinstimmung verglichen

(im AC); die MS wurde authentisiert. Da das SIM aufgrund mangelnder Rechenleistung nicht in der Lage ist, in

Echtzeit zu verschlüsseln, fordert das ME den Schlüssel KC vom SIM an, mit dem es alle weiteren Daten, die

über die Luftschnittstelle versendet werden, verschlüsselt. Ebenso verwendet das Netz den Schlüssel KC zur Ver-

schlüsselung der Gesprächsdaten über die Luftschnittstelle. Der nun im ME enthaltene Schlüssel KC wird spätes-

tens mit dem Abschalten des Endgeräts bzw. dem Entfernen der Karte gelöscht.

Durch dieses System kann zum einen die Identität des Benutzers auf der Luftschnittstelle verifiziert, aber den-

noch weitestgehend (durch Verwendung der TMSI, falls vorhanden) geheim gehalten werden, und zum anderen

wird ein Schlüssel zur Verschlüsselung der Gesprächsdaten über die Luftschnittstelle erzeugt, ohne ihn jemals

im Klartext zu übertragen. Diese Prozedur findet in regelmäßigen Abständen und zu jedem Location Update

immer wieder statt, so dass nie für lange Zeit der gleiche Schlüssel KC verwendet wird. Für die Verschlüsselung

und Entschlüsselung der Gesprächsdaten über die Luftschnittstelle wird der Algorithmus A5 verwendet. Der ak-

tuelle Schlüssel KC wird auf dem SIM im EFKC gespeichert (vgl. Kapitel 3.1, EFKC).

Im Handbuch der Chipkarten [B] kann in Kapitel 13.5 Abbildung 13.8 der Ablauf der Schlüsselerzeugung und

Verschlüsselung der Gesprächsdaten anhand eines Diagramms nachvollzogen werden.

Sicherung des SIM vor Entfernung der Karte aus dem ME: (TS 11.11, 11.2.8)

Damit nicht das SIM während einer bestehenden GSM-Session aus dem ME entfernt werden kann, sendet das

ME auch bei Phase-1-SIM regelmäßig während bestehenden Gesprächsverbindungen das STATUS Kommando

an das SIM. Erhält das ME nicht augenblicklich eine Antwort oder entspricht die Antwort nicht der erwarteten

(sie stammt z.B. von einer anderen SIM Karte), muss es binnen 5 Sekunden das Gespräch beenden. Diese Proze-

dur ist zusätzlich zu einer mechanischen Sicherung implementiert (vgl. TS 11.11, Kapitel 11.2.8).

44

Kapitel 4: SAT: Phase 2 - Eine funktionale Erweiterung des SIM ________________________________________________________________

4 SAT: Phase 2 - Eine funktionale Erweiterung des SIM

Wie bereits in Kapitel 3 erläutert wurde, ist das SIM Application Toolkit weder ein weiteres Modul, das auf der

Chipkarte integriert wurde, noch beinhaltet es neue Elementary Files. Es ist vielmehr als eine Erweiterung des

Befehlssatzes für SIM und ME zu sehen, mit dessen Hilfe einige neue Mechanismen umgesetzt werden, die u.a.

dem SIM ermöglichen, mit dem ME zu interagieren (vorher konnte es nur reagieren).

Die für SAT „relevanten“ Daten findet man primär in der international geltenden Spezifikation [16] des Third

Generation Partnership Projects: TS 11.14. Einige Zusammenhänge wurden zur selben Zeit parallel in einer neu-

en Version der SIM-Spezifikation dokumentiert.

In diesem Kapitel wird die SAT-Spezifikation 11.14 Release 99 als Quelle verwendet. Die Features des SAT

werden in Unterkapitel 4.1 aufgelistet und bzgl. ihrer Funktionsweise in Unterkapitel 4.2 diskutiert.

4.1 Zusätzlicher Funktionsumfang Der Leistungsumfang von SAT kann anhand einer Liste von Anforderungen beschrieben werden, die aus den

einzelnen in der Spec. [16] beschriebenen Funktionen herausinterpretiert wurde:

Anforderungen:

• Feststellen des ME-Leistungsumfangs durch das SIM

• Erweiterung des SIMs um die Fähigkeit (indirekt) Anweisungen an das ME zu erteilen

• Kontrolle möglichst aller benutzer- und gesprächsabhängigen Aktionen durch das SIM

• Möglichkeit, das SIM direkt über das Netz an neue Dienste anzupassen (Data Download to the SIM)

• Für den Benutzer transparente (bzgl. Ihrer Herkunft) Darstellung von Menüs auf dem Display des ME,

die auf dem SIM gespeichert sind und transparente Integration einzelner Menüpunkte aus dem SIM zur

Erweiterung der im ME vorhandenen Menüstrukturen

• Einführung eines Mechanismus, mit dem das ME der SAT-Anwendung direkt Anweisungen erteilen

kann, ohne dass das SIM diese zuvor interpretiert (ENVELOPE)

• Meldung aller in einer Liste (EVENT) definierten Ereignisse an das SIM

• Setzen, Steuerung und Aktivierung von Timern durch das SIM

Umgesetzt wurde diese Liste durch die folgenden Funktionalitäten:

• Profile Download: Der Profile Download stellt einen Mechanismus (vgl. [16], Kapitel 4.1) zur Verfü-

gung, der es dem ME ermöglicht, dem SIM mitzuteilen, über welche Fähigkeiten es verfügt. Die Fähig-

keiten des SIM sind dem ME bekannt, da es Zugriff auf die Dateien EFPhase und EFSST, verfügt. (vgl.

[16], Kapitel 5)

• Proactive SIM: Mit Hilfe des Proactive SIM Mechanismus wird das Master-Slave-Problem zwischen

Terminal und Chipkarte umgangen, das durch die genaue Umsetzung der ISO/IEC 7816-3 Spezifikation

entstanden ist. Soll das SIM in irgendeiner Form Handlungen initialisieren können, so ist ihm zunächst

45

Kapitel 4.1: Zusätzlicher Funktionsumfang ________________________________________________________________ eine Möglichkeit einzuräumen, wie es eine Kommunikation zum ME aufbauen (indirekt: veranlassen) kann (vgl. [16], Kapitel 6).

• Data Download to the SIM: Der Data Download to the SIM ermöglicht dem Netzbetreiber, Verände-

rungen an den Daten der SIM Karte aus dem Netz heraus vorzunehmen. Vor der Einführung dieses Fea-

tures, hätte der Netzbetreiber alle Karten einziehen müssen, um einen neuen Dienst mit Kartenunter-

stützung implementieren zu können (vgl. [16], Kapitel 7).

• Menu Selection: Menu Selection übergibt im SIM gespeicherte Benutzer-Auswahl-Optionen an das

ME, das diese wiederum in eigene Menüstrukturen integriert, so dass die Quelle der einzelnen Menü-

punkte für den Benutzer nicht erkennbar ist (vgl. [16], Kapitel 8).

• Call Control by the SIM: Mit der Einführung von SAT wird jeder Verbindungsauf- und -abbau vom

SIM überwacht und genehmigt oder verweigert. Insbesondere für eingeschränkt funktionsfähige Endge-

räte (z.B. durch Eltern auf bestimmte Rufnummern beschränkte Endgeräte ihrer Kinder) ist dieses Fea-

ture sehr wichtig (vgl. [16], Kapitel 9.1).

• MO Short Message control by the SIM: Ebenso wie Verbindungen wird auch das Verschicken von

Kurznachrichten vom SIM kontrolliert und ggf. eingeschränkt (vgl. [16], Kapitel 9.2).

• Event Download: Der Event Download umfasst eine Vielzahl von einzelnen, anwendungsspezifischen

Nachrichten, die an das SIM übergeben werden, wenn in einer Tabelle definierte Ereignisse beim ME

auftreten. Diese Nachrichten dienen u.a. als Werkzeuge, mit deren Hilfe Funktionen wie Call Control

by the SIM oder Menu Selection eingeleitet werden (vgl. [16], Kapitel 11).

• Timer Expiration: Hierbei handelt es sich um einen Mechanismus, der dem ME ermöglicht dem SIM

mitzuteilen, dass ein vom SIM initialisierter Timer abgelaufen ist (vgl. [16], Kapitel 10).

4.2 Wirkungsweise der neuen Funktionen Profile Download:

Der Profile Download ist ein Mechanismus (vgl. [16], Kapitel 4.1) mit dem das ME dem SIM mitteilt, über wel-

che Fähigkeiten es verfügt. Die Fähigkeiten des SIM sind dem ME bekannt, da es Zugriff auf die Dateien EFPhase

und EFSST hat.

Mit der Implementierung von SAT wurde dem SIM indirekt eine bidirektionale Handlungsfähigkeit verliehen.

Bis dahin diente es, von der Schlüsselgenerierung und Verschlüsselungsprozedur abgesehen, als reiner Daten-

speicher. Um überhaupt Anweisungen an das ME zu schicken, die dort auch verarbeitet werden können, muss

das SIM zunächst wissen, welche Funktionen das ME unterstützt. Es wäre durchaus denkbar, dass ein SAT-

fähiges SIM in ein Phase-1-Endgerät eingebaut wird. In diesem Fall könnte das Endgerät mit diversen, in diesem

Kapitel angesprochenen Statusmeldungen und Nachrichten des SIMs nichts anfangen und würde schlimmsten-

falls sogar in einen inkonsistenten Zustand gelangen. Um dies sicher zu vermeiden, teilt das ME dem SIM im

Rahmen des Initialisierungsprozesses mit, welche Nachrichten es verstehen und welche Anweisungen es ausfüh-

ren kann. In der Initialisierungsprozedur liest das ME zunächst die Datei EFPHASE ein. Wenn in diesem File ein

Hinweis darauf enthalten ist, dass das SIM Informationen über die Leistungsfähigkeit des ME benötigt, wird es

das ME anweisen die Profile Download Prozedur einzuleiten, nachdem zuvor die CHV, nicht aber EFLOCI und

EFIMSI übergeben wurden.

46

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ Das ME antwortet mit dem Kommando TERMINAL PROFILE und übergibt die notwendigen Daten. Sollte das

ME auf die Forderung des SIM nicht reagieren, weiß das SIM nach Ablauf einer Frist (timeout), dass das ME

SAT nicht unterstützt und merkt sich dies bis zu seiner Deaktivierung (Ausschalten des ME).

Der Datenteil der Anweisung TERMINAL PROFILE besteht aus einer erweiterbaren Sequenz von 20 definierten

Bytes, in denen je Bit binär die Unterstützung eines SAT Dienstes kodiert ist. Diese Belegung der Einzelbits

kann in der TS 11.14 [16] im Kapitel 5.2 explizit nachgelesen. Als Beispiel wird hier das 16te Byte dargestellt:

Text scrolling as defined in 5.3.3

Width reduction when in a menu as defined in 5.3.3

RFU

Text wrapping supported as defined in 5.3.4

Display can be resized as defined in 5.3.3

b8 b7 b6 b5 b4 b3 b2 b1

Abbildung 38: Das 16. Byte des Terminal Profile Kommandos (aus Kapitel 3.5, [16] ) die in der Abb. angegebenen Kapitelnummern entsprechen den Kapiteln der Spezifikation)

In dem Byte 16 definiert das Terminal Profile Kommando die Darstellungsfähigkeiten des ME. Ergänzende In-

formationen dazu sind vereinzelt auch noch in den Bytes 14 und 15 enthalten. Die restlichen Bytes enthalten

primär Informationen zur Verfügbarkeit von Diensten bzgl. Proactive SIM und Event-Handling, aber auch An-

gaben, welche zusätzlichen Protokolle unterstützt werden (Byte 17, TCP/IP, UDP) und ob das Endgerät GPRS

unterstützt. Byte 18 und das erste „Subsequent byte“ (Folgebyte) 20 sind vollständig für zukünftige Anweisun-

gen reserviert.

Bit b1 beinhaltet die Möglichkeit des Benutzers, die Anzahl der auf dem Display dargestellten Zeichen in einer

Zeile und die Anzahl der Zeilen pro Bildschirm festzulegen, bzw. die Fähigkeit des ME, dies dynamisch zu rea-

lisieren. Das Text-wrapping in b2 soll eine Aufsplittung von Worten aufgrund der beschränkten Zeilenlänge im

Display des ME durch verschieben zu langer Worte in die Folgezeile vermeiden indem die Worte, vorausgesetzt

sie übersteigen nicht ohnehin die maximale Anzahl Zeichen einer Zeile, als ganzes verschoben werden. Der in

b3 betroffene Effekt dient der besseren Darstellung gesplitteter Worte. Ist ein einzelnes Wort länger als in einer

Zeile darstellbar wäre, so muss es in zwei Zeilen dargestellt werden. Es ist nun denkbar, dass solch ein aufgeteil-

tes Wort gerade am Ende einer darstellbaren Bildschirmseite beginnt und das Ende des Wortes erst auf der

nächsten Seite sichtbar ist. Die Scrollfunktion des ME soll gewährleisten, dass wenn der Benutzer auf das be-

stimmte Wort scrollt, es vollständig (beide Zeilen) auf dem Display erscheint, indem der sichtbare Bereich des

Textes automatisch um eine Zeile „hochgescrollt“ wird. Die Bits b4 und b5 sind für künftige Anwendungen re-

serviert worden und die letzten drei Bit des 16ten Bytes geben an, wie viele Zeichen auf dem Display einem

DISPLAY TEXT (proactive command) ohne Scrollen zur Verfügung stehen.

Proactive SIM:

Proactive SIM ist das bedeutendste Feature, welches mit der Einführung von SAT zur Verfügung steht. Es um-

fasst eine größere Anzahl von Mechanismen (Anweisungen), mit denen das SIM Handlungen anstoßen kann, die

das ME ausführen soll. Angesichts der Tatsache, dass das ME laut der ISO/IEC 7816-3 Spezifikation grundsätz-

lich die Funktion des Masters inne hat und somit das SIM keine Möglichkeit hat, eine Aktion des ME anzusto-

47

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ ßen, handelt es sich bei dem Proactive SIM um einen zunächst sehr kritisch zu betrachtenden Mechanismus, da

eben dies umgangen wird. Proactive SIM ist aus der Notlage heraus entstanden, dass eine strenge ISO/IEC 7816-

3 Konformität die Möglichkeiten, zeitnah neue Features auf dem SIM zu realisieren, stark einschränkt. Schließ-

lich wird durch einen Trick gewährleistet, dass das SIM seine in T=0 (und auch in T=1) spezifizierte Rolle als

Slave weiterspielen und dennoch Anweisungen an das ME absetzen kann. Die Lösung des Problems besteht in

der Einführung neuer Statusworte in der Antwort APDU des SIM. Die neuen Statusworte (SW1 SW2) ’91 XX’

haben zunächst dieselbe Funktion wie das aus dem Übertragungsprotokoll T=0 bekannte Statuswort ’90 00’, also

mitzuteilen, dass alles in Ordnung ist. Sie enthalten aber gleichermaßen eine Mitteilung vom SIM an das ME,

dass es Informationen für das ME bereithalten, die sich das ME mit dem FETCH Kommando abholen soll. Zu-

sätzlich zu den neuen Statusworten lauscht das ME an der Schnittstelle zum SIM in bestimmten (s.u., „Poll In-

terval“) Zeitintervallen, um feststellen zu können, ob das SIM Nachrichten bereithält.

Damit auf keinen Fall Komplikationen auftreten können, darf diese Gruppe von Statusworten ausschließlich

dann verwendet werden, wenn sowohl SIM als auch ME den Mechanismus des Proactive SIM unterstützen.

Eine über ’91 XX’ bzw. dem darauf gefolgten FETCH Kommando des ME erhaltene Anweisung durch das SIM

soll das ME augenblicklich durchführen. Nach der Ausführung soll das SIM anhand eines TERMINAL RES-

PONSE Kommandos über den Ausgang informiert werden (erfolgreich oder warum nicht erfolgreich). Einige

Anweisungen des SIM verlangen vom ME, dass es sich zusätzliche Daten vom SIM abholt. Um diese Daten zu

erhalten, verwendet es die GET RESPONSE Anweisung, wie sie in der TS 11.11 [15] Spezifikation beschrieben

ist. Des Weiteren sollen (vgl. [15] TS 11.11) die Befehle TERMINAL PROFILE, ENVELOPE, FETCH und

TERMINAL RESPONSE auf keinen Fall angewandt werden, wenn nicht sowohl SIM-Karte als auch Endgerät

mindestens Phase 2 entsprechen und beide das SIM Application Toolkit unterstützen.

Die Anweisungen von Proactive SIM:

Insgesamt umfasst dieser Mechanismus die Einführung von 30 neuen Befehlen, die im Folgenden teilweise (s.u.)

dargestellt und diskutiert werden. Diese 30 Befehle können in drei Gruppen unterteilt werden: Einige Anweisun-

gen stehen im direkten Zusammenhang zu der seit SAT bestehenden Möglichkeit, mehrere Karten in ein Endge-

rät einzuführen bzw. Multi-Applikations-Karten zu verwenden (letzteres wurde im Ansatz bereits in SIM TS

11.11 spezifiziert). Diese Funktionen ermöglichen dem ME ein Umschalten auf eine andere, zusätzlich einge-

führte Karte bzw. den Zugriff auf Informationen einer anderen Karte, das Abschalten einer Karte sowie das Ak-

tivieren bzw. die Wahl unterschiedlicher Datenkanäle, etc. Da es z.Z. in Deutschland keine Anwendungen für

diese Funktionen gibt, u.a. weil die MEs auf dem deutschen Markt lediglich den Betrieb einer einzigen Karte un-

terstützen, soll diese besondere Befehlsgruppe im Folgenden keine weitere Beachtung finden.

Die zweite Gruppe von Anweisungen regelt vom SIM gesteuerte Ausgaben auf dem Display und das Anfordern

von Benutzereingaben zur Weiterverarbeitung im SIM. Der dritte Anweisungsblock realisiert Steuerfunktionen.

Die Anweisungen der beiden zuletzt genannten Gruppen werden im Folgenden beschrieben.

Anweisungen zur Ein- und Ausgabesteuerung des SAT:

• DISPLAY TEXT: Dieser mit hoher Priorität ausgestattete Befehl weist das ME an, einen Text auf

dem Display darzustellen. Die hohe Priorität ist notwendig, damit ein ggf. bereits dargestellter Text ü-

berschrieben werden darf. Das SIM kann die Priorität selbst festlegen, es hat die Wahl zwischen norma-

ler und hoher Priorität. Anhand eines Flags, das vom SIM gesetzt wird, kann das ME ableiten (vgl. [16],

48

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

Kapitel 6.4.1), ob die Nachricht nur temporär auf dem Display erscheinen soll (z.B. eine Willkommens-

nachricht beim Einbuchen ins Netz) oder ob eine Reaktion des Benutzers erwartet wird (z.B. bei einer

Menüauswahl). Im ersten Fall soll das ME dem SIM falls auf dem Display bereits etwas anderes als der

Standardtext dargestellt wird mitteilen, dass es zur Zeit beschäftigt ist (TERMINAL RESPONSE: ME

currently unable to process command, screen busy) und die Anweisung nicht ausführen kann. Ist das

Flag auf High Priority gesetzt, so ist der Screen sofort zu überschreiben. Anweisungen, Texte und Icons

darzustellen, können mit einem Zeitstempel (im Sinne einer Frist) versehen sein, wodurch sie nach Ab-

lauf der Frist vom ME durch die Standardausgabe ersetzt werden. Der Benutzer kann die Darstellung zu

einem früheren Zeitpunkt abbrechen, selbst wenn eigentlich eine Eingabe erwartet wird und diese noch

nicht getätigt wurde (TERMINAL RESPONSE: Proactive SIM application session terminated by the

user). Wird eine Eingabe erwartet, aber vom Benutzer keine getätigt, so entscheidet das ME nach Ab-

lauf einer Frist den Abbruch (TERMINAL RESPONSE: No response from user). Will der Benutzer zu

einem vorhergehenden Deck zurück springen, so wird dieses anstelle des Aktuellen angezeigt (TER-

MINAL RESPONSE: Backward move in the proactive SIM session requested by the user). Ein weiteres

Ereignis, in dessen Folge ein Icon oder Text überschrieben werden kann, ist das Eintreffen einer An-

weisung mit höherer Priorität. Ist die Anweisung schließlich vollständig und ordnungsgemäß abgearbei-

tet worden, soll das ME lediglich die Nachricht „TERMINAL RESPONSE: Command performed succ-

sessfully“ an das SIM weiterleiten.

• GET INKEY: Diese Anweisung ermöglicht einen direkten Dialog mit dem Benutzer, in dem sie das

ME anweist, einen Text oder ein Icon auf dem Display anzuzeigen. Als Rückantwort wird ein einzelnes

Zeichen (z.B. y = yes, n = no) erwartet. Sie wird primär für die Menüauswahl verwendet. Der akzeptier-

te Zeichensatz für die Rückgabe ist eingeschränkt und kann aus [16], Kapitel 6.4.2 entnommen werden.

Weitere vom SIM getroffene Einschränkungen der akzeptierten Zeichen (z.B. nur Ziffern) als Rückga-

bewert auf bestimmte Anweisungen, sind vom ME zu überwachen. Für Yes/No Entscheidungen durch

den Benutzer ist vom ME-Hersteller festzulegen, welches Zeichen für Yes und No verwendet werden

soll und dem Benutzer ist dies entsprechend anzuzeigen.

• GET INPUT: Vergleichbar mit GET INKEY erwartet diese Anweisung einen String als Rückgabewert

(kann auch aus einem Zeichen bestehen), z.B. zur Übergabe einer Webadresse. Die Eingabe des Benut-

zers soll transparent an das SIM weitergeleitet werden, ohne dass das ME diese Daten zwischenspei-

chert oder interpretiert. Erwartet das SIM einen standardisierten Text als Rückantwort, so ist dieser dem

Benutzer vom ME entsprechend zur Auswahl zu präsentieren. Wenn für eine bestimmte Entscheidung

eine Hilfeinformation zur Verfügung steht und der Benutzer diese auswählt, so soll das ME ein „TER-

MINAL RESPONSE: help information required by the user“ an das SIM schicken und die entsprechen-

den Daten anfordern (vgl. [16], Kapitel 6.4.3).

• PLAY TONE: Die Anweisung instruiert das ME, einen Ton über ein akustisches Medium, z.B. Kopf-

hörer oder Lautsprecher auszugeben. Das SIM hat zusätzlich die Möglichkeit, dem ME mit dem Kom-

mando PLAY TONE einen Alpha Identifier zu übergeben, so dass das ME zusätzlich ein Icon oder Text

auf dem Display darstellt. Ein Ton als Steuersignal an den Benutzer, der aus dem Netz eintrifft, hat im-

mer höchste Priorität und überlagert alle von SAT und ME initialisierten akustischen Ausgaben.

• SELECT ITEM: Das SIM stellt eine Itemliste zur Verfügung, als Auswahlliste für den Benutzer. Die

Darstellungsform der Liste auf dem Display ist abhängig von der jeweiligen Implementierung des ME.

49

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

Die in der Liste enthaltenen Items können entweder direkt auswählbare Menüpunkte (z.B. eine Tele-

fonnummer eines Telefonregisters) oder übergeordnete Menüstrukturen (z.B. Telefonbuch, Adressbuch,

Termine) sein. Jedem Item ist eine Kurzidentifikationsnummer beigefügt, die dem SIM nach der Aus-

wahl durch den Benutzer weitergereicht wird. Die Menüpunkte können sowohl als reine Textstrings als

auch anhand eines zusätzlichen Icons an das ME übergeben werden. Letztlich entscheidet das ME über

die tatsächliche Darstellungsform (Icon oder Textform). Hat der Benutzer ein Item aus der Liste ausge-

wählt, schickt das ME der SIM Karte ein „TERMINAL RESPONSE: OK“ in Verbindung mit der Kurz-

identifikationsnummer des geforderten Datums oder Dienstes.

Anweisungen mit Steuerfunktionen:

• MORE TIME: Anhand dieser Anweisung kann sich die SAT-Anwendung exklusive Rechenzeit vom

SIM reservieren lassen. In der Konsequenz blockiert diese Anweisung kurzfristig den Prozessor, so dass

er nicht für andere Anweisungen genutzt werden kann. Es werden keine Rückgaben vom ME erwartet,

außer einer möglichst sofortigen, kurzen Empfangsbestätigung (TERMINAL RESPONSE: OK), mit

dem das ME bestätigt, innerhalb der definierten Zeit keine Anweisungen niederer Priorität an das SIM

weiterzuleiten. Für das Netz zeitsensitive Instruktionen, wie die Login Prozedur werden nach wie vor

an das SIM weitergeleitet. Das MORE TIME Kommando ermöglicht vermeidet den Abbruch einer SIM

Prozedur durch Time-out und ersetzt den in [15] spezifizierten SLEEP Befehl (vgl. [16], Kapitel 6.4.4).

• POLL INTERVALL: Mit diesem Kommando wird das Zeitintervall ausgehandelt, nach dem das ME

die Statusabfragen an das SIM richtet. Nachdem das SIM dem ME ein Poll Intervall mitgeteilt hat, prüft

das ME zunächst, ob es diese Häufigkeit unterstützt. Ist die gewünschte Häufigkeit für das ME Reali-

sierbaren, so erhält das SIM eine Bestätigung. Falls diese Häufigkeit nicht unterstützt wird, sendet das

ME dem SIM die maximale unterstützte Pollingrate, die sich am nächsten unterhalb der geforderten be-

findet (vgl. [16], Kapitel 6.4.6). Mit der Anweisung POLLING OFF kann das Polling generell abge-

schaltet werden. Abgesehen von der SIM presence detection Prozedur werden dann keine weiteren Sta-

tusabfragen gemacht. Die Statusabfragen nach APDU-Übertragungen werden weiterhin durchgeführt,

lediglich auf Abfragen in „den Ruhezeiten“ des SIM wird verzichtet (vgl. [16], Kapitel 6.4.14).

• REFRESH: Anhand dieser Anweisung kann das SAT u.a. ein SIM-Reset vom ME erzwingen. Sie kann

aber auch verwendet werden, wenn sich der Dateninhalt oder die Struktur eines oder mehrerer EFs ge-

ändert hat und dadurch ein erneutes Einlesen der betroffenen EFs notwendig ist. Im Falle eines SIM-

Reset wird die GSM-Session terminiert und anschließend vom ME neu initialisiert (vgl. [16], Kapitel

6.4.7), wobei die PIN (CHV1) vom Benutzer auch abgefragt wird. Bei der SIM-Initialisierung auf-

grund von geänderten Daten auf der Karte beginnt der Vorgang nach der CHV1 Übergabe. Es soll kein

elektrisches Reset stattfinden weshalb die PIN auch nicht erneut eingegeben werden soll. Die

REFRESH Anweisung besitzt keine hohe Priorität, so dass in Fällen, in denen diese Anweisung erteilt

wird und z.B. gerade eine Gesprächsverbindung aktiv ist, das ME den sofortigen Refresh mit einem

„TERMINAL RESPONSE ME currently unable to process command – currently busy on call“ verwei-

gern kann. Das REFRESH Kommando dient primär dem Datenabgleich: Viele Endgeräte kopieren ei-

nige EFs einer SIM-Karte temporär in den eigenen Speicher, so dass sie die Prozesse beschleunigen

können. Mit dem REFRESH Kommando kann das ME die EFs auf den neuesten Stand bringen. Ver-

50

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

weigert das ME die Ausführung der REFRESH Anweisung, soll das SIM den Polling Intervall herun-

tersetzen (POLL INTERVALL), so dass das ME möglichst zeitnah neue Informationen erhält.

• SEND DTMF: Dieses Kommando veranlasst das ME einen DTMF (Dual Tone Multiple Frequency)

während einer bestehenden Verbindung zu senden. Diese Anweisung wird nur dann ausgeführt, wenn

bereits eine bestehende Verbindung existiert; andernfalls soll sie mit dem SET UP CALL Kommando

übergeben werden. Der Benutzer muss in der Lage sein, diese Anweisung zu deaktivieren, damit er ggf.

dadurch nicht gestört wird (vgl. [16], Kapitel 6.4.24).

• SET UP CALL: Die Anweisung dient dazu, eine vom SAT angeforderte Verbindung aufzubauen. Es

gibt für eine solche Anweisung drei Parameter: (1) Die Anweisung wird nur dann ausgeführt, wenn

noch keine Verbindung besteht bzw. das ME nicht anderweitig beschäftigt ist, (2) bestehende Verbin-

dungen werden geparkt oder (3) sie werden ausgelöst. Die Parameter werden mit der Anweisung vom

SIM übergeben. Es ist möglich, dass das SIM Parameter zur „Wiederwahl bei besetzt“ mit übergibt. In

jedem Fall sollte das ME jedoch einmalig die Nummer wählen, falls die entsprechenden Parameter be-

sagen, dass bestehende Verbindungen geparkt oder abgebrochen werden sollen (vgl. [16], Kapitel

6.4.13). Wurde kein solcher Parameter übergeben und es besteht bereits eine Verbindung, so schickt das

ME dem SIM ein TERMINAL RESPONSE (ME unable to process command – currently busy on call).

• SEND SS: Das SIM verschickt eine Anforderung für definierte Mehrwertdienste an das Netz (SS =

Supplementary Service). Ist das ME bereits damit beschäftigt, einen Mehrwertdienst (SS oder USSD)

auszuführen, oder unterstützt den geforderten Mehrwertdienst nicht, so kann es die Anforderung zu-

rückweisen, indem es dem SIM eine Fehlermeldung „TERMINAL RESPONSE: currently busy on

SS/USSD transaction“ oder „Command beyond MEs capabilities“ übergibt. Unterstützt das ME den an-

geforderten Mehrwertdienst, so wird der Benutzer von der Vorbereitung zur Nutzung des Dienstes nicht

informiert, es sei denn, das SIM übergibt mit seiner Anweisung einen Alpha Identifier ungleich dem

Null-Datenobjekt. Die Antwort auf die Anforderung eines Mehrwertdienstes aus dem Netz ist dem Be-

nutzer nicht mitzuteilen, selbst dann nicht, wenn das Netz den Mehrwertdienst nicht unterstützt. Je

nachdem, ob eine Anforderung aus temporären Gründen vom Netz abgelehnt wurde, wird das SIM nach

entsprechendem Erhalt dieser Information, die Anforderung erneut anstoßen (vgl. [16], Kapitel 6.4.11).

• SEND USSD: Ein USSD String ( = Unstructured Suplemmentary Service Data) wird an das Netz ver-

schickt. In Folge eines USSD Strings kann das Netz eine direkte Kommunikation mit dem Benutzer

starten (der wesentliche Unterschied zu SS), bei dem er z.B. aus einem Menü auswählt, das aus dem

Netz kommt und nicht auf dem SIM oder im ME gespeichert ist (vgl. [16], Kapitel 6.4.11).

• SEND SHORT MESSAGE: Eine Short Message (Text) oder aber ein Short Message Command wer-

den an das Netz verschickt. Short Messages können sowohl in gepackter (160 7-Bit-Zeichen) als auch

in ungepackter (140 Zeichen) Form verschickt werden. Das Packen übernimmt das ME. Das ME packt

alle Short Messages (Text), es sei denn, das SIM erteilt dem ME explizit in Form eines Parameters mit

der Anweisung SEND SHORT MESSAGE die Anweisung nicht zu packen (packing not required).

SMS-Kommandos werden nicht gepackt, Textnachrichten i.d.R. schon, da sie für das Netz völlig trans-

parent übertragen werden. Die mit der SMS übergebene Adresse des SMS-SC soll nicht vom ME mit

der entsprechenden Adresse aus dem EFFDN verglichen werden (vgl. [16], Kapitel 6.4.10).

• SET UP EVENT LIST: Das SIM präsentiert eine Liste von Ereignissen, bei deren Eintreten das SIM

zu unterrichten ist. Infolge dieses Kommandos muss das ME alle Aktionen auf die Liste hin beobach-

51

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

ten. Bestehende Event-Listen werden von neueren Listen immer überschrieben. Bei einem Ausschalten

des ME wird die Event-Liste im ME gelöscht. Unterstützt das ME einzelne Dienste der Event-Liste

nicht, so verwendet es den Event Download Mechanismus und sendet ein TERMINAL RESPONSE

(Command beyond MEs Capabilities) an das SIM. (vgl. TS [16], Kapitel 6.4.16)

• SET UP IDLE MODE TEXT: Das SIM übergibt dem ME einen Test, der auf dem Display angezeigt

werden soll, z.B. „T-D1“ im Falle des D1 Netzes (vgl. [16], Kapitel 6.4.22). Der mit dem Kommando

übergebene Text überschreibt den im ME voreingestellten Standardtext. Jeder solche Eintrag durch den

Befehl SET UP IDLE MODE TEXT ist temporär und wird beim Ausschalten des ME gelöscht.

• SET UP MENU: Dem ME wird vom SIM eine Itemliste übergeben, die es in seine Menüstruktur integ-

rieren und dem Benutzer anzeigen soll. Diese Liste kann neben alphanumerischen Strings auch Verwei-

se auf Icons enthalten (vgl. [16], Kapitel 6.4.9), die auf dem Display dargestellt werden. Ist das ME

nicht in der Lage, die Anweisung auszuführen, da es z.B. nicht über den dafür notwendigen freien Spei-

cher verfügt, muss es ein „TERMINAL RESPONSE: Command beyond MEs capabilities“ senden. Mit

den einzelnen Items der Liste übergibt das SIM einen Identifier, den das ME dem SIM zurückgibt, so-

bald der Benutzer eines der in der Liste enthaltenen Objekte auswählt.

• PROVIDE LOCAL INFORMATION: Mit dieser Anweisung wird das ME vom SIM aufgefordert,

ihm Informationen bzgl. des aktuellen Standorts mitzuteilen. Das ME übergibt dem SIM den Mobile

Country Code (MCC), den Mobile Network Code (MNC), den Location Area Code (LAC) und die Cell

ID der aktuellen Zelle. Zusätzlich werden die IMEI, Messergebnisse aus dem BCCH (Broadcast Chan-

nel), die aktuelle Zeitzone, Zeit und Datum sowie die aktuellen Spracheinstellungen des ME an das SIM

übergeben. Die Daten können auch einzeln vom SIM angefordert werden (vgl. [16], Kapitel 6.4.15).

• TIMER MANAGEMENT: Diese Funktion veranlasst das ME, einen Timer zu steuern oder zu starten,

der im ME implementiert ist. Die Bedingungen und ggf. die Zeitdauer werden mit der Anweisung in

Form von Parametern vom SIM übergeben. Die möglichen Aktionen sind das Starten eines Timers, das

Deaktivieren eines laufenden Timers sowie die Übergabe des aktuellen Werts eines Timers. Parallel

können 8 unterschiedliche Timer gesetzt, gesteuert und überwacht werden. Als mögliche Zeit, die solch

ein Timer läuft, kann jeder Zeitraum zwischen 1 Sekunde und 24 Stunden gewählt werden, wobei im-

mer in Sekundenschritten gezählt wird. Bei einem Abschalten des ME werden alle Timer gelöscht. Soll

ein Timer deaktiviert werden, der schon deaktiviert ist, so soll das ME eine entsprechende TERMINAL

RESPONSE (action in contradiction with the current timer state) Nachricht an das SIM übergeben. Soll

das ME einen Timerwert übergeben, so übergibt es diesen mit einem TERMINAL RESPONSE, oder

falls der Timer deaktiviert wurde, mit einer Fehlermeldung (s.o.). Läuft ein Timer ab, so ist das SIM mit

Hilfe des Timer Expiration Mechanismus zu informieren und kann ihn dann reaktivieren oder löschen

lassen (vgl. [16], Kapitel 6.4.21).

• LANGUAGE NOTIFICATION: Anhand dieser Anweisung kann dem ME mitgeteilt werden in wel-

cher Sprache der Text innerhalb von Proactive SIM-Anweisungen übergeben wird. Da es möglich ist,

dass sich MMI, ME und SIM gemäß ihrer Einstellung jeweils unterschiedlicher Sprachen bedienen (vgl.

[16], Kapitel 6.4.24), dient diese Anweisung als eine Maßnahme einen Sprachkonflikt zu vermeiden.

Das ME hat diese Sprache zu adaptieren und verliert diese Einstellung erst wieder, wenn es deaktiviert,

bzw. das SIM aus dem Endgerät entfernt wird.

52

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

• LAUNCH BROWSER: Diese Anweisung muss vom ME zunächst geprüft werden, ob es in der Lage

ist, sie zu befolgen. Es handelt sich dabei um eine Aufforderung, den Browser des ME zu aktivieren.

Wenn das ME über keinen solchen verfügt, kein unterstützender Dienstanbieter verfügbar ist oder aber

bereits ein aktiver Browser geöffnet ist, muss es dem SIM eine entsprechende Fehlermeldung anhand

eines TERMINAL RESPONSE (vgl. [16], Kapitel 6.4.26) zukommen lassen. Zusammen mit der An-

weisung kann das SIM auch gleich eine Startseite angeben, die das ME aus dem Netz abrufen soll. Ist

das ME in der Lage, die Anweisung auszuführen, so soll es zunächst das SIM darüber informieren

(TERMINAL RESPONSE : OK), woraufhin das SIM nun die Proactive Session beendet. Erst nach Be-

endigung der Proactive SIM Session durch das SIM wählt das ME die mitgelieferte Adresse an. Wurde

keine Adresse mitgeliefert, so soll das ME die voreingestellte Adresse anwählen.

Das ME muss dem SIM auf jeden Fall die korrekte und vollständige Ausführung der SAT-Anweisung anhand

der „Command Result Procedure“ (TERMINAL RESPONSE) bestätigen. Was folgt, nachdem eine Anweisung

vom ME nicht erfolgreich abgearbeitet wurde, bestimmt das SIM. Die sofortige oder spätere Wiederholung des

Vorgangs oder ein Unterlassen der Wiederholung stehen dem SIM dabei zur Option. Als Antwort bzgl. des Sta-

tus der Anweisungserfüllung stehen dem ME entsprechend drei Möglichkeiten zur Verfügung: Das Kommando

wurde erfolgreich abgearbeitet (OK), es gab Probleme, die nur vorübergehend waren (temporary), und daher

lohnt es sich die Anweisung zu wiederholen oder es gab unlösbare Probleme. Wurde die Anweisung nicht kor-

rekt ausgeführt gibt es unterschiedliche Gründe: Es können Daten fehlen, die Nachrichten können zu kurz sein,

es kann aber auch sein, das das ME die Anweisungen einfach nicht versteht oder das Netz die Anweisungen

nicht ausführen kann, weil z.B. eine SMS verschickt werden sollte, das Netz aber SMS nicht unterstützt. Proac-

tive SIM Anweisungen werden gemäß den Basic Encoding Rules (BER) nach der TLV (Tag Length Value) Re-

gel codiert. Ein Werte-Feld kann selber wieder TLV-Objekte beinhalten (dies entspricht BER). Es gibt eine

Vielzahl von einfachen TLV-Objekten, die ihrerseits keine weiteren TLV-Objekte enthalten dürfen. Objekte bei-

der Typen werden sowohl Richtung SIM ME als auch in Gegenrichtung verschickt (vgl. TS 11.14, Annex D).

Beispiele:

Die Struktur von MORE TIME (vgl. [16], Kapitel 6.6.4):

Description M/O Length

Proactive SIM command Tag M 1

Length A + B M 1 or 2

Command Details M A

Device Identities M B

Tabelle 9: Kommandostruktur TLV Codierung

Wird in Folge des PROVIDE LOCAL INFORMATION Kommandos, z.B. die IMEI von der MS an das SIM

übergeben, so hat auch diese innerhalb des Value Feldes wiederum die TLV Struktur:

Bytes Description Length

1 IMEI tag 1

2 Length = ’08’ 1

3 - 10 IMEI of the ME 8

Tabelle 10: TLV Darstellung der IMEI

53

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ Darstellung einer Proactive SIM Session am Beispiel einer Menüauswahl durch den Benutzer:

ME Display

Get Inkey

Select Item list

Setup Menu list

SW1 SW2 = ’90 00’

TERMINAL RESPONSE

GET INKEY

FETCH

SW1 SW2 = ’91 XX’

TERMINAL RESPONSE

SELECT ITEM

FETCH

SW1 SW2 = ’91 XX’

ENVELOPE (Menu selection)

SIM ME Display ME

Abbildung 39: Darstellung einer Proactive SIM Session, Menüauswahl, vgl. [16], Annex E

Data Download to the SIM:

Der Datendownload aus dem Netz ist eine weitere Schlüsselfunktion aus dem SAT. Um neue Dienste, insbeson-

dere neue Daten auf die Karte bringen zu können, muss es einen Mechanismus geben, der dies unterstützt. Die

technisch einfachste Lösung wäre es, alle vorhandenen SIM-Karten einzuziehen und zu aktualisieren, ist aus lo-

gistischer und organisatorischer Sicht jedoch indiskutabel. Ein Update des SIM muss über die Luftschnittstelle

realisiert werden. Zur Lösung des Problems gibt es sowohl Push-Technologien, als auch die Möglichkeit, Daten

von einem Server herunter zu laden. Der Datendownload erfordert die Kenntnis der Quelladresse. Das SIM, wie

auch das ME kennen nur die BTSs, aber nicht deren physikalische Adressen, sondern deren netzinterne Bezeich-

nungen durch LAI, LAC, etc. und deren aktuelle Frequenzbereiche, unter denen sie abgehört bzw. adressiert

werden. Es muss also seitens des Netzes eine Push-Technologie verwendet werden, so dass die Daten an das

ME/SIM verschickt werden können. Die Lösung des Problems wird durch eine SMS aus dem Netz an das SIM

realisiert. Es gibt zwei unterschiedliche Szenarien: Die Punkt zu Punkt Übertragung (SMS-PP) für individuelle

Einspielungen und eine Cell Broadcast Übertragung (SMS-CB) die verwendet wird, wenn alle SIM-Karten im

Netz gleichermaßen aktualisiert werden sollen.

Eine weitere Problematik ist der Umstand, dass es sich dabei um Daten handelt, die ausschließlich der SAT-

Befehlssatz richtig interpretieren kann. Wenn nun also das SIM eine Daten-SMS empfängt, die es nicht interpre-

tieren kann, speichert es diese bestenfalls (da es sich um eine SMS handelt) in der Datei EFSMS ab. Es muss also

ein Mechanismus existieren, mit dem SMS transparent am SIM vorbeischleust werden können, ohne dass es die-

se direkt in die Datei EFSMS verschiebt (und den Benutzer benachrichtigt) und stattdessen dem SAT zur Interpre-

tation übergibt. Dieser Mechanismus wird durch die unidirektionale Funktion (ME SIM) ENVELOPE reali-

siert. Für das SAT bestimmte Daten aus dem Netz werden in Form von SMS vom ME empfangen und zunächst

in eine bestimmte Form gebracht, d.h. eingepackt und mit einem Header versehen, den das SIM interpretieren

kann und als ein für die SAT-Anwendung bestimmtes Datum erkennt.

54

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ Für einen erfolgreichen Datendownload via SMS muss der Datendownload im SIM Service Table (EFSST) akti-

viert sein. Das ME erkennt „Daten-SMS“ anhand ihres Protocol Identifiers, der auf SIM Data download gesetzt

ist und anhand des Data Coding Scheme, das die Nachricht als Class-2-Message beschreibt. Eine solche Nach-

richt darf vom ME nicht interpretiert werden, noch darf es den Benutzer informieren, dass eine SMS eingegan-

gen ist. Es verpackt die Nachricht in ein für das SIM akzeptables Format und reicht sie an das SIM weiter, das

die Nachricht wiederum an die SAT-Anwendung weiterreicht. Ist in der SIM Service Table die Option des Da-

tendownload nicht aktiviert, so speichert das SIM die Nachricht im EFSMS ab, der Benutzer wird nicht darüber

informiert. Es gibt einige Fehlerroutinen, die in [16], Kapitel 7 nachgelesen werden können. Der Envelope Me-

chanismus unterscheidet sich bei SMS-CB und SMS-PP. Er wird u.a. auch bei der Menu Selection angewandt

und immer dann eingesetzt, wenn das ME direkt mit der SAT-Anwendung kommunizieren muss. Alle ENVE-

LOPE Anweisungen sind nach der TLV Struktur aufgebaut.

Die Strukturen der ENVELOPE Anweisungen beim Datendownload:

Description M/O Length SMS - PP Download tag M 1 Length (A + B + C) M 1 or 2 Device Identities M A Adress O B SMS TPDU (SMS - DELIVER) M C

Abbildung 40: Structure of ENVELOPE (SMS-PP DOWNLOAD), vgl. [16], Kapitel 7.1.2

Als Device Identities sind vom ME die Quelle (Source) mit “Network“ und das Ziel (Destination) mit „SIM“ zu

bezeichnen. In dem Adressfeld wird der Absender der Daten-SMS eingetragen, also des Service Centers. Eine

Antwort vom SIM ist von den Statusworten SW1/SW2 ’90 00’ abgesehen, nicht erforderlich. Erwartet das Netz

Rückgabedaten, so setzt das SIM seinen Status nicht auf ’90 00’ sondern auf ’9F XX’ oder ’9E XX’ und über-

gibt die folgenden Daten:

Byte(s) Description Length 1-X ( X ≤ 128) SIM Acknowledgement X

Im Gegensatz zum Punkt zu Punkt Versand von Daten-SMS überprüft das ME beim Broadcast Versand von Da-

ten-SMS aus dem Netz die Adresse des Senders anhand des EFCBMID (Cell Broadcast Message Identifier). Ist die

Adresse des Absenders in dieser Tabelle enthalten, so wird die Nachricht direkt eingepackt und an das SIM wei-

tergeleitet, ohne dass der Benutzer informiert, oder die Nachricht im Display angezeigt wird. Ist die Adresse

nicht in der Tabelle enthalten, so entscheidet das ME, ob die Nachricht im Display angezeigt wird. Bei Cell

Broadcast SMS sind abgesehen von der Empfangsbestätigung keine Daten als Rückgabe vom SIM vorgesehen.

Description M/O Length Cell Broadcast Download tag M 1 Length (A + B) M 1 or 2 Device identities M A Cell Broadcast page M B

Abbildung 41: Structure of ENVELOPE (CELL BROADCAST DOWNLOAD), vgl. [16], Kapitel 7.2.2

55

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ In den Device Identities sind vom ME als Quelle das Netzwerk und als Ziel das SIM einzutragen. Die Cell

Broadcast Page dient zur Identifizierung der Quelle. Dieses Datum ist in der oben bereits erwähnten Tabelle im

EFCBMID enthalten.

Menu Selection:

Bei der Menüauswahl wird auch die ENVELOPE Funktion verwendet. Damit der Benutzer aus einem Menü der

SIM-Karte auswählen kann, muss das ME die Anweisung SET UP MENU erhalten und seine Liste entsprechend

erweitert bzw. verändert haben (vgl. [16], Kapitel 8). Wählt der Benutzer einen Menüpunkt aus, der auf Daten

der mit SET UP MENU übertragenen Liste verweist, schickt das ME an das SIM eine Anforderung, indem es

den Item Identifier und die Device Identity (oder ggf. mehrere) mit dem ENVELOPE (MENU SELECTION)

Kommando verpackt und weiterreicht. Gleiches geschieht, wenn der Benutzer zu einem bestimmten Menüpunkt

erklärende Unterstützung benötigt. Hilfe-Dateien sind immer optional und werden vom SIM nur auf Anforde-

rung hin verschickt. Die Quelle in der ENVELOPE Anweisung ist das Keypad angegeben und das Ziel das SIM.

Call Control by SIM:

Jeder Versuch eine Verbindung aufzubauen oder zu steuern, vorausgesetzt „Call Control by the SIM“ ist in der

SIM Service Table aktiviert, soll mit dem für diese Funktion definierten speziellen ENVELOPE Kommando an

das SIM geschickt werden. Es spielt keine Rolle, ob der Verbindungsaufbau direkt vom Benutzer oder vom SIM

(SET UP CALL) initialisiert wurde. Die ENVELOPE Anweisung für „Call Control by the SIM“ besteht wie die

in den Abbildungen 40 und 41 grafisch dargestellten ENVELOPE Anweisungen auch aus den Feldern Tag (Call

control tag), der Länge (hier A+B+C+D+E+F) und den Device IDs im Wertefeld. Im Wertefeld müssen zusätz-

lich die Adresse des angeforderten Mehrwertdienstes und die aktuellen Ortsinformationen der Zelle, in der sich

das rufende ME befindet (MCC, MNC, LAC, Cell Identity), enthalten sein. Weiter können noch zwei Typen von

Konfigurationsparametern (nur bei Gesprächsverbindungen) enthalten sein und eine Subadresse der angerufenen

Seite, falls es sich um einen Verbindungsaufbau handelt. Diese Parameter beziehen sich auf die Bearer Capabili-

ties 1 und 2 (TS 04.08) , die in dieser Arbeit aber nicht weiter behandelt werden. Erhält das SIM die entspre-

chende ENVELOPE Anweisung, so kann es ohne weitere Daten an das ME zurückzugeben mit den Statusworten

SW1 SW2 ’90 00’ antworten. Dies interpretiert das ME als eine bedingungslose Erlaubnis. Hat das SIM Ein-

wände gegen einen speziellen bevorstehenden Verbindungsaufbau, der entweder nicht statt finden darf oder nur

in veränderter Form, so muss es dem ME mit den Statusworten im Datenfeld der Response APDU eine entspre-

chende Nachricht zukommen lassen. Im Folgenden wird das mögliche Antwortpaket des SIM dargestellt und er-

läutert.

Description M/O Length Call control result M 1 Length (A + B + C + D + E + F) M 1 or 2 Adress or SS String or USSD String O A Capability configuration parameters 1 O B Subadress O C Alpha Identifier O D BC repeat indicator M/O E Capability configuration parameters 2 O F

Abbildung 41: Structure of Response APDU after ENVELOPE (Call Control), vgl. [16], Kapitel 9.1.6

56

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ Für das Feld Call control result existieren 3 Parameter: Die Verbindung darf aufgebaut werden (’00’), sie darf

nicht aufgebaut werden (’01’) oder sie darf zwar aufgebaut werden, jedoch nur nach erfolgten Veränderungen

der Parameter (’02’). Im Adress-Feld darf nur eine einzige Adresse enthalten sein, sofern das SIM Veränderun-

gen an Einzelheiten des angefragten Diensts (Verbindungsaufbau, SS, USSD) erzwingen will. Wurde dem SIM

zuvor keine Adresse des zu startenden Dienstes mitgeteilt, muss das SIM im Feld „Adress or SS String ...“ ein-

tragen, dass keine Modifikationen an diesem Parameter vorzunehmen sind. Die Subadresse kann, falls es sich

um einen Verbindungsaufbau handelt und sie vom ME an das SIM übergeben wurde, vom SIM modifiziert wer-

den. Übergibt das SIM dem ME anstelle der Subadresse das Null Data Object ’00’, so ist keine Subadresse an

das Netz zu übermitteln. Der Alpha Identifier kann genutzt werden um dem Benutzer eine Nachricht auf das

Display zu übermitteln. Der BC (Bearer Capability) repeat indicator bezieht sich auf die beiden Konfigurations-

parameter und gibt an, auf welche Weise diese zu interpretieren sind. Wurde das Call control result vom SIM auf

„allowed with modifications“ gesetzt, so muss es mindestens eines der optionalen Felder mit einem Inhalt füllen.

MO SMS control by SIM:

(vgl. [16], Kapitel 9.2) Bei allen zu verschickenden Kurznachrichten muss das ME zunächst das SIM um Er-

laubnis fragen. Dies gilt sowohl für direkt vom Benutzer eingegebene Nachrichten, als auch für Nachrichten, die

durch das SIM anhand des Befehls SEND SHORT MESSAGE in Form eines Proactive Commands eingeleitet

werden. Das ME hat dem SIM die Adresse des Service Centers sowie die Adresse des Empfängers mitzuteilen.

Das SIM kann mit ’90 00’ antworten, wenn keine Modifikationen erforderlich sind, mit ’93 00’ wenn die Nach-

richt nicht gesendet werden darf oder mit ’9F XX’ wenn die Adressen zuvor geändert werden müssen. Das EN-

VELOPE Kommando enthält neben den üblichen Tag und Längenfeldern die Device Entities, die beiden oben

angegebenen Adressen und eine Location Information. Die Antwort des SIM besteht entweder aus den Status-

worten SW1 SW2 ’90 00’, oder enthält neben dem „MO short message control result“ und dem Längenfeld opti-

onal noch die beiden Adressen in der jeweils geänderten Fassung und einen optionalen Alpha Identifier, der ei-

nen vom ME auszugebenden Text für den Benutzer enthält. Die möglichen Codierungen für das „MO short mes-

sage control result“ Feld entsprechen den Codierungen für das in Abbildung 41 gezeigte Call Control result.

Event Download:

Mit dem Oberbegriff „Event Download“ werden eine Vielzahl von einzelnen Nachrichten, die unterschiedlich

geartete Events abdecken, bezeichnet. Jedes dieser einzelnen Ereignisse, die auftreten können und vom ME an

das SIM gemeldet werden müssen, wird mit einer eigenen ENVELOPE Anweisung übergeben. Sie sind gemäß

der in TS 11.14 getroffenen Vereinbarung im TLV-Modus kodiert und enthalten alle das Tagfeld, ein Längenfeld

und als Wert mindestens die Angabe der beteiligten Device Entites. Jeder dieser Events muss als Grundbedin-

gung dafür, dass er registriert werden kann, Bestandteil der Eventlist sein, die mit der letzten erfolgten SET UP

EVENT LIST Anweisung vom SIM an das ME übergeben wurde. Für keine dieser ENVELOPE Nachrichten

sind spezifische Antwortdaten seitens des SIM vorgesehen. Alle ENVELOPE Nachrichten enthalten ein Feld mit

der Bezeichnung „Event list“, in dem auf einem einzigen Byte der aktuell eingetretene Event codiert ist. Bei dem

in der folgenden Aufzählung der einzelnen Nachrichten häufiger erwähnten „Transaction identifier“ handelt es

sich um ein aus einer einzelnen Identifikationsnummer bestehendes Datenobjekt. Die Beschreibung der Nach-

richten beschränkt sich jeweils auf die grundlegende Funktion und die Besonderheiten im Wertefeld:

57

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

• MT call event: Bei jedem eingehenden Anruf, eine SETUP Nachricht muss als Bedingung aus dem

Netz kommend beim ME eingehen, muss das SIM anhand einer speziellen ENVELOPE Nachricht dar-

über informiert werden. Neben den oben bereits aufgezählten Feldern und einem Transaction Identifier,

der die im SETUP enthaltene Transaktionsnummer beinhaltet, die die ENVELOPE Nachricht enthalten

muss, können zusätzlich noch die evtl. in dem SETUP enthaltene BCD Nummer und/oder die Subad-

resse enthalten sein (vgl. [16], Kapitel 11.1).

• Call connected event: Dieser Event wird dem SIM immer dann gemeldet, wenn eine Verbindung auf-

gebaut wurde, sei es eine vom Endgerät ausgehende oder ans Endgerät eingehende Verbindung. Falls

die Verbindung aufgrund einer Proactive SIM Anweisung aufgebaut wurde, soll das ME zuerst das

TERMINAL RESPONSE als Antwort auf das proactive command und dann die ENVELOPE (EVENT

DOWNLOAD, call connected) Nachricht an das SIM schicken. Die ENVELOPE Nachricht enthält ne-

ben den bekannten Bestandteilen einen Transaction Identifier, der die Nummer der CONNECT Nach-

richt beinhaltet. Je nachdem, ob es sich um eine MT- oder MO-Verbindung handelt, wird im Device i-

dentities Feld das ME oder das Netz als Quelle eingetragen (vgl. [16], Kapitel 11.2).

• Call disconnected event: Dieser Event ist das Pendant zum Call-connected-event für den erfolgten

Verbindungsabbau. Im Gegensatz zum Call connected event kann der enthaltene Transaction identifier

eine ganze Liste von getrennten Verbindungsidentifikationsnummern enthalten, z.B. für das Auslösen

einer Konferenzschaltung. Zusätzlich ist auch noch ein optionales Feld für die Ursache der erfolgten

Verbindungsauslösung enthalten. Dieses Feld beinhaltet dann die CC-cause information, die in der

beim ME eingegangenen Netznachricht DISCONNECT, RELEASE oder RELEASE COMPLETE ent-

halten ist (vgl. [16], Kapitel 11.3).

• Location status event: Der Location Status Event tritt dann ein, wenn das ME eine MM-IDLE Abfrage

an das Netz schickt, unabhängig davon, ob sich an den im SIM gespeicherten ortspezifischen Daten,

wie LAI, LAC, etc. etwas geändert hat. Mit der entsprechenden ENVELOPE (EVENT DOWNLOAD,

Location status) Nachricht wird dem SIM mitgeteilt, dass eine solche Abfrage stattgefunden hat und ob

sich etwas geändert hat. Hat sich an den gespeicherten Ortsinformationen nichts geändert, so enthält die

ENVELOPE Nachricht lediglich (zusätzlich zu den bekannten Daten) ein „Location status“ Feld, in

dem der aktuelle Service Status des Endgeräts codiert ist. Im Falle einer Änderung wird zusätzlich ein

Feld mit den ortspezifischen Angaben an das SIM übergeben (vgl. [16], Kapitel 11.4).

• User activity event: Der User activity event tritt immer dann ein, wenn der Benutzer eine Handlung

von sich aus vornimmt, z.B. einen Knopf drückt. Die ENVELOPE Nachricht an das SIM enthält ledig-

lich die oben fest vorgegebenen Parameter. Das ME löscht nach der Meldung dieses Events an das SIM

den Eintrag in der Eventlist, um ihn nicht noch einmal zu melden, wenn der Benutzer infolge dieses ers-

ten „Knopfdrucks“ noch weitere Knöpfe drückt (vgl. [16], Kapitel 11.5).

• Idle screen available event: Dies ist ebenfalls ein Event, der nach dem Erhalt der Eventlist nur ein ein-

ziges Mal ausgeführt werden soll und dann aus der Liste gelöscht wird. Jedes Mal, wenn das ME eine

DISPLAY TEXT Anweisung erhält und sich gleichzeitig in einem Zustand befindet, in dem es einen

Text mit normaler Priorität eher anzeigen würde als ihn abzulehnen (also gerade keine Anzeige außer

dem Standard Icon auf dem Bildschirm angezeigt wird), erhält das SIM diese Mitteilung. Sie beinhaltet

keine weiteren Daten, als die bereits bekannten (vgl. [16], Kapitel 11.6).

58

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________

• Card reader status event: Dieser Event bezieht sich auf die Verwendung mehrerer Karten und tritt

dann ein, wenn eine zusätzliche Karte in das ME eingeführt oder aus dem ME entfernt wird. Der Card

Reader Status (Status Flags und Identifier bzgl. der zusätzlichen Karte) wird zusätzlich zu den bekann-

ten Informationen an das SIM übertragen. (vgl. [16], Kapitel 11.7).

• Language selection event: Immer dann, wenn im ME die vordefinierte Sprache geändert wird, ver-

schickt das ME eine entsprechende ENVELOPE Nachricht an das SIM. Zusätzlich zu den oben be-

schriebenen Standardfeldern aller ENVELOPE Nachrichten dieser Sektion enthält diese Nachricht noch

ein Feld, in dem die aktuell verwendete Sprache codiert ist (vgl. [16], Kapitel 11.8).

• Browser termination event: Wenn der Browser des ME geschlossen wird, erfolgt eine ENVELOPE

Nachricht an das SIM. Die Nachricht enthält die Ursache der Beendigung (vgl. TS 11.14, Kapitel 11.9).

• Data available event: Wenn der Datenpuffer des Empfangskanals des ME gerade leer ist und neue Da-

ten aus dem Netz eintreffen, wird diese ENVELOPE Nachricht an das SIM übergeben. Dieser Event

kann ausschließlich bei Mehrkanal-Endgeräten auftreten. Mit der Nachricht werden zum einen der Ka-

nal-Status und seine Identifikationsnummer übergeben und zum anderen die Länge der eingegangenen

Daten. Falls mehr als 255 Byte eingehen, wird die Länge auf FF gesetzt. (vgl. [16], Kapitel 11.10).

• Channel status event: Auch diese Nachricht existiert ausschließlich bei Mehrkanal-Endgeräten. Sie

wird dann übergeben, wenn in einem der Kanäle ein Fehler auftritt. Mit der Nachricht wird, von den

Standarddaten abgesehen, nur der Channel Status an das SIM übergeben (vgl. [16], Kapitel 11.11).

Timer Expiration:

Alle Timer, die mit der TIMER MANAGEMENT Anweisung erzeugt werden, laufen wie bereits oben beschrie-

ben, nach spätestens 24 Stunden aus. Sobald ein Timer ausläuft, muss das ME dies dem SIM mitteilen, indem es

ihm mit einer ENVELOPE (TIMER EXPIRATION) Nachricht den Identifikator und Wert (definierter Zeitrah-

men, der den Start des Timers bis zu seinem Auslaufen umfasst) des Timers übergibt. Ist das SIM gerade mit ei-

ner anderen Operation beschäftigt und übergibt anstelle eines ’90 00’ ein ’93 00’, so muss das ME bis zum

nächsten TERMINAL RESPONSE warten, das auf ein zuvor empfangenes ’90 00’ erfolgt. Auf die Nachricht

TIMER EXPIRATION erfolgt keine Rückantwort (außer der Statusworte SW1 und SW2, s.o.).

Beispiel einer SAT Anweisung, die durch eine aus dem Netz kommende SMS-CB-Nachricht erzeugt wird:

In der Abbildung 43 wird gezeigt, wie SIM-Update-Daten aus dem Netz in Form einer Daten-SMS an das ME

geschickt und von diesem dann an das SIM weitergeleitet werden. Erst die SAT-Anwendung verarbeitet die Da-

ten. Die interne Kommunikation zwischen SIM und SAT Anwendung wird durch Klammerung symbolisiert. Die

blau gestrichelten Linien entsprechen einer Wartezeit von jeweils 60 ms, die das SAT benötigt, die Daten SMS

auszuwerten.

Nachdem das SIM die Daten-SMS empfangen und an die SAT Anwendung weitergeleitet hat, bestätigt das SAT

nach einer Bearbeitungszeit von 120 ms den Erhalt und weist gleichzeitig das ME durch ein Setzen der Status-

worte auf ’91 XX’ darauf hin, dass es eine aus der SMS resultierende Anweisung für das ME bereithält. Zu-

nächst bestätigt das ME dem Netz die Abarbeitung der SMS und schickt dem SIM eine FETCH Anweisung, mit

dem es das SAT auffordert, die interpretierte Anweisung zu übergeben. Nachdem die Anweisung übergeben

wurde, quittiert das ME diese mit einem TERMINAL RESPONSE. Das SAT hat keine weiteren Anweisungen

oder Daten zu übergeben und gibt die Statusmeldung ’90 00’ (OK) aus, die das SIM an das ME weiterleitet. In

59

Kapitel 4.2: Wirkungsweise der neuen Funktionen ________________________________________________________________ einem vergleichbaren Szenario, in dem vom Netz eine Rückantwort durch das SIM erwarten würde, müsste das

SAT entsprechend die angeforderten Daten in Form einer MO-SMS an das Netz schicken. Bei der zu erteilenden

Anweisung könnte es sich beispielsweise um eine PLAYTONE Anweisung handeln.

TERMINAL RESPONSE (TERMINAL RESPONSE)

(’90 00’) ’90 00’

Command

(Command)

(FETCH)

FETCH

’91 XX’

(SMS)

(’91 XX’)

SMS Ack

ENVELOPE (SMS)

SMSSIM DD Class2

ME SIM Application GSM SIM Netz

Abbildung 43: Empfang einer Daten SMS (SMS DATA DOWNLOAD) aus dem Netz, vgl. [15], Annex E

4.3 Die Interaktion zwischen ME und SIM am Beispiel eines Traces Bei dem vorliegenden Trace handelt es sich um die Aufzeichnung der Kommunikationsdaten zwischen einem

Phase-2-ME vom Typ Alcatel 701 und einer Phase-2-SIM-Karte. Das Tracing-Programm wurde exklusiv für die

T-Mobile-International geschrieben und speichert die vorinterpretierten Informationen in Form eines HTML-

Dokuments ab, das zur Wiedererkennung von Einzelpassagen über Seitenzahlen verfügt und zusätzlich die ver-

strichene Zeit dokumentiert. Es wurden die ISO/OSI-Schichten 2 und 7 aufgezeichnet. In Annex B befindet sich

eine Zusammenfassung des Layer-7-Traces. In dieser Zusammenfassung wurde der Layer-7-Trace durch Einrü-

ckungen und Verwendung unterschiedlicher Schriftarten und –Grade zu Gunsten besserer Lesbarkeit verändert.

Sich permanent wiederholende Informationen, insbesondere im HTML-Trace interpretierte Zusatzinformationen

wurden dabei weggelassen. Auch bei dieser Zusammenfassung wurden jeweils die Seitenzahlen und die relative

Zeit in den jeweiligen Überschriften zum direkten Vergleich mit dem Original integriert. Das Original liegt nicht

in gedruckter Form (215 Seiten) vor, sondern kann auf der dieser Arbeit beiliegenden CD-Rom betrachtet wer-

den. Im Folgenden werden Teile des Traces in Form einer Tabelle analysiert, bei der jeweils die zueinander ge-

hörigen Passagen von Layer 2 und Layer 7 gegenüber gestellt werden.

60

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________ Anhand der Zeitangabe kann der jeweilig interpretierte Befehl im Original bzw. der in Annex B enthaltenen Zu-

sammenfassung wiedergefunden werden. Die jeweilige Auswahl der gegenübergestellten Passagen wurde so ge-

troffen, dass jeder im Trace aufgezeichnete Befehl mindestens einmal vorkommt. Um die Daten der Layer 2

Aufzeichnung im Layer 7 wiederfinden zu können, wurden die entsprechend korrespondierenden Passagen bei-

der Layer jeweils in unterschiedlichen Farben markiert. Die Informationen zur Analyse des Traces stammen aus

unterschiedlichen Kapiteln von [15] SIM- und [16] SAT Spezifikation, so dass weitestgehend von direkten Quel-

lenverweisen zugunsten einer besseren Übersicht abgesehen wurde. Zur Übersetzung von HEX in ASCII wurde

eine entsprechende Tabelle verwendet.

Zu Anfang werden die Schicht 2 Aufzeichnungen von ATR (Answer to Reset) und PPS (Protocol Parameter Se-

lect) vorgestellt. Zu diesem Zeitpunkt spielt die Anwendungsschicht noch keine Rolle. Folglich werden auch

noch keine TPDUs auf Schicht 2 übertragen.

Zeit (s) 0.00136176 (Cold Reset) (Cold Reset)

Event Reset card interface ATR TS Value: 3B Meaning: Direct convention ICD (ETU): 119.86 T0 Value: 9A Meaning: Following interface chars: TA1,TD1 Number of historical chars: 10 ICD (ETU): 83.27 TA1 Value: 94 Meaning: F = 512 D = 8 ICD (ETU): 13.60 TD1 Value: 00 Meaning: Following interface chars: none Transfer protocol T=0 ICD (ETU): 13.60 T1 Value: 91 Meaning: ICD (ETU): 13.60 ……………………………………………………………………. T10 Value: 96 Meaning: ICD (ETU): 13.65 PPS request PPSS Value: FF Meaning: Initial character ICD (ETU): 18.44 PPS0 Value: 10 Meaning: Following parameter chars: PPS1 Transfer protocol: T=0 ICD (ETU): 13.01 PPS1 Value: 94

TS = Initial Character +3/5 V = logische “1” T0 = Format Character Kündigt die folgenden Schnittstellen-Zeichen TA1 und TD1 an TA1 = Global Interface Character ’94’ bezeichnet die Anweisung, die Übertragungsgeschwindigkeit von default F = 372 D = 1 auf F = 512 D = 8 zunächst für die Dauer des folgenden PPS zu erhöhen TD1 = Interface Character initialisiert die Kom-munikation mit T = 0 T1 - Tn = Historical Character PPS (Protocol and Parameter Select): PPS besteht aus 4 Zeichen:

TA1 = ’94’

PPS Request

PPSS = ’FF’ PPS0 = ’10’ PPS1 = ’94’ PCK = ’7B’

PPS Response

PPSS = ’FF’ PPS0 = ’10’ PPS1 = ’94’ PCK = ’7B’

ATR

Reset SIM ME

61

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

Meaning: F = 512 D = 8 ICD (ETU): 13.01 PCK Value: 7B Meaning: Check character ICD (ETU): 13.01 PPS response PPSS Value: FF Meaning: Initial character ICD (ETU): 12.97 PPS0 Value: 10 Meaning: Following parameter chars: PPS1 Transfer protocol: T=0 ICD (ETU): 14.38 PPS1 Value: 94 Meaning: F = 512 D = 8 ICD (ETU): 14.38 PCK Value: 7B Meaning: Check character ICD (ETU): 14.38

Falls die Erhöhung der Übertragungsgeschwindig-keit für PPS von default F = 372 D = 1 auf F = 512 D = 8 noch nicht statt gefunden hat, wird sie jetzt angewiesen

Das oben im PPS-request (PPS0) vorgeschlagene Übertragungsprotokoll T=0 wird hier im PPS-response bestätigt und kann nun auch für die wei-tere Kommunikation verwendet werden (vgl. [15], 5.8.2, letzter Satz). Die geänderte Übertragungsgeschwindigkeit kann nun auch in der folgenden Kommunikation bei der Übertragung von TPDUs und APDUs verwendet werden (vgl. [15], 5.8.2, letzter Satz).

Nach Abschluss dieser Prozedur können nun APDUs auf Schicht 7 und die entsprechenden TPDUs auf Schicht 2

vom Endgerät zur Chipkarte und zurück übertragen werden. Nach dem MF wird zunächst DFGSM ausgewählt:

Zeit (s) Layer 2 Layer 7

0.00582638 APDU TPDU Header [CLA INS P1 P2 P3]: (A0 A4 00 00 02) Incoming data (2 bytes): 7F 20 Return code [SW1 SW2]: 9F 1B TPDU Header [CLA INS P1 P2 P3]: A0 C0 00 00 1B Outgoing data (27 bytes): 00 00 00 05 7F 20 02 FA FF AA FF 01 0E 93 00 1A 06 00 83 8A 83 8A 00 83 83 00 22 Return code [SW1 SW2]: 90 00

SELECT (GSM) Command: SELECT Status: OK Current DF: GSM (7F20) Current EF: None Time: 0.058 s RFU bytes 1-2: 00 00 Memory available: 5 bytes File ID: 7F20 Type of file: Dedicated file RFU bytes 8-12: FA FF AA FF 01 Length of following data: 14 bytes File characteristics: Clock stop: Allowed, no preferred level Min. freq. for GSM algor:13/4MHz Technology identification: 3V Technology SIM CHV1:Disabled DFs in current directory: 0 EFs in current directory: 26 Number of CHV and admin. codes: 6 RFU byte 18: 00 CHV1 status: False presentations remaining:3 RFU bits 7-5: 000 Secret code: Initialised UNBLOCK CHV1 status:

62

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

False presentations remaining: 10 CHV2 status: False presentations remaining:3 RFU bits 7-5: 000 Secret code: Initialised UNBLOCK CHV2 status: False presentations remaining: 10 RFU bits 7-5: 000 Secret code: Initialised RFU byte 23: 00 Reserved for admin. management: 83 83 00 22

0.16732848 APDU

Header [CLA INS P1 P2 P3]: (A0 A4 00 00 02) Incoming data (2 bytes): 6F AE Return code [SW1 SW2]: 9F 0F

SELECT (PHASE) Command: SELECT Status: OK - response length 15 Current DF: GSM (7F20) Current EF: Phase identification (6FAE) Time: 0.167 s

0.17655258 APDU Header [CLA INS P1 P2 P3]: (A0 B0 00 00 01) Outgoing data (1 bytes): 03 Return code [SW1 SW2]: 90 00

READ BINARY Command: READ BINARY Status: OK Current DF: GSM (7F20) Current EF: Phase identifi- cation (6FAE) Time: 0.177 s Offset: 0 Length: 1 SIM Phase: Phase 2 and PROFILE DOWNLOAD required

1.39218832 s APDU

Header [CLA INS P1 P2 P3]: (A0 B2 01 04 B0) Outgoing data (176 bytes): 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

READ RECORD (1) Command: READ RECORD Status: OK - Proactive SIM com- mand pending response length 69 Current DF: TELECOM (7F10) Current EF: Short Messages(6F3C) Time: 1.392 s Record No.: 1 Mode: Absolute Status: RFU bits 8-6: 000 Status: free space Remainder: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF

63

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF Return code [SW1 SW2]: 91 45

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF Anmerkung: das folgende FETCH re-sultiert direkt aus SW2

1.44989472 APDU

Header [CLA INS P1 P2 P3]: (A0 12 00 00 45) Outgoing data (69 bytes): D0 43 81 03 01 25 00 82 02 81 82 85 0C 54 2D 44 31 20 53 70 65 63 69 61 6C 8F 0A 01 54 2D 44 31 20 4E 65 77 73 8F 0B 02 4D 61 69 6C 20 26 20 46 61 78 8F 08 03 4D 79 4D 6F 6E 65 79 8F 07 04 45 78 74 72 61 73 Return code [SW1 SW2]: 90 00

FETCH (SET UP MENU) Command: FETCH Status: OK Current DF: TELECOM (7F10) Current EF: Short Messages(6F3C) Time: 1.450 s Proactive SIM Command Command Details Command Number: 1 Command Name: SET UP MENU Command Qualifier: no selection preference, no help information available Device Identity Source: SIM Destination: ME Alpha Identifier: T-D1 Special Item Identifier of item: 01 Text String: T-D1 News Item Identifier of item: 02 Text String: Mail & Fax Item Identifier of item: 03 Text String: MyMoney Item Identifier of item: 04 Text String: Extras

Nachdem sich das ME die Überschriften 1-4 (s.o.) abgeholt hat , die es in seiner Menüstruktur integrieren soll

und noch einen weiteren Record ausgelesen hat (READ RECORD(2), Time: 1.4921232s ), schickt es dem SIM

eine Empfangsbestätigung in Form eines TERMINAL RESPONSE (SET UP MENU):

1.55243452 APDU Header [CLA INS P1 P2 P3]: (A0 14 00 00 0C) Incoming data (12 bytes): 81 03 01 25 00 02 02 82 81 83 01 00 Return code [SW1 SW2]:91 0B Das SW2=0B bezieht sich auf das bereits durchgeführte SELECT auf RECORD(2), es stehen noch weitere Daten (0B = 11 Bytes) zur Abholung bereit.

TERMINAL RESPONSE (SET UP MENU) Command: TERMINAL RESPONSE Status: OK - Proactive SIM command pending-response length11 Current DF: TELECOM (7F10) Current EF: Short messages(6F3C) Command Details Command Number: 1 Command Name: SET UP MENU Command Qualifier: no selection preference, no help information available Device Identity Source: ME Destination: SIM General Result: Command per-formed successfully

1.83498892 APDU

Header [CLA INS P1 P2 P3]: (A0 12 00 00 96) Outgoing data (150 bytes):

FETCH (SEND SHORT MESSAGE) Command: FETCH Status: OK Current DF: TELECOM (7F10)

64

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

D0 81 93 81 03 01 13 00 82 02 81 83 85 00 86 07 91 94 71 01 67 50 62 8B 7D 01 FF 05 81 00 00 F3 00 F4 73 08 09 04 00 01 01 01 01 01 FF FF 05 37 04 80 02 80 01 80 01 80 01 FF FF 80 01 80 01 80 01 FF FF 80 01 80 01 00 01 FF FF FF FF FF FF 80 01 80 01 80 01 FF FF 00 04 00 01 00 01 00 01 FF FF FF FF 00 01 00 01 04 03 04 FF FF 02 0B 04 01 00 17 26 01 90 01 04 11 08 01 0B 04 98 94 20 00 00 10 76 47 09 84 07 03 04 01 99 03 09 04 3A 23 91 60 47 46 12 53 Return code [SW1 SW2]:90 00 Die Zieladresse ist hier das Netz!

Current EF: Short messages(6F3C) Time: 1.835 s Proactive SIM Command Command Details Command Number: 1 Command Name: SEND SHORT MESSAGE Command Qualifier: packing not required Device Identity Source: SIM Destination: Network Alpha Identifier: Address, Type of number: International Number Numbering plan identification: ISDN/ telephony numbering plan (Rec. E.164/ E.163) Dialling number string: 491710760526 SMS TPDU TP-Message-Type-Indicator: SMS-SUBMIT (in the dir. MS to SC) TP-Reject-Duplicates: Instruct SC to accept SMS-SUBMIT TP-Validity-Period-Format: TP-VP field not present TP-Status-Report-Request: A status report is not requested TP-User-Data-Header-Indicator: The TP-UD field contains only the short message TP-Reply-Path: TP-Reply-Path parameter is not set TP-Message-Reference: 255 TP-Destination-Address TON: Un-known Numbering plan identification: ISDN/ telephony numbering plan (Rec. E.164/ E.163) Dialling number string: 00003 TP-Protocol-Identifier: no inter- working, but SME-to-SME protocol, TP-Data Coding Scheme: 8-bit data, Class 0, TP-User Data Length: 115 TP-User Data (hexadecimal): 08 09 04 00 01 01 01 01 01 FF FF 05 37 04 80 02 80 01 80 01 80 01 FF FF 80 01 80 01 80 01 FF FF 80 01 80 01 00 01 FF FF FF FF FF FF 80 01 80 01 80 01 FF FF 00 04 00 01 00 01 00 01 FF FF FF FF 00 01 00 01 04 03 04 FF FF 02 0B 04 01 00 17 26 01 90 01 04 11 08 01 0B 04 98 94 20 00 00 10 76 47 09 84 07 03 04 01 99 03 09 04 3A 23 91 60 47 46 12 53

65

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________ Die Funktion RUN GSM ALGORITHM: 7.74314892 APDU

TPDU Header [CLA INS P1 P2 P3]: (A0 88 00 00 10) Incoming data (16 bytes): 0F 3B A8 D3 03 82 D8 EE 3A DB AA 9D FD 09 A0 F2 Return code [SW1 SW2]: 9F 0C TPDU Header [CLA INS P1 P2 P3]: A0 C0 00 00 0C Dies ist ein GET RESPONSE im Rahmen des RUN GSM ALGORITHM (vgl. [15], 9.2.18) Outgoing data (12 bytes): 99 99 99 99 99 99 99 99 99 99 99 99 Return code [SW1 SW2]:91 96

RUN GSM ALGORITHM () Command: RUN GSM ALGORITHM Status: OK - Proactive SIM command pending-response length 150 Current DF: GSM (7F20) Current EF: None Time: 7.743 s RAND: 0F 3B A8 D3 03 82 D8 EE 3A DB AA 9D FD 09 A0 F2 In der Zwischenzeit wurden vom SIM SRES und Kc berechnet. Kc und SRES werden verschlüsselt übertragen SRES: 99 99 99 99 Cipher Key Kc: 99 99 99 99 99 99 99 99

7.85401522 APDU Header [CLA INS P1 P2 P3]: (A0 A4 00 00 02) Incoming data (2 bytes):3F 00 Return code [SW1 SW2]: 9F 1B

SELECT (MF) Command: SELECT Status: OK - response length 27 Current DF: Master File (3F00) Current EF: None Time: 7.854 s File ID: Master File

7.86278848 APDU Header [CLA INS P1 P2 P3]: (A0 A4 00 00 02) Incoming data (2 bytes):7F 20 Return code [SW1 SW2]: 9F 1B

SELECT (GSM) Command: SELECT Status: OK - response length 27 Current DF: GSM (7F20) Current EF: None Time: 7.863 s File ID: GSM

7.88046426 APDU Header [CLA INS P1 P2 P3]: (A0 A4 00 00 02) Incoming data (2 bytes):6F 20 Return code [SW1 SW2]: 9F 0F

SELECT (Kc) Command: SELECT Status: OK - response length 15 Current DF: GSM (7F20) Current EF: Cipherkey Kc (6F20) Time: 7.880 s File ID: Ciphering key Kc

7.8893086 APDU Header [CLA INS P1 P2 P3]: (A0 D6 00 08 01) Incoming data (1 bytes): 03 Return code [SW1 SW2]: 91 96

UPDATE BINARY (Offset 8, Len 1) Command: UPDATE BINARY Status: OK -Proactive SIM command pending - response length 150 Current DF: GSM (7F20) Current EF: Ciphering key Kc (6F20) Time: 7.889 s Offset: 8 Length: 1 Ciphering key sequence number: Bits 8-4: 00000 Ciphering key sequence number: 3

7.90363542 APDU Header [CLA INS P1 P2 P3]: A0 12 00 00 96 Outgoing data (150 bytes): D0 81 93 81 03 01 13 00 82 02 81 83 85 00 86 07 91 94

FETCH (SEND SHORT MESSAGE) Command: FETCH Status: OK Current DF: GSM (7F20) Current EF: Ciphering key Kc (6F20) Time: 7.904 s

66

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

71 01 67 50 62 8B 7D 01 FF 05 81 00 00 F3 00 F4 73 08 09 04 00 01 01 01 01 01 FF FF 05 37 04 80 02 80 01 80 01 80 01 FF FF 80 01 80 01 80 01 FF FF 80 01 80 01 00 01 FF FF FF FF FF FF 80 01 80 01 80 01 FF FF 00 04 00 01 00 01 00 01 FF FF FF FF 00 01 00 01 04 03 04 FF FF 02 0B 04 01 00 17 26 01 90 01 04 11 08 01 0B 04 98 94 20 00 00 10 76 47 09 84 07 03 04 01 99 03 09 04 3A 23 91 60 47 46 12 53 Return code [SW1 SW2]: 90 00

Proactive SIM Command Command Details Command Number: 1 Command Name: SEND SHORT MESSAGE Command Qualifier: packing not required Device Identity Source: SIM Destination: Network Alpha Identifier: Address TON: International Number Numbering plan identification: ISDN/ telephony numbering plan (Rec. E.164/ E.163) Dialling number string: 491710760526 SMS TPDU ………………………………………………… TP-User Data Length: 115 TP-User Data(hexadecimal): 08 09 04 00 01 01 01 01 01 FF FF 05 37 04 80 02 80 01 80 01 80 01 FF FF 80 01 80 01 80 01 FF FF 80 01 80 01 00 01 FF FF FF FF FF FF 80 01 80 01 80 01 FF FF 00 04 00 01 00 01 00 01 FF FF FF FF 00 01 00 01 04 03 04 FF FF 02 0B 04 01 00 17 26 01 90 01 04 11 08 01 0B 04 98 94 20 00 00 10 76 47 09 84 07 03 04 01 99 03 09 04 3A 23 91 60 47 46 12 53

7.97141386 APDU Header [CLA INS P1 P2 P3]: (A0 D6 00 00 08) Incoming data (8 bytes): 99 99 99 99 99 99 99 99 Return code [SW1 SW2]: 90 00

UPDATE BINARY (Offset 0, Len 8) Command: UPDATE BINARY Status: OK Current DF: GSM (7F20) Current EF: Ciphering key Kc (6F20) Time: 7.971 s Offset: 0 Length: 8 Command parameters/data: 8 bytes 99 99 99 99 99 99 99 99

Die verbleibenden 15 Bytes der Antwort aus Select Kc werden bei Marke 9.14585222s (SELECT ADN) über-

tragen. Die verbleibenden 27 Bytes der Antwort aus Select MF, bzw. DFGSM setzen sich zusammen aus den obi-

gen 15 Bytes (ADN) und den bei Marke 11.3170732s (LOCI) übertragenen 12 Byte.

Im Folgenden werden anhand eines SMS-PP Downloads noch der ENVELOPE-Prozess demonstriert und die

Abarbeitung des daraus resultierenden FETCH (DISPLAY TEXT)-, STATUS (GSM)- und abschließend des

TERMINAL RESPONSE (DISPLAY TEXT)-Kommandos.

67

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

37.14806338 APDU Header [CLA INS P1 P2 P3]: (A0 C2 00 00 AF) Incoming data (175 bytes): D1 81 AC 82 02 83 81 06 07 91 94 71 01 67 51 62 8B 81 9C 04 05 85 00 11 F2 7F F6 20 30 82 90 94 50 40 8C 8B AC 17 14 F1 3C A2 D8 E1 0A 7F BB 40 91 58 00 00 02 41 0F 0A 7F BB A0 E4 D6 00 15 02 00 01 26 7F 10 6F 40 DC 01 04 1E 45 69 67 65 6E 65 20 52 75 66 6E 75 6D 6D 65 72 07 91 94 71 70 63 09 27 FF FF FF FF FF FF 24 FF FF FF FF 0E 81 00 1C 0D 1A 04 49 68 72 65 20 52 75 66 2D 4E 72 3A 20 30 31 37 30 2D 37 33 36 39 30 37 32 14 7F BB A0 E4 D6 00 3A 0C 09 04 3A 23 91 60 47 46 12 53 FF FF 09 7F BB A0 E4 D6 00 64 01 00 D9 BF Return code [SW1 SW2]: 91 27

ENVELOPE (SMS-PP Download) Command: ENVELOPE Status: OK-ProactiveSIM command pending - response length 39 Current DF: GSM (7F20) Current EF: LOCI (6F7E) Time: 37.148 s SMS-PP DOWNLOAD Device Identity Source: Network Destination: SIM Address Type of number: International Number Numbering plan identification: ISDN/ telephony numbering plan (Rec. E.164/ E.163) Dialling number string: 491710761526 SMS TPDU …………………………………………… TP-User Data Length: 140 TP-User Data (hexadecimal): 8B AC 17 14 F1 3C A2 D8 E1 0A 7F BB 40 91 58 00 00 02 41 0F 0A 7F BB A0 E4 D6 00 15 02 00 01 26 7F 10 6F 40 DC 01 04 1E 45 69 67 65 6E 65 20 52 75 66 6E 75 6D 6D 65 72 07 91 94 71 70 63 09 27 FF FF FF FF FF FF 24 FF FF FF FF 0E 81 00 1C 0D 1A 04 49 68 72 65 20 52 75 66 2D 4E 72 3A 20 30 31 37 30 2D 37 33 36 39 30 37 32 14 7F BB A0 E4 D6 00 3A 0C 09 04 3A 23 91 60 47 46 12 53 FF FF 09 7F BB A0 E4 D6 00 64 01 00 D9 BF

37.88551508 APDU Header [CLA INS P1 P2 P3]: (A0 12 00 00 27) Outgoing data (39 bytes): D0 25 81 03 01 21 81 82 02 81 02 0D 1A 04 49 68 72 65 20 52 75 66 2D 4E 72 3A 20 30 31 37 30 2D 37 33 36 39 30 37 32 Return code [SW1 SW2]:90 00 „high priority“ ergibt sich aus dem ersten Bit des 5ten Bytes (Command Qualifier)

FETCH (DISPLAY TEXT) Command: FETCH Status: OK Current DF: GSM (7F20) Current EF: Location Information (6F7E) Time: 37.886 s Proactive SIM Command Command Details Command Number: 1 Command Name: DISPLAY TEXT Command Qualifier: high priority, wait for user to clear message Device Identity Source: SIM Destination: (auf ME) Display Text String Data Coding Scheme:Text is uncompressed,no message class mea-ning8-bit data Text String: Ihre Ruf-Nr: 0170-7369072

68

Kapitel 4.3: Die Interaktion zwischen ME und SIM am Beispiel eines Traces ________________________________________________________________

40.93253926 APDU Header [CLA INS P1 P2 P3]: (A0 F2 00 00 07) Outgoing data (7 bytes): 00 00 00 05 7F 20 02 Return code [SW1 SW2]:90 00

STATUS (GSM) Command: STATUS Status: OK Current DF: GSM (7F20) Current EF: Location information (6F7E) Time: 40.933 s RFU bytes 1-2: 00 00 Memory available: 5 bytes File ID: 7F20 Type of file: Dedicated file

45.49695128 APDU Header [CLA INS P1 P2 P3]: (A0 14 00 00 0C) Incoming data (12 bytes): 81 03 01 21 81 02 02 82 81 83 01 00 Return code [SW1 SW2]:90 00

TERMINAL RESPONSE (DISPLAY TEXT) Command: TERMINAL RESPONSE Status: OK Current DF: GSM (7F20) Current EF: Location information (6F7E) Time: 45.497 s Command Details Command Number: 1 Command Name: DISPLAY TEXT Command Qualifier: high priority wait for user to clear message Device Identity Source: ME Destination: SIM Result, General Result: Command performed successfully

85.98900232 Event Power off

(Power Off) Event: Power Off Time: 85.989 s

Da ein Teil aller Vorgänge ausschließlich innerhalb von SIM und ME stattfinden, konnte in diesem Kapitel nur

der Teil gezeigt werden, der durch die Übermittlung vom einen in das andere Medium sichtbar gemacht werden

konnte. Letztlich sind genau diese Schnittstellen die spezifizierten Zusammenhänge, da es für andere Kompo-

nenten keine Rolle spielt, in welcher Reihenfolge ein Gerät Befehle abarbeitet, solange der Output anschließend

die erwartete Form hat, wodurch eine korrekte Interaktion der einzelnen Funktionseinheiten gewährleistet ist.

69

Kapitel 5: UICC: Phase 2+ - Die Multiapplikationskarte des UMTS ________________________________________________________________ 5 UICC: Phase 2+ - Die Multiapplikationskarte des UMTS

Mit Phase 2+ wird die UICC-Karte (Universal Integrated Circuit Card) spezifiziert. Im Gegensatz zur SIM-Karte

handelt es sich bei der UICC-Karte um eine Multi-Application-Plattform, also um eine Karte, die mehrere, auch

grundverschiedene Anwendungen vereinigen kann. Sie ist für den Endkunden zur Zeit noch nicht auf dem Markt

verfügbar und wird in Verbindung mit den entsprechenden UMTS Diensten und Endgeräten auch erst ab An-

fang-Mitte 2003 verfügbar sein. Da sich die Karte sowie die Anwendungen nach wie vor in der Entwicklung be-

finden, ist bis zur endgültigen Marktfreigabe noch mit diversen Änderungen gegenüber dem derzeitigen Stand zu

rechnen. Die UICC wurde für Europa von ETSI als Smart Card spezifiziert. Für dieses Kapitel wurde primär die

ETSI-Spezifikation referenziert. Nur in Fällen, in denen die ETSI-Spezifikation auf die internationale Variante

verweist wurde diese als Referenz verwendet. Die internationale Spezifikation 3GPP TS 31.101 [25] der UICC

schreibt im Gegensatz zur ETSI-Spezifikation ETSI TS 102 221 [17] keinen bestimmten Kartentyp vor. Sie ent-

hält die gleichen Informationen wie die ETSI-Spezifikation und zusätzlich einige weitere Informationen, wie die

EFs auf Masterfile-Level, auf die die ETSI-Spezifikation verweist. Es kann durchaus sein, dass in anderen Regi-

onen der Welt andere Chipkarten mit ganz anderen Charakteristika für die Umsetzung von UMTS verwendet

werden.

5.1 Das Trägersystem Physikalische Charakteristika:

Die physikalischen Parameter der UICC Karte entsprechen den in ISO/IEC 7816-3 definierten Richtlinien. Die

UICC kann sowohl im Plugin Format als auch im ID-1 Format ausgegeben werden.

Übertragungsprotokolle:

Die UICC unterstützt sowohl das Protokoll T=0, wie eine SIM-Karte als auch das T=1 Protokoll. Dies gewähr-

leistet, dass zwischen ME und UICC sowohl eine zeichenorientierte, als auch eine paketorientierte Kommunika-

tion stattfinden kann. Ein Umschalten zwischen den Protokollen wird durch einen Warmstart (PTS) realisiert.

Beim Empfang von drei fehlerhaften Blöcken in Folge wird das ME einen Warmstart erzwingen und wieder auf

das Protokoll T=0 umschalten. Eine maximale Paketgröße, die zwischen UICC und ME ausgetauscht werden

kann wurde auf 32 Byte festgelegt. Das ME darf aus dem Netz Blöcke bis maximal 256 Byte empfangen und

auch diese maximale Paketgröße ins Netz senden. Die minimale Paketgröße ist weder für die Kommunikation

zwischen Karte und ME noch für die Kommunikation zwischen Netz und ME spezifiziert. Dies obliegt den

Netzbetreibern und Kartenherausgebern. Für die Verwendung des T=1 Protokolls sind (vgl. [17]. Kapitel 7.2.3)

Wartezeiten definiert:

• CWT (Character Waiting Time) definiert die relative, maximale Zeitverzögerung (etu: elementary time

unit), die zwischen zwei in einem Block übertragenen Zeichen verstreichen darf. Sie entspricht

(11+2CWI) etu, wobei der CWI (Character Waiting Integer) mit Werten von 0-5 belegt werden kann.

• BWT (Block Waiting Time) definiert die relative Zeit zwischen dem letzten übertragenen Zeichen eines

Blocks und dem ersten zu übertragenden Zeichen des Folgeblocks. Ihr ist in der Spezifikation kein fes-

ter Wert zugewiesen worden. Die BWT soll verwendet werden, um eine ggf. nicht antwortende Karte

entdecken zu können.

70

Kapitel 5.1: Das Trägersystem ________________________________________________________________

• BGT (Block Guard Time) entspricht einer Sicherheitszeit, die zwischen zwei zu übertragenden Blöcken

verstreichen muss und ist auf 22 etu festgelegt.

Logische Charakteristika:

Die Umsetzung der ursprünglich als physikalisches Medium vorliegenden SIM-Karte auf ein logisches Modul

wird durch die Einführung einer neuen Klasse von Dedicated Files bewerkstelligt, den Application Dedicated

Files (ADF). Unterhalb eines solchen ADF stehen alle Anwendungen (DFs und EFs), die zu eben dieser Anwen-

dung gehören. Das Masterfile des SIM wird also durch ein ADFSIM ersetzt. Die gesamte, restliche Struktur un-

terhalb des ursprünglichen Masterfiles, wie auch die Nomenklatur kann identisch erhalten bleiben.

Alle Module und deren FIDs unterliegen etwas anders gearteten Nomenklaturkonventionen. Die Festlegung der

FIDs ist zwar ähnlich strukturiert wie beim SIM, jedoch aufgrund der Vielzahl unterschiedlicher Dateien etwas

unübersichtlicher, insbesondere weil die aus dem SIM übernommenen Dateien zum Teil ihre alten Identitäten

beibehielten. Zusätzlich zu den FIDs wurden manche Dateien mit sogenannten Short Elementary File Identifier

(SFI) ausgestattet (s.u.).

ADFs beginnen mit ’7F FF’. DFs für den administrativen Bereich werden die hexadezimalen Bytekombinatio-

nen ’7F 4X’, ’5F 1X’, und ’5F 2X’ zugewiesen. Im operationalen Bereich stehen 8 unterschiedliche FIDs (An-

fänge) für jeweils unterschiedliche First Level DFs (TELECOM, GSM, DCS1800, etc.) zur Verfügung, deren

erstes Byte übereinstimmend mit ’7F’ bezeichnet wird. Einige IDs von Second Level DFs (unter DFTELEKOM)

wurden ebenfalls reserviert (DFGRAPHICS: ’5F 50’ und DFPHONEBOOK: ’5F 3A’). Die Systematik bei der Nomen-

klatur der File IDs bei EFs richtet sich nach den jeweils übergeordneten DFs, und variiert im ersten Byte zwi-

schen ’2F’, ’4F’ und ’6F’. Alle unter dem Masterfile (’3F 00’) befindlichen EFs beginnen mit dem Byte ’2F’ so

wie auch alle EFs unterhalb von Second Level DFs mit den Bytes ’4F 1X’ beginnen. Die vollständigen Nomen-

klaturfestlegungen sind in der UICC Spezifikation ETSI TS 102 221 in Kapitel 8.6 nachzulesen.

Datenauswahlverfahren:

Die Auswahl von Anwendungen erfolgt durch den jeweiligen Application Identifier (AID). Wurde eine Anwen-

dung ausgewählt, so gilt diese als das Current Application Dedicated File und kann ab dem Moment implizit

durch ’7F FF’ adressiert werden, bis ein anderes ADF ausgewählt wird. Sobald ein anderes ADF ausgewählt

wurde, gilt die zuvor aktive Anwendung als deaktiviert (nicht zu verwechseln mit den Anweisungen ACTIVATE

und DEACTIVATE). Sie kann jederzeit wieder aufgenommen (current) werden.

Wie schon bereits vom SIM und Chipkarten allgemein her bekannt ist, gibt es auch bei der UICC drei Typen von

Elementary Files (transparent, linear fixed, und cyclic) und die bekannten Zugriffsmethoden. Neu eingeführt

wurde das Auswählen von Verzeichnissen und Dateien nach Pfad-Referenzierung und das direkte Ansprechen

von Dateien mit den Befehlen READ BINARY, UPDATE BINARY, READ RECORD, UPDATE RECORD,

INCREASE und SEARCH RECORD in Verbindung mit dem Short File Identifier (SFI) der Datei als Parameter.

Eine weitere Neuerung beim Datenzugriff ist der direkte Zugriff auf Dedicated Files anhand des vollständigen

DF-Namens oder auch nur dem Anfang des Namens (SELECT by partial DF Name, vgl. [17], Kapitel 8.5.1.2).

Des Weiteren ist nun auch ein „SELECT by path“ möglich.

Um als Anwender den Zugriff auf die einzelnen, teilweise sehr unterschiedlich gearteten Anwendungen auf der

Multiapplikations-Karte besser kontrollieren bzw. gegen Unbefugte schützen zu können, wurde zusätzlich zu der

71

Kapitel 5.1: Das Trägersystem ________________________________________________________________ aus dem SIM bekannten PIN (1 und 2 für die gesamte Karte) eine eigene PIN für jede Anwendung eingeführt,

die jeweils einzeln aktiviert bzw. deaktiviert werden können.

Im Übrigen gelten die gleichen Zugriffsregeln auf Elementary Files wie beim SIM. INVALIDATE und REHA-

BILITATE wurden in DEACTIVATE FILE und ACTIVATE FILE umbenannt. Die Funktionen entsprechen in

ihrer Wirkung den jeweiligen Pendants (vgl. [17], Kapitel 11.1.14, 11.1.15). Bei den Anweisungen ENABLE

CHV, DISABLE CHV, CHANGE CHV, etc. wurde „CHV“ in „PIN“ umgeändert, also ENABLE PIN, DI-

SABLE PIN, CHANGE PIN, etc (vgl. [17], 11.1.11).

APDUs:

Die Gestalt von Command- und Response-APDU ist identisch zu der im SIM verwendeten. Es gibt jedoch eine

Reihe neuer Statusworte. Die Statusworte (vgl. [17], Kapitel 10.2, Tabelle 10.16) ’91 XX’ und ’93 00’ dürfen

von der UICC nur dann verwendet werden, wenn das verwendete Terminal USAT unterstützt (letzter Satz 10.2).

Aus dieser Formulierung kann abgeleitet werden, das es durchaus denkbar ist, dass einzelne Anbieter insbeson-

dere Endgerätehersteller USAT nicht implementieren.

Neue Befehle:

Prinzipiell wird bei der UICC zwischen allgemein gültigen Befehlen und Anwendungsspezifischen Befehlen (für

jede auf der UICC Karte befindliche Anwendung) unterschieden, wie z.B. Befehlen, die ausschließlich das U-

SIM versteht oder die nur dann verwendet werden dürfen, wenn die USAT-Anwendung implementiert wurde.

Im Vergleich zum SIM kennt die UICC zwei neue allgemein gültige Anweisungen:

• AUTHENTICATE: Erwartet als Eingabe eine Herausforderung (vgl. [17], Kapitel 11.1.16), z.B. einen

Chiffre, den nur die explizite Anweisung entschlüsseln kann und liefert als Rückgabe sowohl verschlüs-

selte Daten als auch die Authentisierung. AUTHENTICATE realisiert ein klassisches Challenge-

Response Verfahren, das vom ME initialisiert und von der UICC vervollständigt wird. Diese Anwei-

sung ersetzt RUN_GSM_ALGORITHM, ist aber wie in Kapitel 5.2 noch gezeigt wird wesentlich

mächtiger.

• MANAGE CHANNEL: MANAGE CHANNEL ist noch nicht implementiert und für (vgl. [17], Kapi-

tel 11.1.17) „zukünftige Studien“ des 3G Konsortiums reserviert.

Neue Dateien auf dem MF Level:

Aufgrund der neuen (bezogen auf das SIM, wo es nur ein einziges Modul gibt) Struktur der Daten auf der UICC

Karte gibt es direkt unterhalb des Master Files neben den bekannten Dateien EFICCCID und EFELP (das in EFPL =

Prefered Language umbenannt wurde), die immer noch vorhanden sind, zwei zusätzliche Dateien:

• EFDIR (Directory): Es handelt sich dabei um eine Datei vom Typen Linear Fixed auf die für das ME nur

lesender Zugriff erlaubt ist und alle anderen Aktionen, wie UPDATE, DEACTIVATE und ACTIVATE

ausschließlich ADM vorbehalten sind. Sie stellt so etwas wie ein Inhaltsverzeichnis für ADFs dar. Die

Datei trägt den Identifier ’2F 00’ und enthält eine nicht festgelegte Anzahl von Records, in denen

Anwendungs-Templates in BER-TLV-Objekten codiert sind. Die Records dürfen eine Länge von 127

Byte nicht überschreiten und es muss zumindest der Application Identifier des Daten Objekts (AID DO)

enthalten sein. Das EFDIR darf zusätzlich auch auf anderen Ebenen als direkt unter dem MF existieren.

72

Kapitel 5.1: Das Trägersystem ________________________________________________________________

• EFARR (Access Rule Reference): In dieser Datei werden die Zugriffsbedingungen für auf der UICC

implementierte ADFs in TLV-Objekten als Records codiert. Es hat die Struktur Linear Fixed und kann

ausschließlich gelesen werden (vgl. EFDIR). Jedes TLV-Objekt enthält genu einen Record, der wiederum

genau eine Zugriffsregel enthält. Nicht benötigte Bytes in den Records werden mit ’FF’ aufgefüllt.

Security Environment:

Im Gegensatz zum SIM gibt es bei der UICC-Karte eine Vielzahl möglicher Passworte (PIN), die individuell für

einzelne Anwendungen und Funktionen definiert werden können (vgl. [17], Kapitel 9). Allen Anweisungen, die

auf eine bestimmte Datei ausgeführt werden können, müssen die entsprechenden Sicherheitsbedingungen zuge-

ordnet werden. Die möglichen Sicherheitsbedingungen jeder einzelnen Anweisung (Security Condition, SC)

werden in den File Control Parameters (FCP, wie auch schon beim SIM) beschrieben. Zur Verwaltung der an-

wendungsspezifischen Nummern (PINs) wurde eine eigene Sicherheitsumgebung (Security Environment, SE)

geschaffen, die auch eine globale PIN definiert. Diese globale PIN kann über ein Setzen der Security Environ-

ment ID (SEID) zwei Zustände annehmen: Entweder ist sie aktiviert (SEID = ’01’) oder deaktiviert (SEID =

’00’). Hat die SEID den Wert ’00’, ist keine globale Authentisierung möglich und die universelle PIN ist deakti-

viert. Die Sicherheitsumgebung muss bei Multi-Applikationskarten unbedingt auch im EFARR referenziert wer-

den, so dass eine universelle PIN, die im SE definiert ist, auch die jeweiligen PINs der einzelnen Anwendungen

ersetzen kann (vgl. [17], Kapitel 9.3).

Das SE unterscheidet drei unterschiedlichen Arten von PINs (vgl. [17], Kapitel 9.4):

• Universal PIN: Die universelle PIN soll in einer Multi-Applikations-Umgebung ermöglichen, alle An-

wendungen mit nur einer einzigen PIN zu sichern. Somit muss jede Anwendung, die auf der UICC imp-

lementiert wird, auch diese universelle PIN berücksichtigen. Sie kann deaktiviert werden, was zur Folge

hat, dass ggf. für einzelne Anwendungen definierte PINs eingegeben werden müssen.

• Application PIN: Die Application PIN, auch Level 1 PIN genannt, sichert entweder eine einzige An-

wendung (ADF) oder aber eine Gruppe von Anwendungen. Sie kann ebenso dazu verwendet werden,

einzelne DFs oder Gruppen von DFs zu sichern, die nicht ADFs sind. In jedem Fall werden Gruppen

von ADFs oder DFs, die mit einer einzigen PIN gesichert sind, vom Sicherheitsstandpunkt aus als eine

einzige Anwendungsgruppe betrachtet (vgl. [17], 9.4.2).

• Local PIN: Der Gültigkeitsbereich dieser PIN ist auf die Daten eines einzigen ADFs oder DFs be-

schränkt und gilt mit einer Ausnahme für alle darunter liegenden Verzeichnisse und Dateien. Die Aus-

nahme: Ist eine lokal beschränkte PIN auf ein ADF oder DF oberhalb von DFTELEKOM festgelegt wor-

den, nicht aber explizit für das DFTELEKOM, so gilt sie auch nicht für dieses (vgl. [17], Kapitel 9.4.3).

In Relation zu den Zugriffsbedingungen auf Dateien (vgl. Tabelle 5, S.35) beim SIM wurde bei der UICC bis auf

die Bezeichnung der Passworte die Anzahl der reservierten bzw. ADM zur Verfügung stehenden Level nichts

geändert:

Level Zugriffs Bedingung 0 ALWays 1 PIN 1 2 PIN 2

3, 4 Reserviert für zuk. Anw. 5, 6 ADM

7 NEVer

Tabelle 11: Zugriffsbedingungen auf Dateien nach Sicherheitslevel

73

Kapitel 5.1: Das Trägersystem ________________________________________________________________ Wie in [17] Kapitel 8.4.5 nachzulesen ist, schließen sich SIM-Anwendungen und USIM-Anwendungen gegen-

seitig aus. Die Aktivierung des Einen führt zur sofortigen Deaktivierung des Anderen. Eine USAT-Anwendung

kann nur dann gestartet werden, wenn eine USIM-Session läuft.

Neben den erhöhten Sicherheitsanforderungen insbesondere an das USIM, die in Kapitel 5.2 erläutert und deren

Umsetzung dort analysiert wird, gibt es neben der Unterstützung von Standard-Diensten des Mobilfunks weitere

Anforderungen an die UICC-Karte:

Maximal mögliche Flexibilität gegenüber der Implementierung neuer Dienste:

Durch die europaweite Spezifikation der Smartcard als neue Mobilfunkkarte und die damit gewählte Anwen-

dungs-unabhängige Architektur ist eine physikalische sowie logische Beschränkung zur Implementierung neuer

Dienste nur durch die Speicherkapazität (256kb ROM) gegeben. Da Anwendungen anstatt vollständig auf der

Karte gespeichert zu sein, auch auf dem mobilen Endgerät gespeichert werden, und die auf der Karte gespeicher-

ten Daten somit auf das Nötigste, wie Initialisierungssequenzen, Sicherheitsmechanismen, vertrauliche Daten,

etc. beschränkt sind, kann das Speicherplatzproblem vernachlässigt werden. Die Anwendungs-Unabhängigkeit

der Smartcard ist bedingt durch die spezielle Architektur dieser Chipkarte: Während das Betriebsystem des auf

einer Basic Card realisierten SIM explizit auf die darauf enthaltenen Anwendungen ausgerichtet ist, sind bei der

Smartcard ein Anwendungsunabhängiger Kernel in Verbindung mit einem Command-Manager definiert worden.

Sie stellen einen grundlegenden Befehlssatz und den zugehörigen Interpreter zur Verfügung. Zusätzlich ist eine

allgemeine Programmierschnittstelle (API) definiert, die es dem Programmierer bei Einhaltung der definierten

Regeln erlaubt auf die darunter liegenden Bausteine zuzugreifen. In der Schicht unterhalb des Kernels befinden

sich eine leistungsstarke kryptographische Einheit zur Berechnung von kryptographischen Algorithmen, wie el-

liptischen Kurven, RSA, der Erzeugung von Zufallszahlen, etc. und die Managementeinheiten für die Dateiver-

waltung, die Verwaltungseinheit der Sicherheitsparameter (Prozeduren zur Verifikation und zum Aushandeln

von Passworten) sowie die I/O-Managementeinheit (vgl. [i]).

Alleine durch die Wahl der Smartcard als Chipkarte ist die zur Zeit maximal mögliche Flexibilität bzgl. noch

unbekannten, zu implementierenden Anwendungen bereits gegeben. Ob eine Java Card mit einer JVM verwen-

det wird, ist abhängig von den jeweiligen Kartenherausgebern und noch nicht endgültig geklärt.

.

Anwendung Anwendung

Anwendung

Kommando Manager

Kernel

Sicherheits-Manager

kryptograph. Einheit

I/O Manager

Datei Manager

Interne API

Abbildung 44: Der logische Aufbau einer Smartcard

74

Kapitel 5.1: Das Trägersystem ________________________________________________________________ Management der auf der Karte enthaltenen Module und Kooperation mit anderen Modulen/Karten:

Durch die Verwendung der oben beschriebenen Architektur verwenden alle Module eine gemeinsame Schnitt-

stelle zum Kernel und können von diesem somit als reine Anwendungen betrachtet werden. Die Anwendungen

(Module), die auf der Karte enthalten sind, werden durch das auf dem Masterlevel implementierte EFDIR ange-

zeigt. Das dort ebenfalls angesiedelte EFARR erläutert die Bedingungen unter denen auf das betreffende Modul

zugegriffen werden darf. Daher stellt sich die Frage eines unterschiedlichen Handlings seitens des Kernels nicht.

Prozeduren zum Zugriff auf die einzelnen Module und zum parallelen Zugriff auf mehrere Module:

Die Module können aufgrund der objektorientierten Umsetzung untereinander auf die gleiche Weise kommuni-

zieren, wie es Anwendungen in der PC-Welt bereits längst realisieren. Nachrichten an andere Module werden

durch Adressierung der entsprechenden SAPs durch den Protokollstapel hindurch zur anderen Anwendung bzw.

zum anderen Modul (anhand seinem AID bzw. FID) weitergeleitet. Ein paralleler Zugriff auf mehrere Module ist

primär eine Problemstellung bzgl. der Implementierung der Anwendungen und Fähigkeiten des Endgeräts.

Module auf der UICC-Karte:

Die Module USIM und USAT sind laut Spezifikation von UMTS obligatorisch auf der UICC zu implementieren.

Die Implementierung der anderen Module ist optional. Damit ist absehbar, dass Module, die ein Netzanbieter in

seine Karten integriert, nicht notwendig auch in anderen Netzen verwendet werden können. Zu diesen zählen

insbesondere das Wireless Identity Module und Anwendungen für M-Commerce (Mobile Commerce). Außer-

dem kann man nicht damit rechnen, dass die ehemalige in Hardware realisierte Phase 2 SIM-Karte auch bei allen

Anbietern als Softwaremodul auf der UICC integriert wird. Zwar ist eine absolute Abwärtskompatibilität der

Engeräte gefordert, es ist jedoch allein den Kartenherausgebern überlassen, ob sie zusätzlich zu den Phase 2+

UICC-Karten weiter die Phase 2 SIM-Karten ausgeben oder ob sie diese in der UICC-Karte integrieren. Die T-

Mobile International arbeitet derzeit an einer solchen Kombinationskarte aus dem 2G-SIM und dem 3G-USIM.

Diese Karte wird für beide Anwendungen ein und dieselbe IMSI verwenden. Diese Karte soll so bald wie mög-

lich, jedenfalls vor dem Start von UMTS eingeführt werden, so dass ggf. nur minimale Umtauschaktionen be-

wältigt werden müssen, wenn UMTS endgültig eingeführt wird.

Damit wird T-D1 voraussichtlich einen größeren Leistungsumfang mit den UICC-Karten anbieten können, als

von den Spezifikationen her gefordert wird. Ein festes Vorhaben ist jedoch Abwärtskompatibilität zu Phase 2

MEs unter evtl. Einbeziehung eines Krypto-Coprozessors für das WIM. Ob nun das Modul WIM von T-D1 tat-

sächlich implementiert wird, steht in direktem Zusammenhang mit der Fragestellung, ob seitens T-D1 eine eige-

ne PKI (Public Key Infrastructure) für WAP-basierte M-Commerce Anwendungen aufgebaut wird. Ebenso un-

geklärt ist bis heute, auf welche Weise reine GSM Service Provider weiter von T-D1 unterstützt und ob noch an-

dere M-Commerce Konzepte implementiert werden.

USIM:

Im Gegensatz zur Spezifikation TS11.11 [15] des SIM enthält die Spezifikation des USIM TS 31.102 [18] nur

Beschreibungen von den auf dem USIM enthaltenen Dateien und von Vorgängen auf der Anwendungsschicht,

wie z.B. Management-Prozeduren, sicherheitsrelevante Prozeduren und Interaktionen mit anderen Modulen.

An dieser Stelle werden lediglich die wichtigsten der neuen EFs beschrieben. Eine direkte Gegenüberstellung der

Dateien von USIM und SIM findet im Kapitel 6 statt und sicherheitsrelevante Prozeduren werden hauptsächlich

75

Kapitel 5.1: Das Trägersystem ________________________________________________________________ in Kapitel 5.2 beschrieben. Die folgende Tabelle 12 zeigt die in Relation zu dem SIM hinzugekommenen Datei-

en. Die blau markierten Dateien werden im Anschluss näher erläutert. Die Tabelle wurde aus den einzelnen Be-

schreibungen der Dateien herausinterpretiert.

Dateityp File ID Struktur des Files, Länge

vgl. TS 31.102 Kapitel Beschreibung

USIM ADF ’7F FF’ 4.2 EFKeys ’6F 08’ Transparent 33 bytes 4.2.3 Cyphering and Integrity Keys EFKeysPS ’6F 09’ Transparent 33 bytes 4.2.4 (EFKeys) … for Packet Switched domain EFUPLMNsel ’6F 30’ Transp. 5n (n>7) bytes 4.2.5 Universal PLMN Selector EFUST ’6F 38’ Transp. X (X>1) bytes 4.2.8 USIM Service Table EFPSLOCI ’6F 73’ Transparent 14 bytes 4.2.23 Packet Switched LOCation Information EFICI ’6F 80’ Cyclic, X+28 bytes 4.2.33 Incoming Call Information EFOCI ’6F 81’ Cyclic, X+26 bytes 4.2.34 Outgoing Call Information EFICT ’6F 82’ Cyclic, 3 bytes Incoming Call Timer EFOCT ’6F 83’ Cyclic, 3 bytes 4.2.36 Outgoing Call Timer EFEXT5 ’6F 4E’ Linear Fixed, 13 bytes 4.2.37 Extension 5 EFCCP2 ’6F 4F’ Linear Fixed, 14 bytes 4.2.38 Capability Configuration Parameters 2 EFHiddenkey ’6F C3’ Transparent, 4 bytes 4.2.42 Hidden Key (hidden phonebook entries) EFEST ’6F 56’ Transparent X bytes 4.2.47 Enabled Services Table EFACL ’6F 57’ Transp. X (X>1) bytes 4.2.48 Access Point Name Control List EFSTART-HFN ’6F 5B’ Transparent, 6 bytes 4.2.51 Initialisation val. for Hyperframe numb. EFTHRESHOLD ’6F 5C’ Transparent, 3 bytes 4.2.52 Maximum Value of START EFOPLMNsel ’6F 5D’ Transp. 5n (n>7) bytes 4.2.53 OPLMN Selector EFPHPLMNAT ’6F 5E’ Transparent, 2 bytes 4.2.54 Preferred HPLMN Access Technology EFARR ’6F 06’ Linear Fixed, X bytes 4.2.55 Access Rule Reference DFPhonebook ’5F 3A’ 4.4.2 EF PBR ’4F 30’ Linear Fixed, X bytes 4.4.2.1 Phone Book Reference EF IAP ’4F XX’ Linear Fixed, X bytes 4.4.2.2 Index Administration Phone Book EF PBC ’4F XX’ Linear Fixed, 2 bytes 4.4.2.5 Phone Book Control EF GRP ’4F XX’ LF. X (0<X<11)bytes 4.4.2.6 Grouping file EF AAS ’4F XX’ Linear Fixed, X bytes 4.4.2.7 Additional number Alpha String EF GAS ’4F XX’ Linear Fixed, X bytes 4.4.2.8 Grouping Information Alpha String EF ANR ’4F XX’ Lin. Fixed X+11 bytes 4.4.2.9 Additional Number EF SNE ’4F XX’ Lin. Fixed X+2 bytes 4.4.2.10 Second Name Entry EFUID ’4F 21’ Linear Fixed, 2 bytes 4.4.2.12.1 Unique Identifier of Phonebook entries EF PSC ’4F 22’ Transparent, 4 bytes 4.4.2.12.2 Phone book Synchronisation Counter EF CC ’4F 23’ Transparent,, 2 bytes 4.4.2.12.3 Change Counter EF PUID ’4F 24’ Transparent, 2 bytes 4.4.2.12.4 Previous Unique Identifier EF EMAIL ’4F XX’ Lin. Fixed, X+Y bytes 4.4.2.13 e-mail adress DFTELECOM ’7F 10’ 4.5 EFARR ’6F 06’ Linear Fixed, X Bytes 4.5.5 Access Rule Reference DFPhonebook ’5F 3A’ 4.6.2 EFCCP1 ’4F 3D’ Linear Fixed, 14 bytes 4.6.3 Capability Configurations Parameter 1

4.2.35

Tabelle 12: Dateien der USIM Spezifikation, die auf der SIM-Karte nicht enthalten sind

Wie EFCCP1 sind auch andere beim SIM bereits vorhandene Dateien an eine ganz andere Stelle des Verzeichnis-

baums versetzt worden. EFCCP1 befand sich beim SIM direkt unterhalb von DFTELECOM. Auffällig ist, dass das

EFARR unter dem ADFUSIM gleich zweimal in unterschiedlichen Baumtiefen implementiert wurde.

Die Auswahl der im Folgenden dargestellten EFs erfolgte nach Besonderheiten und weniger nach Relevanz, zu-

mal die meisten der beschriebenen Dateien optional zu implementieren sind. Es wurden eben solche EFs ausge-

wählt, die beim Phase 2 SIM nicht oder in anderem Zusammenhang existiert haben und die ggf. eine repräsenta-

tive Form für eine ganze Gruppe von EFs haben.

76

Kapitel 5.1: Das Trägersystem ________________________________________________________________ EFKeys und EFKeysPS: (siehe Annex A, Seite f, Nr.18 und 19)

EFKeys und EFKeysPS (vgl. [18], Kapitel 4.2.3, bzw. 4.2.4) haben dieselbe Form und unterscheiden sich ausschließ-

lich in der Funktion der jeweils gespeicherten Schlüssel. Der eine Schlüsselsatz wird für verbindungsorientierte

Datenübertragung verwendet, der andere bei der paketvermittelten Variante. Ein Schlüsselsatz setzt sich aus ei-

nem Tupel aus Schlüssel und Integritätsnachweis zusammen und wird durch eine spezielle Identifikationsnum-

mer repräsentiert. Schlüssel und Integritätsnachweis bestehen jeweils aus 16 Byte langen Bitfolgen und die ent-

sprechende Identifikationsnummer für das Tupel ist in 1 Byte codiert. Der Schlüssel wird häufig, mindestens je-

doch bei jeder Beendigung einer USIM-Session gewechselt (vgl. [18], Kapitel 5.1.2). Die Schlüssel verfügen ü-

ber eine eingeschränkte Lebensdauer, die in der Datei EFSTART-HFN definiert und in der Datei EFTHRESHOLD auf ei-

nen Maximalwert festgelegt ist. Neben den Identifikationsnummern haben beide Dateien auch eine Kurzidentifi-

kationsnummer SFI (Short Elementary File Identifier).

EFPSLOCI: (siehe Annex A, Seite g, Nr.20)

Wie auch das EFLOCI, das bereits vom SIM bekannt ist, beinhaltet auch das EFLOCIPS entsprechende Ortsinforma-

tionen für paketorientierte Dienste. Neben der Paket-Switched TMSI und dem zugehörigen Signaturwert ist ein

Routing Area Identifier enthalten sowie der Updatestatus der aktuell eingetragenen Routing Area.

EFICI und EFICT: (siehe Annex A, Seite g, Nr.21 und 22)

EFICI und EFOCI sowie EFICT und EFOCT haben jeweils zueinander fast das gleiche Format. Im ersten Fall (ICI

und OCI) unterscheiden sich die Dateien vom Format her lediglich im Statusfeld (Incoming Call Status), das bei

der abgehenden Variante nicht existiert (natürlich sind alle Einträge bzgl. Incoming bei OCI in Outgoing umge-

ändert) sowie der ID und SFI. Verwirrend ist die Tatsache, dass die Gesamtlänge bei EFICI mit X+28 Bytes an-

gegeben wird und bei der genau 1 Byte kleineren Datei EFOCI mit X+26 Bytes. EFICT und EFOCT sind vom For-

mat her identisch, beiden wurde keine SFI zugewiesen (vgl. [18], Kapitel 4.2.33/35).

In EFICI werden Informationen bzgl. eingehender Anrufe abgelegt. Es kann mit dem Telefonbuch unter DFTELE-

COM oder aber mit dem in ADFUSIM enthaltenen Telefonbuch verknüpft werden. Die Datei wird, wenn sie auf

dem USIM existiert und aktiviert wurde, immer dann aktualisiert, wenn ein eingehender Anruf ausgelöst wird.

Neben der exakten Zeit (Monat, Tag, Stunde, Minute, Sekunde, Zeitzone) wird ein Link zum Telefonbuch her-

gestellt, falls der Anrufer dort verzeichnet ist. Zusatzinformationen können im Erweiterungsfile EFEXT5 abgelegt

und mit dem EXT5 Record Identifier referenziert werden. EXT5 ist zu den 4 Erweiterungsfiles, die aus dem SIM

bekannt sind, im USIM hinzugefügt worden. Der Incoming Call Timer misst die Dauer von eingehenden und be-

reits eingegangenen Gesprächen (Summe aller eingegangenen Gespräche). Der tatsächliche Nutzen dieser beiden

Dateitypen (jeweils ein- und abgehend) ist aus der Spezifikation nicht zu entnehmen, sie verweist lediglich dar-

auf, dass die Dateien USIM spezifisch sind und in der USIM Anwendung enthalten sind. Alle 4 Dateien dienen

ausschließlich als History Information für den Benutzer.

EFHiddenkey: (siehe Annex A, Seite h, Nr.23)

Das Elementary File “Hiddenkey” enthält die Schlüsselinformationen für versteckte Telefonbucheinträge. Im

Telefonbuch können Einträge versteckt werden und anhand des EFHiddenkey kann das ME verifizieren, welche

Einträge es ohne weitere Eingaben anzeigen darf (vgl. [18], Kapitel 4.2.42).

EFEST: (siehe Annex A, Seite h, Nr.24)

Während es beim SIM lediglich das EFSST gibt, in dem alle verfügbaren und aktivierten Dienste aufgezeigt wer-

den, verfügt das USIM über zwei sich ergänzende Dateien EFUST (USIM Service Table) und EFEST. Dadurch

lässt sich die Berechtigung zur Nutzung der Dienste selektiv vergeben. Da das EFEST optional ist, reicht es aus,

77

Kapitel 5.1: Das Trägersystem ________________________________________________________________ das EFUST zu verwenden, um Zugriff auf die Dienste zu haben. In der Situation, dass Eltern ihren Kindern die

Nutzung diverser Dienste untersagen wollen, kann das EFEST verwendet werden. Ist das EFEST aktiv, kann die

Auswahl der verfügbaren Dienste eingeschränkt und mit der PIN2 gesichert werden. Nur wenn ein Dienst in bei-

den Dateien als aktiviert und verfügbar verzeichnet ist, kann er auch genutzt werden. Im Übrigen gleicht der

Aufbau dem bereits bekannten EFSST bzw. dem in USIM verwendeten EFUST (vgl. [18], Kapitel 4.2.47).

EFPBR: (siehe Annex A, Seite h, Nr.25)

In dieser optional zu implementierenden Datei vom Typ Linear fixed werden alle Dateien, die im Zusammen-

hang zum Telefonbuch stehen, in Form von TLV-Objekten zusammengefasst. Sie beschreibt die Struktur des Te-

lefonbuchs und dient dazu, verteilt gespeicherte Dateien aufzufinden. Da es möglich ist, dass innerhalb eines

einzigen Telefonbuchs öfter als nur einmal eine Datei vom gleichen Typ vorkommt (z.B. EFADN und EFADN 1)

und nicht für beide von vorne herein eine ID festgelegt wurde, ist eine Zusammenfassung aller IDs und SFIs

sinnvoll. Zusätzlich vermittelt diese Datei die Methode, auf welche Weise auf mehrere Dateien verteilte Einträge

zusammenzufügen sind, damit sie einen vollständigen Telefonbucheintrag ergeben (vgl. [18], Kapitel 4.4.2.1).

EFPBC: (siehe Annex A, Seite i, Nr.26)

In dieser Datei wird angezeigt, zu welcher Anwendung (GSM oder USIM) der Telefonbucheintrag gehört und

für welche der beiden Anwendungen er ggf. verborgen sein soll (vgl. [18], Kapitel 4.4.25).

EFEMAIL: (siehe Annex A, Seite i, Nr.27)

In den Feldern „E-mail Adress“ sind Strings gespeichert, die e-Mail Adressen definieren. Sind die beiden letzten

Einträge vorhanden, so nimmt Y den Wert „2“ an, wenn nicht den Wert „0“. Da e-Mailadressen ebenfalls im

EFADN abgespeichert werden können, kann vom EFEMAIL aus darauf verwiesen werden.

Die bereits bekannten Dateien aus dem SIM, die ins USIM übernommen wurden, sind von der Tatsache, dass

ihnen zum Teil ein SFI zugewiesen wurde, und von der veränderten Position im Dateibaum (siehe Kapitel 6)

kaum verändert worden.

USAT:

Bei dem direkten Vergleich der Spezifikationen TS 11.14 ([16] SAT) und TS 131 111 ([19] USAT) ließen sich

keine inhaltlichen Veränderungen feststellen. Die Worte SAT und SIM wurden in USAT, USIM und ggf. UICC

(je nachdem, welche Features des SIM in der SAT Spezifikation verwendet wurden) ausgetauscht und die IMSI

wurde in IMUI (International Mobile User Identity) umbenannt.

Die Nummerierung der einzelnen Kapitel in der TS 11.14 wurde in TS 131 111 stark abgeändert. Durch diese

Verschiebung der Kapitel ist eine effiziente Suche (automatisiert durch Scripte) nach Veränderungen kaum reali-

sierbar. Daher fand der Vergleich manuell, Kapitel für Kapitel (nicht jedoch Wort für Wort) statt. Kleine Verän-

derungen, jedoch im Wesentlichen ohne den Sinn zu verändern, kristallisierten sich heraus. Kapitel 6.8 der SAT

Spezifikation wurde in der USAT Spezifikation in 21 winzige Unterkapitel aufgeteilt. Tatsächlich konnte auf

diese Weise eine deutlich verbesserte Übersichtlichkeit erreicht werden.

Das einfache TLV-Objekt „Network Access Name“, das in der SAT-Spezifikation [16] in Kapitel 12.61 be-

schrieben wird gibt es in der USA-Spezifikation [19] nicht mehr. Dessen Stelle nimmt ein neues einfaches TLV-

Objekt dass den Application Identifier „AID“ trägt und die gleiche Struktur hat, wie das TLV-Objekt „Network

Access Name“.

78

Kapitel 5.1: Das Trägersystem ________________________________________________________________ WIM:

Das WIM wurde vom WAP Forum unter der Nummer WAP-260-WIM-200110712-a [20] spezifiziert.

Aufgrund der Tatsache, dass WIM außerhalb des WAP-Protokollstapels angesiedelt d.h. als eigenständige

Smartcard-Anwendung implementiert wurde und lediglich über zwei Schnittstellen zur Anwendungsschicht

(WAE: Wireless Application Environment) und Sicherungsschicht (WTLS: Wireless Transport Layer Security)

des WAP Protokollstapels verfügt (über SAPs), kann es auch unabhängig von WAP anderen Diensten zur Ver-

fügung gestellt werden (z.B. E-Commerce und M-Commerce Anwendungen).

Zum spezifizierten Leistungsumfang des WIM zählen folgende Features:

• Speichern von geheimen Schlüsseln und Zertifikaten in einem besonders abgesicherten Bereich

• Generieren von langen Zufallszahlen mit Hilfe des integrierten mathematischen Coprozessors

• Verifizieren und Generieren von digitalen Signaturen und Echtzeitentschlüsseln von chiffrierten Texten

• Speichern von URLs (Uniform Ressource Locator) von Client Zertifikaten

• Durchführen von Verschlüsselungen in Echtzeit

Beim WIM handelt es sich um ein optional zu implementierendes Modul, das primär darauf ausgelegt ist, erwei-

terten Sicherheitsanforderungen zu genügen und somit Anwendungen wie M-Commerce und E-Commerce auf

höchstem Sicherheitsniveau zu ermöglichen. Des Weiteren ist auch die Umsetzung der Qualifizierten Digitalen

Signatur nach dem Signaturgesetz (SigG) eine mögliche Anwendung für dieses Modul, da es den speziell in die-

sem Gesetz definierten, hohen Ansprüchen an Hardware und Software genügt.

Digitale Signaturen ermöglichen eine zweifelsfreie Belegung der Identität des Unterzeichners. Dabei werden in

umgekehrter Reihenfolge als dies z.B. vom RSA-Verfahren her bekannt ist asymmetrische Verschlüsselungsver-

fahren eingesetzt. Der Unterzeichner verwendet seinen privaten Schlüssel zur Verschlüsselung eines Hash-

Wertes über eine Klartextnachricht, die von jedem anhand des öffentlichen Schlüssels decodiert werden kann.

Da nur der Unterzeichner über den privaten Schlüssel verfügt und dieser aufgrund seiner Länge beim aktuellen

Stand der Technik nicht in endlicher Zeit ermittelt werden kann, gilt seine Identität als sichergestellt. Die Her-

kunft des öffentlichen Schlüssels bei diesem Verfahren stellt die eigentliche Schwachstelle dar und es wäre

durchaus möglich, dass ein gefälschter öffentlicher Schlüssel verbreitet wird und somit auch ein falscher Privater

Schlüssel genutzt werden könnte, die Identität eines anderen vorzutäuschen. Um dies und „Man in the Middle“

Angriffe wirkungsvoll vermeiden zu können, ist der Einsatz eines Trustcenters (Zertifizierungsstelle) unver-

zichtbar. Ein Trustcenter wäre dann für eine sichere Vergabe von Signaturen und die Verteilung von öffentlichen

Schlüsseln verantwortlich. Die Einrichtung einer solchen Zertifizierungsstelle unterliegt nach dem SigG einer

Reihe von Bestimmungen und ist kostenaufwendig. Eine Implementierung der digitalen Signatur auf der UICC

nach dem SigG ist in nächster Zukunft unwahrscheinlich.

79

Kapitel 5.2: Sicherheitsrelevante Prozesse des USIM ________________________________________________________________ 5.2 Sicherheitsrelevante Prozesse des USIM Diesem Kapitel liegt im Wesentlichen die Spezifikation „ETSI TS 133 102 : 3G Security; Security Architecture“

[24] zugrunde, einzelne Informationen entstammen zusätzlich der USIM Spezifikation [18].

Sicherheitsaspekte*1

• Authentisierung des USIMs gegenüber dem (GSM) Netz

• Authentisierung des Netzes gegenüber USIM

• Authentisierung des Benutzers gegenüber USIM

• Datensicherheit auf der Luftschnittstelle

• Differenzierte Dateizugriffsbedingungen (siehe Kapitel 5.1)

• Anonymität des Benutzers beim Einbuchen und bei bestehenden Verbindungen

Die Kommunikation im Festnetz zwischen VLR/SGSN und HLR/AC wird als sicher vorausgesetzt. Die Umset-

zung dieser sicheren Kommunikation ist den Netzbetreibern überlassen.

Anstelle der beim GSM zur Benutzeridentifikation und Datenverschlüsselung verwendeten 3 Algorithmen A3

(Erzeugung einer unterschriebenen Rückantwort), A8 (Schlüsselerzeugung) und A5 (zur Verschlüsselung auf der

Luftschnittstelle) werden bei UMTS 6 Algorithmen, f1-f5 und f8 wie in der folgenden Tabelle 13 eingesetzt.

SIM USIM Bestimmung f1 Extrahiert die XMAC aus Teil von RAND u.V.v.K

A3 f2 Erzeugt signierte Antwort RES aus Teil von RAND u.V.v. K A8 f3 Erzeugt Schlüssel Kc bzw. CK aus Teil von RAND u.V.v. K

f4 Erzeugt Integrity Key IK aus Teil von RAND u.V.v. K f5 Extrahiert aus RAND den Anonymity Key AK u.V.v. K

A5 f8 Verschlüsselt Daten auf der Luftschnittstelle mit Kc bzw. CK

Tabelle 13: Bei UMTS eingesetzte kryptographische Algorithmen; u.V.v. K = unter Verwendung von K

Jeder Algorithmus f1 bis f5 verwendet einen geheimen und festen Initialisierungsvektor K, der ausschließlich

dem jeweiligen USIM und dem Authorisation Center bekannt ist (vgl. [24], 6.3.1). Der Algorithmus f8 verwen-

det den Schlüssel CK zur Verschlüsselung auf der Luftschnittstelle. Die Signed Response SRES aus der GSM-

Authentisierung wird bei der UMTS-Authentisierung mit Response (RES) bezeichnet. Bei Challenge-Response

Verfahren wird der separat erzeugte Kontrollwert (XRES) jeweils mit einem X vor der erwarteten Antwort

(RES) notiert.

Im Gegensatz zu der bei GSM abgewickelten Prozedur übernimmt bei UMTS das VLR/SGSN die Übergabe der

Zufallszahl an das ME und die Überprüfung der unterschriebenen Rückantwort. Dies hat den Grund, dass eine

Einbuchung in das Netz möglichst unabhängig von der momentanen Verfügbarkeit eines HLR/AC sein sollte,

während VLR/SGSN für jeden Aufbau einer Kommunikationsbeziehung im GSM/UMTS Umfeld essentiell ist.

Zu diesem Zweck erhält das VLR/SGSN auf Anfrage vom HLR/AC einen Satz von Authentisierungs-Vektoren

(AV). In jeden AV fließt bei der Erzeugung (bei der Wahl von K, ggf. K = IMSI) die IMSI ein, die im Rahmen

der Anfrage des VLR/SGSN mit übergeben wird.

Authentication Data request, IMSI VLR/ SGSN

HLR/ AC

Abbildung 45: Übergabe der AV (vgl. [24], Kapitel 6.3.2 Abb.6) Authentication data response, AV(1..n)

*1 Diese Anforderungsliste wurde aus den beschriebenen Sicherheitsmechanismen in [24] abgeleitet.

80

Kapitel 5.2: Sicherheitsrelevante Prozesse des USIM ________________________________________________________________

Als Antwort erhält das VLR/SGSN einen Satz Zufallszahlen (RAND) und zusätzlich die erwarteten, unter-

schriebenen Rückantworten (XRES, der vom AC berechnete Wert von RES) sowie die jeweiligen für die Zu-

fallszahlen gültigen Verschlüsselungscodes (CK, bei GSM KC genannt), Integritätscodes (IK), Anonymity Co-

des (AK) und Authentisierungs-Token (AUTN). (vgl. [24], Kapitel 6.3.2, Abbildung 7).

Ein Authentisierungsvektor, wie er vom HLR/AC an das VLR/SGSN übergeben wird hat folgende Gestalt:

AV := RAND || XRES || CK || IK || AUTN

Der Authentisierungs-Token (AUTN) dient dem ME zur Verifikation der Herkunft der RAND. In diesem Token

stecken eine Sequenznummer SQN, der Schlüssel AK, der Message Authentification Code MAC sowie ein Au-

thentication Management Field AMF (vgl. [24], Kapitel 6.3.2, Abbildung 9).

AUTN := SQN AK || AMF || MAC ⊕

Die Sequenznummer wird vom ME gespeichert und AUTN wird nur dann akzeptiert, wenn sie größer ist, als die

zuletzt abgespeicherte Sequenznummer. Sie darf jedoch nicht beliebig größer sein: Die Differenz zwischen der

zuletzt im ME abgespeicherten Sequenznummer und der Folgenden darf einen Wert nicht überschreiten,

sonst wird die AUTN nicht akzeptiert. Der Wert ist nicht vorgegeben. Bei Ablehnung muss ein Grund ange-

geben werden (vgl. [24], Kapitel 6.3.3). Jeder Authentisierungsvektor AV darf genau einmal verwendet werden.

Bislang unbenutzte Authentisierungsvektoren werden bei einem Inter-MSC-Handover mit an das neue

VLR/SGSN übergeben (vgl. [24], Kapitel 6.3.4). Der Schlüssel IK wird für Handover-Prozesse verwendet.

∆

∆

Authenti-sierung, Schlüs-sel-Erzeu-gung und Schlüs-sel-Eta-blierung

Erzeugt CK(i) und IK(i) zur Verschlüsselung und HO

Wählt CK(i) und IK(i) zur weiteren Chiffrierung und HO

Vergleicht RES(i) mit XRES(i) aus AV(i)

User authentication response RES(i)

Verifiziert AUTN(i) Berechnet RES(i)

User authorisation request RAND(i) || AUTN(i)

Wählt einen Authentisierungs-Vektor AVi aus

Anforderung, Erzeugung, Über-gabe und Speicherung von Au-thentisierungs-Vektoren (AV) Speichert

AV(1..n)

Authentication data response, AV(1..n)

Erzeugt AV (1..n)

Authentication data request, IMSI

HLR/ACVLR/SGSNMS

Abbildung 46: Benutzer-Authentisierung und Schlüsselerzeugung (vgl. [24], Kapitel 6.3.1, Abb.5)

81

Kapitel 5.2: Sicherheitsrelevante Prozesse des USIM ________________________________________________________________

82

⊕

∆

rs-

nein

Undefiniert, evtl. erneute Aufforde-rung zur Authentisierung

ja

Wählt CK für Vechlüsselung und IK für HO

RES = XRES

User authentication response RES ja

nein User authentication reject CAUSE SQNHE < SQNMS oder SQNHE > SQNMS + oder XMAC != MAC

SQS kann akzeptiert werden

USIM User authorisation request RAND | AUTN VLR/SGSN

RAND

XMAC RES CK IK

f 2 f 3 f 4

Überprüft MAC = XMAC

f 1

Überprüft die Aktualität von SQN

AUTN

MAC AMF SQN + AK

+

K

AK

f 5

SQN

Legende: SQNHE = SQN Home Environment SQNMS = SQN Mobile Station Home Environment = HLR/AC AV = RAND || XRES || CK || IK || AUTN AUTN = SQN AK || AMF || MAC

Authentication data request, IMSI

AK

Erzeugt SQN

Erzeugt RAND

RAND

XRES CK IK

f 2 f 3 f 4 f 1

MAC

AMF K

f 5

SQN HE

Authentication data response, AV(1..n)

HLR/AC

Abbildung 47: Authentisierung bei UMTS (vgl. [24] Kapitel 6.3.1, 6.3.2, 6.3.3). Um diese Übersicht zu er-zeugen wurden mehrere Grafiken aus der Spezifikation verwendet, zusammengeführt und um Daten ergänzt.

Kapitel 5.2: Sicherheitsrelevante Prozesse des USIM ________________________________________________________________

Authentisierung des Netzes gegenüber USIM (vgl. Abbildung 47, 49):

Aus der Zufallszahl RAND ermittelt das ME anhand der Funktion f5 und dem Initialisierungsvektor K den

Schlüssel AK, mit dem es dann aus SQN AK (im ersten Teil von AUTN enthalten) durch erneutes Addieren

von AK die Sequenznummer SQN extrahiert und gemäß den oben beschriebenen Bedingungen auf Aktualität

überprüft. Mit dem Algorithmus f1 und dem Initialisierungsvektor K berechnet das ME aus der SQN, dem AMF

(beide in AUTN enthalten) und der Zufallszahl RAND den Wert XMAC, der dem Wert MAC aus dem AUTN

entsprechen muss (vgl. [24], Kapitel 6.3.3). Ist dies nicht der Fall oder SQN war nicht gültig, wird die Authenti-

sierungsprozedur nach vorangegangener Übermittlung des Grundes ans VLR/SGSN abgebrochen.

⊕

∆

siehe Abb. 50

K

Weiteres Vorgehen nicht spezifiziert

VLR/SGSN

Verschlüsselung der weiteren Kommunikation mit CK

Übermittelt RAND und AUTN (aus einem AV entnommen)

Berechnet RES und AK (s.u.)

Bedingungen erfüllt?

Fehlermeldung an VLR/SGSN unter Angabe des Grundes nein

ja

Authentisierung USIM gegenüber Netz

Ermittelt aus RAND den Authentisierungs-Schlüssel AK, extrahiert damit aus dem ersten Teil von AUTN die Sequenznummer SQN und überprüft sie auf Aktualität. Aus SQN, AMF und RAND (s. Abb. 47) wird XMAC berechnet, das dem in AUTN enthaltenen Wert für MAC entsprechen muss. Sind die Bedingungen erfüllt, berechnet das USIM im Folgenden RES und CK (s. Abb. 50). In alle Berechnungen fließt der ge-heime aber feste Schlüssel K ein.

USIM

2.

1. SQNHE < SQNMS oder

SQNHE > SQNMS + SQN

XMAC = MAC?

f1

XMAC

+ AK f5

RAND AUTN = (SQN+AK AMF MAC)

Abbildung 48: Authentisierung des Netzes gegenüber USIM

Authentisierung des USIM gegenüber dem Netz (vgl. Abbildung 47, 49):

Zufallszahl RAND und Authentisierungs-Token AUTN werden vom VLR/SGSN an das USIM übermittelt.

Erst erfolgt die Verifizierung des Netzes, bei der das USIM die Sequenznummer und den Wert XMAC berechnet

und überprüft (s.u.). Ist dies erfolgreich verlaufen berechnet das USIM mit dem Algorithmus f3 und dem Initiali-

83

Kapitel 5.2: Sicherheitsrelevante Prozesse des USIM ________________________________________________________________ sierungsvektor K den Schlüssel CK und mit f2 und K als Initialisierungsvektor die unterschriebene Rückantwort

RES. RES wird an das VLR/SGSN zurückgeschickt und dort mit dem Wert XRES verglichen, den das VLR/

SGSN aus dem entsprechenden AV entnimmt. Sind die beiden Ergebnisse identisch, so wird der Einbuchungs-

vorgang abgeschlossen und der Schlüssel CK zur Sprachverschlüsselung mit Algorithmus f8 verwendet. Erhält

das USIM vom Netz anstelle von AUTN und RAND nur RAND, so weiß es, dass es sich bei dem aktuellen Netz

um ein Phase-2-Netz handelt. In diesem Fall berechnet das USIM lediglich RES und CK, schickt RES zurück an

das VLR/SGSN und verwendet CK zur Verschlüsselung auf der Luftschnittstelle. In der folgenden Abbildung 50

wird der Ablauf der USIM-Authentisierung durch das Challenge-Response Verfahren anhand eines Flussdia-

gramms veranschaulicht. Die gestrichelte Linie bezieht sich auf die in Abbildung 48 (s.o.) dargestellte Netzveri-

fizierung.

Verifizierung des Netzes (s.o.) anhand von AUTN

CK wird für die weitere Kommunikation zur Verschlüsselung verwendet

Überprüft CK durch direkten Vergleich mit dem für den versendeten Authentisie-rungs-Token vorgesehenen, gesp. Muster

RES (Response) wird übermittelt Berechnet aus RAND CK und RES, speichert CK

RAND (Challenge) und AUTN werden übermittelt USIM VLR/SGSN

Abbildung 50: Authentisierung des USIM gegenüber dem Netz durch Challenge-Response Verfahren

Authentisierung des Benutzers gegenüber USIM:

Der Benutzer authentisiert sich gegenüber dem USIM anhand einer PIN, die mindestens aus 4 Zeichen und

höchstens aus 8 Zeichen bestehen darf. Ist die PIN kürzer als 8 Zeichen, so muss das Endgerät die restlichen Zei-

chen durch die Einträge ’FF’ ergänzen, bevor es die PIN an das USIM übergibt. Die Unblock PIN, mit der eine

ggf. gesperrte PIN nach dreimaliger Fehleingabe wieder frei geschaltet werden kann, muss genau achtstellig sein

(vgl. [18], Kapitel 6.4). Die Authentisierung des Benutzers gegenüber dem USIM kann durch die Funktion

DISABLE PIN abgeschaltet werden. Der Einsatz einer universellen PIN kann die Authentisierung des Benutzers

beim USIM ebenfalls ersetzen.

Datensicherheit auf der Luftschnittstelle:

Die Daten auf der Luftschnittstelle werden mit dem Schlüssel CK verschlüsselt. Der Schlüssel CK hat eine Län-

ge von 128 Bit (bei 2G GSM war der Schlüssel KC nur 64 Bit lang). Derselbe Schlüssel darf nur innerhalb eines

kurzen Zeitraumes (nicht näher spezifiziert) gültig sein. Der Benutzer wird nach seiner Ersteinbuchung anhand

seiner temporären Identifikationsnummer (TMSI*1) identifiziert. Die TMSI wird mit dem Schlüssel CK und spä-

*1 In der Spezifikation [24] werden sowohl die Bezeichnungen TMUI und TMSI verwendet, wobei U = User und S = Subscriber entsprechen. Tatsächlich ist es dieselbe Nummer und TMUI ist die Bezeichnung der TMSI im UMTS Umfeld. Der Bekanntheit halber wird hier ausschließlich die Bezeichnung TMSI verwendet.

84

Kapitel 5.2: Sicherheitsrelevante Prozesse des USIM ________________________________________________________________ testens beim nächsten Location Update gewechselt. Die Aktualisierung von TMSI/LAI findet nach der Aktivie-

rung der Verschlüsselung über die Luftschnittstelle statt (vgl. [24], Kapitel 6.1.2). Bei der Ersteinbuchung und

wenn der Benutzer anhand seiner TMSI nicht identifiziert werden kann, fordert das Netz (VLR oder SGSN) die

Übergabe der IMSI an. Diese Übergabe erfolgt im Klartext, was einen bekannten (vgl. [24], Kapitel 6.2, letzter

Satz) Bruch der definierten Sicherheitsparameter bzgl. des Vertraulichkeit von Benutzerdaten darstellt.

Dateizugriffsbedingungen (siehe Kapitel 3.3):

Es werden zwei unterschiedliche Typen von PINs verwendet, PIN 1 und PIN 2. Während PIN 2 zur Authentifi-

zierung des Benutzers gegenüber jedem einzelnen ADF/DF separat definiert werden kann, gilt PIN 1 für alle

ADFs/DFs gemeinsam (vgl. [17], Kapitel 9.1). Die PINs werden jedenfalls nach der Eingabe in eine zweckge-

bundene Schlüsselreferenznummer umgewandelt, anhand derer die entsprechende Anwendung freigeschaltet

wird. Die universelle PIN (wenn sie aktiviert wurde) ersetzt die Eingabe von PIN 1 und PIN 2 (vgl. [18], Kapitel

6.4) und muss in jedem G3 Endgerät unterstützt werden.

Anonymität des Benutzers beim Einbuchen und bei bestehenden Verbindungen:

Aufgrund der Verwendung der häufig wechselnden TMSI anstelle der festen IMSI sowohl beim Einbuchen (die

zuletzt verwendete TMSI wird verwendet) als auch bei bestehender Verbindung weitestgehend gewährleistet.

Einen Bruch der Anonymität des Benutzers stellt der oben im Abschnitt Datensicherheit auf der Luftschnittstelle

beschriebene Umstand dar.

85

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________ Kapitel 6 Vergleichende Analyse und Fazit

Implementierung der Protokollebenen:

Während für das SIM die allgemein für Chipkarten spezifizierte 3-Layer-Architektur übernommen wurde, wurde

für UICC und 3G-Terminal gemäß [17] ein 5-Layer Modell implementiert. In Abbildung 51 werden die Proto-

kollebenen von ISO-OSI, SIM und UICC gegenüber gestellt.

2. Data Link Layer

3. Transport Layer

5,5. USAT Layer

7. Application Layer

2. Data Link Layer

7. Application Layer

2. Data Link Layer

3. Network Layer

4. Transport Layer

5. Session Layer

6. Presentation Layer

7. Application Layer

SIM: 3 Layer Modell

1. Physical Layer

UICC, 5 Layer Modell 1. Physical Layer

OSI: 7 Layer Modell

1. Physical Layer

Abbildung 51: Die Protokollebenen von SIM und UICC im Vergleich zum OSI Schichtenmodell

Bei SIM und UICC-Karte findet auf Schicht 1 die Bitübertragung statt. Zu dieser Ebene zählen die rein physika-

lischen Charakteristika von Karte und Terminal und die Übertragung von unstrukturierten Bits (oder Blöcke im

Falle von T=1). ATR und PTS werden ebenfalls auf Layer 1 durchgeführt.

Auf Layer 2 wird der Bitstrom (im Falle von T=1 Blöcke) auf Empfängerseite zu verwertbaren Datenpaketen

zusammengesetzt und eine Fehlererkennung mit Hilfe von Paritätsbits durchgeführt. Es gibt keine Fehlerkorrek-

tur, fehlerhafte Pakete werden verworfen und je nach Protokoll erneut gesendet (T=0, T=1) oder, falls das nicht

zu einer fehlerfreien Übertragung führt (bei T=1), neu synchronisiert. Im äußersten Notfall (T=1) wird ein Reset

durchgeführt. Diese Methoden sind in der ISO-Spezifikation ISO/IEC 7861-3[12] genau beschrieben. TPDUs

werden an die Bitübertragungsschicht und an die höhere Schicht über den jeweiligen SAP weitergeleitet.

Die OSI-Schicht 3 spielt für Chipkarten keine Rolle, da für die Übertragung der Daten zwischen Terminal und

Chipkarte nur der direkte Weg vorgesehen ist. Layer 3 entspricht beim SIM der Anwendungsschicht Layer 7.

Die Bildung und Interpretation von Command- und Response-APDUs, die Ausführung der enthaltenen Anwei-

sungen von SIM und SAT und die Übergabe von Ausführungsbestätigungen bzw. Fehlermeldungen sind die

Aufgaben dieser Schicht, ebenso wie die Verschlüsselung und Dechiffrierung und die Erzeugung von Schlüsseln

bzw. signierten Rückantworten. Beim SIM wird auf dieser Ebene auch das SIM Application Toolkit eingesetzt.

Im Gegensatz dazu entspricht die dritte Schicht der UICC-Karte der Transportschicht (Layer 4) und ist somit

verantwortlich für das Mapping von Command- und Response-APDUs in Command- bzw. Response-TPDUs.

Zusätzlich werden auf dem Transport Layer auch die Anweisung GET RESPONSE und die Statusworte der

Response-APDU übertragen (vgl. [17], Kapitel 7.3) und interpretiert.

Die Schicht 4 von UICC und Terminal (USAT Layer) wird in der Spezifikation [17, Kapitel 7.4.2] nur sehr ru-

dimentär beschrieben: Die USAT Statusworte ’91 XX’, ’62 XX’, ’63 XX’ und ’93 00’, die ENVELOPE Anwei-

sung und die Proactive Commands zählen zu ihren Aufgaben. Eine eindeutige Zuordnung zu einer bestimmten

Schicht des ISO-OSI Modells ist nicht möglich. Die Kontrollfunktionen des Event Handling, die u.a. Verbin-

dungen registrieren und überwachen entsprechen Aufgaben des Session Layer, die ENVELOPE Funktionen

86

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________ müssten aber eher dem Presentation Layer (Layer 6) zugeordnet werden. Auf der Schicht 5 des UICC-

Protokollstapels, der Anwendungsschicht (Layer 7) werden die Command-APDUs und Response-APDUs inter-

pretiert und ausgeführt.*1

Vergleich der Dateitypen und Zugriffsmethoden bei SIM und UICC:

Da dieses Thema bereits erschöpfend in den Kapiteln 3 und 5 diskutiert wurde, wird es an dieser Stelle nur noch

einmal in Form der Tabelle 14 zusammengefasst.

Feature SIM

UICC

Dateitypen: Elementary Files: x x Dedicated Files x x Application Dedicated Files x Master File x x

Typen von Elementary Files: Transparent Elementary Files x x Cyclic Elementary Files x x Linear Fixed Elementary Files x x

Zugriffsmethoden auf Dateien und Verzeichnisse: SELECT by File Identifier Referencing x x SELECT by Path Referencing x SELECT by Short File Identifier x SELECT by Dedicated File Name x SELECT by Partial Dedicated File Name x

Sicherheitsaspekte der Chipkarte: Sicherung der Chipkarte durch eine Geheimnummer (PIN, Passwort) CHV1 PIN1 Sicherung durch ein zusätzliches Passwort mit anderem Rechte-Status CHV2 PIN2 Möglichkeiten zur Sicherung einzelner Anwendungen durch Vergabe von Passworten

Univ. PIN Appl. PIN Local PIN

Unterschiedliche Zugriffsbedingungen für alle Befehle je Datei ALWays, CHV1 CHV2, ADM, NEVer

ALWays, PIN1 PIN2, ADM NEVer

Anzahl der Fehlversuche bei der Eingabe eines Passworts (PIN, CHV) 3 3 Rücksetzung des Fehlversuche-Zählers bei Eingabe der korrekten PIN x x Rücksetzung des Fehlversuche-Zählers der PUK bei korrekter Einga-be der UNBLOCK PIN

Maximale Anzahl von Unblock Fehlversuchen bis zur Sperrung 10 10

Tabelle 14: Vergleich von Dateitypen, Zugriffsmethoden und Sicherheitsaspekten zwischen SIM und UICC

Gegenüberstellung der auf SIM und UICC enthaltenen Dateien:

In der folgenden Tabelle 15 wurden die im SIM implementierten Dateien daraufhin untersucht, ob und wie sie in

UICC bzw. USIM übernommen wurden und ob sie denselben Verpflichtungsgrad (M/O) beibehalten haben,

wenn sie auch in der UICC implementiert wurden. Ferner wurde auch untersucht, ob sie ihre Struktur und Größe

beibehalten haben und inwieweit die Identifikationsnummern übernommen wurden. Die Tabelle wurde mit den

Daten aus der SIM [15] und der UICC [17] bzw. USIM [18] Spezifikation erstellt.

*1 Es ist nicht ganz nachvollziehbar zu welchem Zweck der USAT-Layer als eigenständige Protokollschicht de-finiert wurde, zumal bei Betrachtung des logischen Aufbaus der Spezifikation schnell auffällt, dass das Kapitel USAT Layer (7.4.2) als Unterkapitel des fast inhaltslosen Application Layer Kapitels (7.4) eingefügt wurde. Es scheint, als wollte man sich hier - etwas künstlich - mehr an das OSI Modell anpassen, als dies bei der Implementierung von SIM geschehen ist.

87

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________

88

’6F 3E’

M

3G Pb

’6F 4A’

SIM M/O UICC M/O Changes MF ‘3F 00’ M MF ‘3F 00’ M EFICCID ’2F E2’ transparent, 10 bytes M EFICCID ’2F E2’ transparent, 10 bytes M EFELP ’2F 05’ transparent, 2n bytes O EFPL ’2F 05’ transparent, 2n bytes M name EFDIR ’2F 00’ linear fixed, x bytes M new EFARR ’2F 06’ linear fixed, x bytes O new ADFUSIM ’7F FF’ new DFPhonebook ’5F 3A’ div. subfiles, s. table 9

transparent, 9 bytes O ID (DFGSM) EFLOCIGPRS ’6F 53’ transparent, 14 bytes O EFSUME ’6F 54’ transparent, x+y bytes O EFSUME ’6F 54’ transparent, x+y bytes O (DFTELECOM) EFPLMNwAcT ’6F 60’ transparent, 5n, (n>7) bytes O EFOLMNwAcT ’6F 61’ transparent, 4n, (n>7) O EFHPLMNwAcT ’6F 62’ transparent, 5n bytes O EFCPBCCH ’6F 63’ transparent, 2n bytes O EFCPBCCH ’6F 63’ transparent, 2n bytes O ID (DFGSM) EFInvScan ’6F 64’ transparent, 1 byte O EFInvScan ’4F 76’ transparent, 1 byte O ID +(DFGSM) EFRPLMNAcT ’6F 5F’ transparent, 2*x bytes O DFSoLSA ’5F 70’ DFSoLSA ’5F 70’ n.v. R99 EFSAI ’4F 30’ transparent, x+1 bytes O EFSAI ’4F 30’ transparent, x+1 bytes n.v. R99 EFSLL ’4F 31’ lin. fixed, x+10 bytes O EFSLL ’4F 31’ lin. fixed, x+10 bytes n.v. R99 DFMExE ’5F 3C’ DFMExE ’5F 3C’ N EFMExE-ST ’4F 40’ transparent, x byte, x>0

O

new

EFMExE-ST

DFGSM

transparent, x byte, x>0

’7F 20’

N

DFGSM

EFORPK

’5F 3B’

’4F 41’

lin. Fixed, x+10 bytes

O

ID

EFORPK

EFLP

lin. Fixed, x+10 bytes

’6F 05’

transparent, 2n bytes

N

M EFLI

EFARPK

’6F 05’

’4F 42’

transparent, 2n bytes

lin. fixed, x+10 bytes

O

O

name + 1Lv.

EFARPK

EFIMSI

lin. fixed, x+10 bytes

’6F 07’

transparent, 9 bytes

N

M EFIMSI

EFTPRPK

’6F 07’

’4F 43’

transparent, 9 bytes

lin. Fixed, x+10 bytes

M

O

->ADFUSIM

EFTPRPK

EFKc

lin. Fixed, x+10 bytes

’6F 20’

transparent, 9 bytes

N

M EFKc

DFTELECOM

’4F 20’

’7F 10’

transparent, 9 bytes

O

ID (DFGSM)

DFTELECOM

EFMSISDN

EFADN

’6F 40’

’6F 3A’

lin. fixed, x+14 bytes

O

D New (tele)

EFADN

EFPLMNsel

lin. fixed, x+14 bytes

’6F 30’

3G Pb

transparent, 3n (n>7)

N

O EFUPLMNsel

EFFDN

’6F 30’

’6F 3B’

transparent, 5n (n>7)

lin. fixed, x+14 bytes

O

O

name + 1Lv.

EFFDN

EFHPLMN

lin. fixed, x+14 bytes

’6F 31’

3G Pb

transparent, 1 byte

N

M EFHPLMN

EFSMS

’6F 31’

’6F 3C’

transparent, 1 byte

lin. fixed, 176 bytes

M

O

-> ADFUSIM

EFSMS

EFACMmax

lin. fixed, 176 bytes

’6F 37’

3G Pb

transparent, 3 bytes

N

O EFACMmax

EFCCP

’6F 37’

’6F 3D’

transparent, 3 bytes

lin. fixed, 14 bytes

O

O

-> ADFUSIM

EFCCP

EFSST

lin. fixed, 14 bytes

’6F 38’

3G Pb

transparent, min. 2 byte

N

M EFUST

EFECCP

’6F 38’

’6F 4F’

transparent, min. 2 byte

lin. fixed, 14 bytes

M

O

name + 1Lv.

EFACM

’6F 39’

cyclic, 3 bytes

O EFACM

EFMSISDN

’6F 39’

’6F 40’

cyclic, 3 bytes

lin. fixed, x+14 bytes

O

O

-> ADFUSIM

EFMSISDN

EFGID1

lin. fixed, x+14 bytes

transparent, 1-n bytes

n

O EFGIDI

EFSMSP

’6F 3E’

’6F 42’

transparent, 1-n bytes

lin. fixed, 28+y bytes

O

O

-> ADFUSIM

EFSMSP

EFGIDI2

lin. fixed, 28+y bytes

’6F 3F’

3G Pb

transparent, 1-n bytes

n

O EFGIDI2

EFSMSS

’6F 3F’

’6F 43’

transparent, 1-n bytes

transparent, 2+x bytes

O

O

-> ADFUSIM

EFSMSS

EFSPN

transparent, 2+x bytes

’6F 46’

3G Pb

transparent, 17 bytes

n

O EFSPN

EFLND

‘6F 46’

’6F 44’

transparent, 17 bytes

cyclic, x+14 bytes

O

O

-> ADFUSIM

EFLND

EFPUCT

cyclic, x+14 bytes

’6F 41’

3G Pb

transparent, 5 bytes

n

O EFPUCT

EFSDN

’6F 41’

’6F 49’

transparent, 5 bytes

lin. fixed, x+14 bytes

O

O

-> ADFUSIM

EFSDN

EFCBMI

lin. fixed, x+14 bytes

’6F 45’

3G Pb

transparent, 2n bytes

n

O EFCBMI

EFEXT1

’6F 45’

’6F 4A’

transparent, 2n bytes

lin. fixed, 13 bytes

O

O

-> ADFUSIM

EFEXT1

EFBCCH

lin. fixed, 13 bytes

’6F 74’

3G Pb

transparent, 16 bytes

n

M EFBCCH

EFEXT2

’4F 74’

’6F 4B’

transparent, 16 bytes

lin. fixed, 13 bytes

O

O

ID (DFGSM)

EFEXT2

EFACC

lin. fixed, 13 bytes

’6F 78’

3G Pb

transparent, 2 bytes

n

M EFACC

EFEXT3

’6F 78’

’6F 4C’

transparent, 2 bytes

lin. fixed, 13 bytes

M

O

-> ADFUSIM

EFEXT3

EFFPLMN

lin. fixed, 13 bytes

’6F 7B’

3G Pb

transparent, 12 bytes

n

EFFPLMN

EFBDN

’6F 7B’

’6F 4D’

transparent, n*3, n>3

lin. fixed, x+15 bytes

M

O

-> ADFUSIM

EFBDN

EFLOCI

lin. fixed, x+15 bytes

’6F 7E’

3G Pb

transparent, 11 byte

n

M EFLOCI

EFEXT4

’6F 7E’

’6F 4E’

transparent, 11 byte

lin. fixed, 13 bytes

M

O

-> ADFUSIM

EFEXT4

EFAD

lin. fixed, 13 bytes

’6F AD’

3G Pb

transparent, 3+x bytes

n

M EFAD

EFSMSR

’6F AD’

’6F 47’

transparent, 4+x bytes

lin. fixed, 30 bytes

M

O

-> ADFUSIM

EFSMSR

EFPhase

lin. fixed, 30 bytes

’6F AE’

3G Pb

transparent, 1 byte

n

M

EFCMI

’6F 58’

lin. fixed, x+1 bytes

O

EFCMI

EFVGCS

lin. fixed, x+1 bytes

’6F B1’

3G Pb

transparent, 4n<51

->ADFUSIM

O

EFARR

EFVGCSS

linear fixed, x bytes

’6FB2’

M

transparent, 7 bytes

New

O

DFPhonebook

EFVBS

div. subfiles, s. table 9

’6F B3’

transparent, 4n<51

New

O

DFGraphics

’5F 50’

DFGraphics

EFVBSS

’6F B4’

transparent, 7 bytes

n

O

EFIMG

’4F 20’

lin. fixed, 9n+2 bytes

O

EFIMG

EFeMLPP

lin. fixed, 9n+2 bytes

’6F B5’

O

transparent, 2 bytes

n

O EFeMLPP ’6F B5’

Tabelle 15: Vergleichende Dateianalyse

transparent, 2 bytes O -> ADFUSIM EFAAeM ’6F B6’ transparent, 1 byte O EFAAeM ’6F B6’ transparent, 1 byte O -> ADFUSIM EFCBMID ’6F 48’ transparent, 2n bytes O EFCBMID ’6F 48’ transparent, 2n bytes O -> ADFUSIM EFECC ’6F B7’ transparent, 3n, (n<6) O EFECC ’6F B7’ linear fixed, x+6 bytes M -> ADFUSIM EFCBMIR ’6F 50’ transparent, 4n bytes O EFCBMIR ’6F 50’ transparent, 4n bytes O -> ADFUSIM EFFDN ’6F 3B’ linear fixed, x+14 bytes O D new (tele) EFSMS ‘6F 3C’ linear fixed, 176 bytes O D new (tele) EFSDN ’6F 49’ linear fixed, x+14 bytes O D new (tele) Diverse weitere Duplikate (zu DFTELECOM) vorhanden, siehe TS 31.102 EFDCK ’6F 2C’ transparent, 16 byte O EFDCK ’6F 2C’ transparent, 16 byte O -> ADFUSIM EFCNL ’6F 32’ transparent, 6n bytes O EFCNL ’6F 32’ transparent, 6n bytes O -> ADFUSIM EFNIA ’6F 51’ linear fixed, x+1 bytes O EFKcGPRS ’6F 52’ transparent, 9 bytes O EFKcGPRS ’4F 52’

’4F 40’ ’4F 41’ ’4F 42’ ’4F 43’ ’7F 10’ ’6F 3A’ ’6F 3B’ ’6F 3C’ ’6F 3D’

’6F 40’ ’6F 42’ ’6F 43’ ’6F 44’ ’6F 49’

’6F 4B’ ’6F 4C’ ’6F 4D’ ’6F 4E’ ’6F 47’ ’6F 58’ ’6F 06’

’5F 50’ ‘4F 20’

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________

Legende zur Tabelle 15:

M: mandatory O : optional

n: keine Änderungen -> XX: verschoben nach XX

new: neu eingeführt, in SIM nicht vorgesehen

D new (tele): Duplikat, an dieser Stelle neu, noch einmal im DFTELECOM enthalten

n.v. R99: nicht vorgesehen in Release 99, wohl aber in Release 2000

ID: Die Identifikationsnummer hat sich geändert

ID (DFGSM): aufgrund der neuen ID von DFGSM wurde die ID dieser Datei angepasst

(DFTELEKOM): im SIM in DFTELECOM angesiedelt

name: nur der Name wurde an UMTS angepasst, sonst keine Änderungen

name + lLv.: der Name wurde angepasst, die Datei wurde im Baum um ein Level nach oben verschoben

3G Pb: 3G Anwendungen (UMTS) sollen die Daten nicht aus dem DFTELECOM auslesen, sondern aus dem DFPhonebook. Die Daten stehen nur aus Gründen der Abwärtskompatibilität zu älteren Endgeräten in diesem Verzeichnis (manche Dateien sind auch unter ADFUSIM angesiedelt).

Einige weitere Dateien, die zusätzlich zu den im SIM enthaltenen, in UICC implementiert wurden bzw. optional

zu implementieren sind, wurden bereits in Kapitel 5.1 aufgelistet und teilweise diskutiert.

Auswertung der Tabelle 15:

Einige optionale Dateien des SIM sind nicht übernommen worden. Sie spielen im UMTS Umfeld entweder keine

Rolle mehr, oder wurden auch bei Phase 2 nicht oder kaum genutzt. Die für GSM relevanten Dateien sind alle

übernommen worden, wodurch die Kompatibilität von 3G-Endgeräten und -Karten zum GSM-Netz gesichert ist.

Nur eine obligatorische Datei aus dem SIM wurde nicht in die UICC übernommen, nämlich das EFPhase. Diese

Datei spielt bei UMTS keine Rolle und die Phasenerkennung erfolgt durch das Fehlen der Datei EFDIR auf MF-

Level. Die im SIM obligatorische Datei EFLP im DFGSM wurde in EFLI (Language Identifier) umbenannt, um ein

Level nach oben verschoben, also direkt unter das ADFUSIM, und als optional definiert. Die UICC verfügt selbst

über eine obligatorische Datei, die Sprachpräferenzen des Benutzers speichert. Tatsächlich ist es so, dass Dateien

die nachträglich hinzugefügt werden, grundsätzlich nur als optional deklariert werden dürfen. Erst wenn eine

neue Karte eingeführt wird, kann dies geändert werden. Eine Erklärung dafür könnte auch der Umstand sein,

dass die Spracheinstellung der UICC direkt unter dem Masterlevel für alle Module der UICC-Karte gelten soll.

Das in SIM optional zu implementierende EFECC (Emergency Call Codes) wurde in der UICC als obligatorisch

erklärt. Auch hier gilt obige Erklärung.

Einige neue Dateien sind bei der UICC hinzugekommen, so. z.B. das Telefonbuchverzeichnis und die auf allen

Ebenen wiederkehrende Datei EFARR (Access Rules Reference), die dem mobilen Endgerät anzeigt, wie auf die

Dateien dieses Levels zuzugreifen ist (vgl. Kapitel 5). Im Wesentlichen handelt es sich dabei aber um Dateien,

die Serviceleistungen für den Benutzer erfüllen, und nicht um Systemdateien.

Vergleich SAT – USAT:

Wie bereits in Kapitel 4 erläutert wurde, hat sich zwischen SAT und USAT abgesehen von einem TLV-Objekt

(vgl. Kapitel 5.1, „USAT“) funktional betrachtet keine Änderung ergeben. Dass USAT als eigenständiges Modul

neben USIM koexistiert, ist als eine konsequente Umsetzung der im SIM bereits imaginären Trennung anzuse-

hen. Wie aus mehreren Schaubildern (vgl. [15], Annex E) in der SIM-Spezifikation zu erkennen ist, wurde das

SAT bereits vor der Einführung der UICC-Karte als eigenständige Anwendung betrachtet. Dort werden jeweils

die Einheiten SIM und SAT im Nachrichtenversand separat voneinander dargestellt.

89

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________ Vergleich des Befehlssatzes von SIM und UICC:

Die Funktionen von SIM und UICC sind bis auf die Nomenklatur fast gleich geblieben. Die CHV wurde in PIN

umbenannt, die Anweisung VALIDATE und INVALIDATE in ACTIVATE und DEACTIVATE, SEEK in

SEARCH RECORD und RUN GSM ALGORITHM in AUTHENTICATE, wobei AUTHENTICATE (s.u.) drei

zusätzliche Algorithmen (vgl. Kapitel 5.2) umfasst. Bei der UICC ist die Anweisung MANAGE CHANNEL

hinzugekommen. Dieser Anweisung wurde noch keine Bedeutung zugewiesen (vgl. dazu [17], Kapitel 11.1.17).

Vergleich der sicherheitsrelevanten Prozeduren (Netz-Authentisierung, Verschlüsselung, Benutzerauthen-

tisierung) von SIM und UICC:

Das Sicherheitskonzept der UICC-Karte im UMTS Umfeld ist ungleich aufwändiger gestaltet als bei der SIM-

Karte im 2G-GSM Umfeld. Die folgende Tabelle stellt die Unterschiede in den Sicherheitskonzepten dar. Nähe-

re Informationen dazu stehen in den Kapiteln 3 und 5 und Abbildung 49.

Sicherheitskonzept von SIM und UICC bzgl. der Datenintegrität auf der Luftschnittstelle und dem Authenti-sierungsprozess im Vergleich

Features SIM UICC

Authentifikation Benutzer gegenüber Chipkarte CHV1, CHV2 PIN1, UPIN Explizite Authentisierung des Benutzers gegen-über einzelnen Anwendungen nein PIN2 Sperrung nach dreimaliger Fehleingabe des Pass-wortes

Freischaltung durch PUK Freischaltung durch PUK Authentisierung Chipkarte gegenüber ME Es können Codes verein-

bart werden (vgl.[24], Ka-pitel 5.3.2)

nur gegen Entfernung ge-sichert

Authentisierung Chipkarte gegenüber Netz SRES/XRES RES/XRES Zeitliche Gültigkeitsbeschränkung von Zufallzahlen zur Schlüsselgenerierung

s- nein Sequenznummern

Authentisierung Netz gegenüber Chipkarte nein MAC/XMAC Gesicherte Datenübertragung über die Luftschnitt-stelle

64 Bit Verschlüsselung 128 Bit Verschlüsselung Abgestufte Zugriffsbedingungen auf Daten der

Chipkarte siehe Tabelle 13 Siehe Tabelle 13

Unabhängigkeit des Authentisierungsprozesses gegenüber dem Netz durch Nichterreichbarkeit des HLR/AC

VLR/SGSN übernimmt die Authentifizierung anhand

von temporären Daten

nein

Wahrung der Anonymität des Benutzers durch TMSI durch TMSI (TMUI) Authentisierung von Anwendungen gegenüber Anwendungen, die auf Empfängerseite angesto-ßen werden, bzgl:

(vgl. [24], Kapitel 5.4.1) Als künftiges USAT Fea-

ture geplant

Anwendungen untereinander nein geplant Datenintegrität nein geplant

Datenherkunft (von der andere Anwen-dung) nein geplant

Sicherheit vor Replay Attacken nein geplant Sequenzintegrität der einzelnen Datenpa-

kete nein geplant Empfangsbestätigung nein geplant

Vertraulichkeit der Daten nein geplant

Explizit geforderte sichere Datenübertragung zwi-schen VLR/SGSN/MSC und HLR/AC

nein ja

Tabelle 16: Unterschiede in den Sicherheitskonzepten von UICC und SIM

90

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________ Geplante Anwendungen, z.B. M-Commerce stellen hohe Anforderungen an die Informationssicherheit. Die Fle-

xibilität bzgl. neuer Anwendungen soll nicht durch mangelnde Sicherheitsmechanismen eingeschränkt werden.

*1Vergleich der Initialisierungsprozeduren von SIM und USIM:

Tabelle 17 enthält alle Dateien, die bei der Initialisierung der Reihe nach vom ME je SIM und USIM angefordert

und ausgewertet werden. Zunächst erfolgt je nach Dienst bei der Initialisierung eine Überprüfung (Ü), ob er im

EFSST aktiviert ist. Hat sie statt gefunden und war erfolgreich, oder wurde sie nicht durchgeführt, werden nach

dem Anfordern der Datei ggf. die Schritte Lesen (L) und Updaten (U) ausgeführt. Verzeichniswechsel werden

als Current Directory (DIR) symbolisiert. ÜV bezeichnet die Überprüfung einer geforderten Datei auf Existenz

und Verwertbarkeit. Ist die Datei nicht verfügbar oder verwertbar, so wird ggf. eine andere Datei ausgelesen

( ). Wenn auch diese nicht verfügbar oder verwertbar ist, werden die Defaulteinstellungen (D) vorwendet. SIM (vgl. [15], Kapitel 11.2.1) USIM (vgl. [18], Kapitel 5.1.1.1)

Aktivierung und CHV Eingabe steht vor der Initialisierung Aktivierung der UICC und Wahl des ADFUSIM (DIR) stehen vor Initialisierung

EFDIR , (ÜV,L) DFGSM *1 (aktuelle Position ist ADFUSIM)

DFGSM , (DIR)

EFECC , (ÜV, L) EFECC , (L)

EFELP , (ÜV, L) EFLP(MF), (L) (D) EFLI , (ÜV, L) EFPL (MF), (L), (D)

PIN (ADFUSIM)Überprüfung, wenn erfolgreich Folgendes, sonst Wdhlg.

EFAD , (L) EFAD , (L)

EFSST , (L) EFUST , (L)

EFIMSI , (L) EFIMSI , (L)

EFACC , (L) EFACC , (L)

EFHPLMN , (L) EFHPLMN , (L)

EFPHPLMNAT , (L)

EFInvScan , (Ü, L)

EFPLMNsel , (Ü,L,U) EFUPLMNsel , (L); EFOPLMNsel , (L); EFPLMNsel (U)

Anforderung der GSM Initialisierung an das Netz

EFHPLMNAcT , (Ü,L)

EFPLMNwAcT , (Ü,L,U)

EFOPLMNwAcT , (Ü,L)

EFRPLMNAcT , (Ü,L,U)

EFLOCI , (L, U) EFLOCI , (L,U) und/oder EFLOCIPS , (L,U)

EFKc , (L,U) EFKeys , (L,U) und/oder EFKeysPS , (L,U)

EFBCCH , (L,U)

EFCPBCCH , (Ü,L,U)

EFPLMN , (L,U) EFFPLMN , (L, U)

EFSTART-HFN , (L,U)

EFTHRESHOLD , (L)

EFCBMI , (L,U)

EFSAI , (L); EFSLL , (L,U); LSA Discriptor Files (U)

EFCBMID , (Ü,L,U)

EFDCK , (Ü,L)

EFNIA , (Ü,L)

Tabelle 17: Vergleich Initialisierungsprozedur SIM-USIM

*1 Findet das UMTS Endgerät auf der UICC kein EFDIR oder darin enthalten keinen Eintrag, der auf ein ADFUSIM hinweist, so geht es davon aus, dass ein GSMSIM vorliegt und versucht gleich die GSM Initialisierung zu starten. Die funktionalen Aspekte der Einbuchung in das GSM-Netz sind gegeben.

91

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________ Fazit: Wie gezeigt wurde, konnte im Laufe der Entwicklung der Chipkarten im Mobilfunk konnte eine stetige Verbes-

serung der Informationssicherheit, des Benutzerkomforts und der Übertragungsraten festgestellt werden, wobei

Letzteres nicht im Zusammenhang zu den Chipkarten steht. Ebenso wurde die Menge der verfügbaren Dienste

immer weiter vergrößert. Ein großer Teil der technischen Veränderungen und der daraus resultierenden Erweite-

rung der Dienstvielfalt, die beim Wechsel von GSM über GPRS auf UMTS vollzogen werden (wurden), ist aus-

schließlich durch die entsprechenden Implementierungen der Dienste in Wirknetz und Endgeräten erreicht wor-

den. Die Verantwortlichkeit der Chipkarte für die Realisierung dieser neuer Dienste, wie Streaming Audio,

Streaming Video, E-Commerce und M-Commerce, sowie Bildtelefonie und Web-Browsing beschränkt sich auf

die Erfüllung umfangreicher Anforderungen in Bezug auf Sicherheitsmechanismen (also Schaffung sinnvoller

Grundvoraussetzungen), die zum einen den Benutzer und seine persönlichen Daten schützen, zum anderen aber

auch die jeweiligen Dienstanbieter absichern.

Durch die Implementierung einer restriktiven Rechtevergabe auf alle Daten der Chipkarte, definierter Authenti-

sierungsprozesse zwischen allen unmittelbar*1 beteiligten Institutionen (untereinander) anhand von Challenge-

Response-Verfahren und Anwendungen anhand von Zeitstempeln, und die Anonymisierung der Benutzer mit

Hilfe von häufig wechselnden langen (in Relation zur Gültigkeitsdauer) Schlüsseln, die nur ein einziges Mal

vergeben werden dürfen, ist ein Sicherheitsniveau erreicht worden, das beim heutigen Stand der Technik kaum

noch zu verbessern ist.

Bedauerlicherweise wurde dieses Sicherheitsniveau bislang nicht konsequent auf allen Ebenen explizit gefordert

und wenn gefordert, dann nicht klar definiert. Einen echten Schwachpunkt in diesem System (UMTS) stellen die

Netzbetreiber und Kartenhersteller dar: Ihnen obliegt die volle Verantwortung für die Art der Umsetzung einer

gesicherten Datenübertragung im Festnetz und eines gegen gewaltsame Eingriffe geschützten Speichers auf der

Chipkarte: Die Tatsache, dass nicht festgelegt wurde, auf welche Weise (aus Hardware-Sicht) die auf der Karte

als sicher geltenden Speicherbereiche zu implementieren sind, ist als Schwachpunkt des Gesamtsystems zu be-

zeichnen, da die Sicherheit des Gesamtsystems u.a. auf der Sicherheit der auf der Karte gespeicherten, vertrauli-

chen Daten basiert. Zwar wurden die Zugriffsbedingungen, unter denen auf diese Daten der Karte über das ME

zugegriffen werden darf klar definiert und durch Spezifikationen auch gewährleistet, dass die Daten ohne ent-

sprechend legitimiertes Terminal nicht ausgelesen werden können, es wurde jedoch nicht festgelegt, wie sie ge-

gen gewaltsame, externe Zugriffe zu schützen sind.

Das Fehlen fest definierter, verpflichtender Anforderungslisten bzgl. der beiden obigen Punkte (Datenübertra-

gung im Festnetz und Kartensicherung gegen physikalische Angriffe) schränkt die Sicherheit des Gesamtsystems

zunächst einmal (je nach tatsächlicher Umsetzung durch Netzbetreiber und Kartenhersteller muss dieses Problem

ja nicht gegeben sein) stark ein.

Auch ist der in Kapitel 5 beschriebene Verstoß gegen die Sicherheitsanforderungen bei der Übergabe der IMSI

im Klartext eine ernstzunehmende Sicherheitslücke.

Der Benutzer wird nicht wissen ob seine geheimen Schlüssel vom HLR/AC ans VLR/SGSN im Klartext oder

mit adäquaten Schlüsseln chiffriert übergeben werden. Ebenso wenig wird er wissen, ob seine auf der Karte ge-

speicherten, persönlichen Daten (ggf. z.B. gespeicherte Kontoinformationen) nach Verlust des Endgeräts tatsäch- *1 Unmittelbar im Sinne von direktem Kontakt: gemeint sind die beteiligten Netzelemente im Umfeld der Luft-schnittstelle

92

Kapitel 6: Vergleichende Analyse und Zusammenfassung ________________________________________________________________ lich sicher sind. Durch dieses Unwissen wird der Benutzer keine Gelegenheit haben, sich die sicherste Alternati-

ve (Netzbetreiber, Kartenherausgeber) auszusuchen, zumal der übliche Benutzer ein informationstechnischer

Laie und daher kaum in der Lage ist, solche Probleme selbständig zu erkennen.

Jedenfalls wurde mit der Spezifikation von UICC und USIM eine ernstzunehmende Basis für eine zukünftige,

sichere Datenübertragung geschaffen, und es bleibt zu hoffen, dass die entsprechend konsequente Umsetzung bis

in die letzten Subsysteme verantwortlich fortgeführt wird.

93

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________ 7 Ausblick: Entwicklungstrends Im Folgenden werden einige neue Dienste beschrieben, die in Zukunft bedingt durch die neuen Möglichkeiten,

in UMTS umgesetzt werden können. Einer Umsetzung vor UMTS standen unter anderem die niedrigen Übertra-

gungsraten, aber auch die nicht erfüllten Sicherheitsanforderungen einzelner Dienste im Wege. Auch ist die Um-

setzung einer paketorientierten Datenübertragung für diverse Anwendungen, wie z.B. Streaming Audio und

Streaming Video eine absolute Voraussetzung zu ihrer Umsetzung.

Im Folgenden werden ausschließlich Kernanwendungen beschrieben, bei denen die Chipkarte in der Umsetzung

eine Rolle spielt bzw. spielen könnte. Darüber hinaus gibt es eine lange Liste von Chipkarten-unabhängigen

Anwendungen und wahrscheinlich auch eine Reihe von Anwendungen in die zwar die Chipkarte direkt invol-

viert ist, die aber noch nicht öffentlich diskutiert wurden.

M-Payment und E-Commerce Mobile-Payment ist bereits in 2G-GSM umgesetzt, jedoch nur sehr verhalten genutzt worden. Eine deutliche Er-

höhung der Sicherheitsstandards, wie sie in UMTS erfolgt, könnte eine Etablierung solcher Dienste bewirken.

Der mobile Teilnehmer ruft eine bestimmte Service-Nummer an, woraufhin ihm ein fester Betrag von seinem

Mobilfunkkonto abgebucht bzw. in seine Rechnung aufgenommen wird. Dieser Fall ist trivial, da die Bezahlung

lediglich von den Kosten der Service-Nummer abhängig ist, es handelt sich ja um einen Festbetrag. So ange-

wandt kann das System z.B. für Spendenaktionen oder auch One-Price-Verkaufsaktionen (sofern die Ware sofort

übergeben wird) genutzt werden. Es entspricht einem Lastschriftverfahren für Festbeträge, bei dem der Kunde

anstelle seiner Unterschrift, seine Willenserklärung durch einen Anruf bekundet. Das Geld wird sicher übertra-

gen, seine Personalien stehen durch seinen Mobilfunk-Vertrag bereits fest und das Risiko trägt die Telefonge-

sellschaft, die das Geld vom Benutzer einzutreiben hat. Ein solches System ist ausschließlich für Übertragungen

von Geldbeträgen gegen sofort erfolgte Servicedienstleistungen oder sofort übertragene Waren sinnvoll, da der

Dienstleister oder Verkäufer (jedenfalls nicht ohne aktive Mitarbeit des Kunden) über die persönlichen Daten,

wie z.B. die Lieferadresse oder den Namen des Kunden verfügt. Eine Bestätigung der Anweisung kann z.B.

durch eine SMS erfolgen, die nach erfolgtem Anruf automatisch verschickt wird und diesen bestätigt. Der Kunde

zeigt dem Verkäufer diese Bestätigung auf dem Display des ME (die Thematik des Vortäuschens soll an hier

nicht erörtert werden). Mit der Einführung von Ipv6 könnte ein entsprechender Händler, jeder Produktgruppe

(nach Preisen gruppiert) eine eigene, feste „Telefonnummer“ (IP-Adresse) als Service Nummer zuweisen, so

dass auch dieses System vielseitiger würde.

Wesentlich interessanter ist jedoch ein Anweisen beliebiger Geldbeträge, so dass das mobile Endgerät auf diese

Weise zumindest zeitweise die Kreditkarte ersetzen kann. Eine zusätzliche Möglichkeit persönliche Daten zu

übermitteln, so dass eine Hauslieferung in Frage kommt, sollte ebenfalls bestehen. Des Weiteren muss dem

Händler eine Bestätigung übermittelt werden können, von der er sicher sein kann, dass sie von einer glaubwürdi-

gen Stelle aus erfolgt, z.B. durch eine SMS auf sein mobiles Endgerät: Er hinterlässt mit dem Erwerb der Servi-

ce-Nummer seine MSISDN, auf die Bestätigungen zu schicken sind. Zusätzlich zu den gestellten Anforderungen

sollte auch der Kunde eine Möglichkeit haben, von seinem Kauf zurücktreten zu können.

Ein solch komplexes Verfahren bedarf nicht nur einer neutralen, für alle Beteiligten vertrauenswürdigen Instanz

sondern ebenso aufgrund hoher Anforderungen an die Integrität der übertragenen Daten und den Datenschutz

sowie die Identität des Kunden, eines aufwändigen Hintergrundsystems. Dies könnte durch UMTS gewährleistet

93

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________ werden. Insbesondere in Bezug auf die Identität des Benutzers ist UMTS ein wesentlicher Vorteil gegenüber

dem stationären Internet. Ein entsprechendes, nicht veränderliches oder von Dritten auslesbares Modul (ADF)

für M-Payment könnte implementiert werden. In Verbindung mit einem im Endgerät integrierten Internet-

Browser könnte solch ein Modul die fehlende Sicherheit im Internet ausgleichen. Die Voraussetzung für ein

Umsetzen ist jedoch die Bereitschaft der Mobilfunk-Dienstanbieter, ein solches System über ihre Kundenab-

rechnung abzuwickeln und die entsprechende Bereitschaft eines oder aller Beteiligten, die entstehenden Kosten

zu übernehmen.

Diese Voraussetzung kann eingespart werden, wenn das gleiche System für E-Commerce genutzt wird. Bei E-

Commerce verwendet der Kunde z.B. seine Kreditkarte oder er erteilt eine Lastschriftgenehmigung (oder zahlt

per Rechnung, Überweisung, ...). Eine zusätzliche Verschlüsselung der Kundendaten kann über Standards wie

SSL oder HTTPs (via dem im Endgerät integrierten Browser) realisiert werden, so dass auch die Übertragung im

Internet verschlüsselt und sicher stattfinden kann. Voraussetzung für eine mobile Nutzung von E-Commerce

Anwendungen ist die Implementierung von SSL und HTTPs im Browser der Endgeräte.

Ein weiterer Anwärter für Module auf der UICC sind in diesem Zusammenhang Kontoungebundene Geldkar-

tensysteme, bei denen der Kunde für seine Geldkartennummer einen bestimmten Betrag gutschreiben lässt den er

zuvor z.B. bei seinem Mobilfunk-Dienstanbieter eingezahlt hat und der bei Transaktionen entsprechend verrin-

gert wird. Dieses System wird über ein Schattenkonto geführt, das von der Kartennummer (im Falle der UICC -

Modulnummer) repräsentiert wird. Ein solches System ist bereits eingeführt und könnte sich zumindest für das

Bezahlen von kleineren Geldbeträgen durchsetzen (vgl. [k])..

Von einer Weiterführung der bereits seit 2G-GSM bestehenden Paybox-Verfahren ist auszugehen. Bei Paybox-

Verfahren, die für mobile Endkunden konzipiert sind, schließen Verkäufer und Kunde jeweils Verträge mit der

Paybox AG ab. Sie übernimmt die Rolle einer vertrauenswürdigen Instanz. Nachdem der Kunde seinen Zah-

lungswunsch an den Händler geäußert hat (in Verbindung mit seiner Handy-Nummer), übermittelt dieser den

Zahlungswunsch an die Paybox AG. Die Paybox AG lässt sich den Zahlungswunsch vom Kunden bestätigen,

indem er angerufen und angehalten wird, seine Bereitschaft mit der Eingabe einer 4-stelligen PIN zu bezeugen.

Die Bezahlung wird über ein Lastschriftverfahren abgewickelt. An das Paybox-System werden keine weiteren

Anforderungen an die Technik des Mobilfunknetzes gestellt, wodurch es auch bereits bei GSM einsetzbar war.

Sowohl für den Kunden, als auch für den Händler entseht eine geringe jährliche Grundgebühr ((vgl. [k], Größen-

ordnung: 5 Euro).

Es gibt diverse weitere Bezahl-Modelle, wie net900 Classic (Micropaymentsystem, das entweder ein Software-

modul auf der UICC oder aber eine Integration in die Software des ME erfordert), E-Cash (Wallet-System, es

erfordert ebenfalls Software auf Client Seite, die in Form eines Moduls auf der UICC oder im Endgerät abgelegt

werden könnet) und andere, die mit Hilfe der modularen Fähigkeiten der UICC-Karte im UMTS Umfeld zum

mobilen Einsatz führen könnten. Die größte Hürde bei all diesen Systemen ist die Akzeptanz auf Benutzer- und

Händler-Seite. Aufgrund der wesentlich höheren Sicherheit im UMTS-Umfeld gegenüber dem Internet und

GSM wäre eine wirkliche Etablierung solcher Dienste durchaus denkbar (vgl. [k]).

Ob sich das im IT-Umfeld ehemalige (vgl. [γ]) Hype-Thema Nr.1: M-Payment bzw. M-Business aufgrund der

neuen Perspektiven, die durch UMTS gegeben sind wieder erholt und seine einstige Position in der Software-

94

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________ entwicklung wieder einnimmt oder bei Softwareentwicklern den Status eines „Waisenkinds“ beibehält, bleibt

abzuwarten.

Location Based Services Location Based Services (LBS, vgl.[α] ) gibt es in ersten Versuchen bereits seit der Einführung von WAP.

Die Idee: Der mobile Kunde befindet sich an einer beliebigen Stelle und möchte Dienstleistungen seiner näheren

Umgebung nutzen oder sich informieren, welche Dienstleistungen dort überhaupt verfügbar sind. Beispiele für

solche Dienstleistungen sind vielfältig, lokale Gastronomie (insbesondere Lieferdienste), Veranstaltungsorte, wie

Kinos, Theater, Konzerthallen, Taxiruf, Notfallservicedienstleistungen wie Autoreparaturienste oder auch Am-

bulanzen. Ebenso fallen alle Arten von (mobilen) Verkehrsleitsystemen unter den Oberbegriff LBS.

Der Kunde, der in seiner Umgebung fremd ist und die lokalen Servicenummern nicht kennt, wählt eine univer-

selle Servicenummer des gewünschten Dienstes, die automatisch an die lokalen Dienstleister vermittelt wird. So

könnte einem Pizza-Lieferdienst automatisch die aktuelle Position des Kunden übermittelt werden, ohne dass

dieser sich zunächst informieren muss, wo genau er sich zur Zeit gerade befindet. Das Anrufen der Servicenum-

mer an sich stellt keine Problematik des Mobilfunks dar, es liegt an der Methode der jeweiligen Telefongesell-

schaften, wie sie die Servicerufnummern auflösen. Eine möglichst genaue Lokalisierung des Kunden jedoch ist

abhängig vom ihm umgebenden Mobilfunksystem.

Zur Feststellung seiner Position gibt es seit 2G drei Modelle. Vorausgesetzt wird zunächst, dass sich der Benut-

zer nach der Anforderung des Dienstes nicht mehr bewegt:

• Der Zellradius als Positionsangabe: Der Kunde befindet sich innerhalb einer GSM-Zelle, also maximal

in einer Entfernung von 70 Km (2* 35 Km Radius, wenn beide beteiligten sich im ungünstigsten Fall

genau auf den gegenüberliegenden Grenzen der Zelle befinden) von seinem z.B. Geschäftspartner. Für

Speisenlieferdienste, die maximal 15-20 Km weit liefern ist dies bereits zu viel. Auch ist die Anfahrt

von ggf. 70 Km um ins lokale Kino oder Theater zu gehen, kaum zumutbar. Diese Methode ist also zu

ungenau und ermöglicht höchstens die Nutzung von Diensten über WAP, wo dann über die grafische

Menüsteuerung weitere Eingrenzungen gemacht werden können - das erfordert vom Benutzer die

Kenntnis seiner Umgebung (z.B. Straßennamen, Ortsnamen, etc.)

• Kreuzpeilung zwischen den umliegenden Base Transceiver Stations: Um eine Kreuzpeilung durchfüh-

ren zu können, müssen mindestens drei Messpunkte existieren. Zwischen je zwei BTSs besteht, voraus-

gesetzt sie stehen jeweils in der Mitte ihrer Zelle, ein Abstand von 70 Km, was je nach Benutzerposition

auch dessen Maximalabstand zu den BTSs der Nachbarzellen ist. Voraussetzung für eine Kreuzpeilung

wäre eine Geländeform, die ein direktes Senden ohne Reflektionen ermöglicht, da die Sendedauer bei

Reflektionen verfälscht wird, was eine sinnvolle Auswertung der Daten unmöglich macht. Insbesondere

in Deutschland ist ein solches System nicht einsetzbar, da zum einen die deutsche Geländeform nicht

als flach zu bezeichnen ist und zum anderen aufgrund eben dieser Tatsache die BTSs nicht immer im

Zentrum ihrer jeweiligen Zellen stehen. Die GSM-Beschränkung der Zellgrößen auf 35 Km Radius re-

sultiert aber insbesondere aus der mit größerem Abstand stark sinkenden Signalqualität. Eine minimale

Signalqualität ist jedoch auch für eine Kreuzpeilung erforderlich: Es müssen zwar keine Sprachdaten

übertragen werden, aber das zwar kurze Signal muss zur Erkennung dennoch fehlerfrei sein. Eine Erhö-

hung der Sendeleistung ist aus gesundheitlichen Gründen und Gründen der Störung von Nachbarzellen

ausgeschlossen.

95

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________

• Global Positioning System (GPS) und Kombinationsverfahren aus GPS und den oben beschriebenen

Verfahren: Der Einsatz von GPS im Umfeld des europäischen Mobilfunks erfordert zum einen eine A-

daption von GPS in die mobilen Endgeräte und bedeutet zum anderen automatisch eine Abhängigkeit

von der amerikanischen Technik und somit von der Willkür der amerikanischen Regierung: Die Ver-

wendung von GPS außerhalb der USA bzgl. der zugelassenen Genauigkeit wurde aus militärischen

Gründen eingeschränkt und auch bereits vollständig unterbunden (Golf-Krieg). Das europäische Pen-

dant zu GPS, Galileo genannt, befindet sich zur Zeit in der Entwicklung und könnte ersatzweise einge-

setzt werden. Letztlich ist diese Lösung zumindest für GSM die einzig sinnvolle Variante, da sie eine

genaue Ortsbestimmung zulässt.

Wie gezeigt wurde, hängt die Umsetzung einer möglichst genauen Positionsbestimmung im Mobilfunknetz von

vielen Faktoren ab, die größtenteils im GSM-Umfeld eine Einführung entsprechend anspruchsvoller Dienste

verhindern. Mit der Einführung von UMTS und der damit verbundenen Einführung von städtischen Zellen (Ur-

ban Cells), die auf max. 300 m Radius beschränkt sind, sieht die Sachlage zu mindest in Ballungsgebieten (Mic-

ro Cells) anders aus: Hier wäre sogar eine Kreuzpeilung umsetzbar, deren Daten jedenfalls genau genug wären,

einen Pizzadienst zu rufen oder einen Tisch im Restaurant bzw. eine Theaterkarte zu reservieren. Für einen

Herzpatienten, der durch einen Knopfdruck auf sein mobiles Endgerät im Falle eines angehenden Infarkts auto-

matisch einen Notarzt rufen will, und der ihn anhand der ihm zur Verfügung stehenden Daten auch sicher findet,

ist das urbane Zellnetz noch nicht feinmaschig genug. Auch wird der Benutzer dem Pizzadienst nach wie vor ei-

ne Adresse nennen müssen, was aber in Städten kaum ein Problem darstellen sollte. Außerhalb von Ballungsge-

bieten beträgt der Radius bis zu 20 Km (eher kleiner). Dies ist ebenfalls noch ein akzeptabler Wert für die oben

genannten Dienste.

Um ein Notfallsystem zu implementieren, bei dem der Rettungsleitstelle eine zuverlässige und verwertbare Posi-

tionsbestimmung übergeben werden kann bedarf es nach wie vor zusätzlicher Technologien, die entsprechend im

Endgerät integriert werden müssten. Anhand der übertragenen TMSI könnten in solch einem Notfall sogar be-

reits der Name und somit die Krankheitsgeschichte des Patienten erfasst werden, ehe der Arzt zum Patienten ge-

langt. Da dies einen Bruch im Sicherheitssystem von UMTS und insbesondere in Bezug auf die Datenschutzver-

ordnungen bedeutet, müsste ein entsprechender Risikopatient eine Genehmigung erteilen, dass im Falle eines

abgesetzten Notrufs der Rettungsdienst die entsprechenden Daten erhalten darf.

Eine weitere Anwendung für LBS sind Verkehrsleitsysteme: Der Kraftfahrer stellt sein MS in eine dafür vorge-

sehene Station im Fahrzeug. Anhand von Sendestationen, die entlang der Straßen positioniert sind und deren

Signale das MS auswertet, kann seine jeweils aktuelle Position auf einer digitalen Karte eingetragen werden. Un-

ter anderem Mautsysteme können solch eine Umsetzung gut verwenden und die Abrechnung gleich über den

Mobilfunkvertrag oder ein Bezahlmodul, das auf der UICC (s.o.) integriert ist, durchführen. Erste Schritte zu ei-

ner Umsetzung eines Mauteinzugs für LKWs sind in Deutschland durch die Festlegung der zu wählenden Tech-

nologie bereits gegangen worden (vgl. [β]). In diesem Modell werden die mobilen Endgeräte jedoch lediglich

zum Übertragen der Daten an eine Abrechnungsstelle verwendet. Eine Verwendung von Chipkarten als Zah-

lungsmittel ist vorgesehen und so wäre der Schritt naheliegend, entsprechende, aufladbare Zahlkarten als Module

auf der UICC zu integrieren.

96

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________ Streaming Audio und Streaming Video Bereits seit der Einführung von GPRS und der damit verbundenen paketorientierten Datenübertragung gibt es in

Deutschland auch im Mobilfunk Dienste wie Streaming Audio und Streaming Video. Aufgrund der immer noch

relativ geringen verfügbaren Bandbreite und der Aktualität der Diensteinführung sind kaum Prognosen bezüglich

dieser Dienste in Deutschland möglich. UMTS bietet jedenfalls die notwendige Bandbreite um die Dienste in

befriedigender Form anbieten und nutzen zu können. Eine umfassende Einführung dieser Dienste wird weitest-

gehend von der Implementierung entsprechende Abspielgeräte in den Endgeräten und von der Unterstützung

durch das Netz abhängig sein. Eine neuerdings zusätzlich hinzugekommene Hürde für die rasche Verbreitung im

mobilen Umfeld dürfte die neuerdings durch Forgent (vgl. [δ]) in den USA eingeforderten Patentlizenzgebühren

auf im JPEG-Format komprimierte Dateien sein. Eine entsprechende Abrechnung, die auf den Kunden umgelegt

wird, könnte On-the-fly über die UICC realisiert werden.

In Japan (vgl. [ε]) wurde der „technische Vorläufer“ von UMTS, i-mode, zum Kassenschlager für „die japani-

sche HipHop-Generation“ und insbesondere die Dienste, mit deren Hilfe „Bilder und Texte auf dem Handy

flimmern“. Diese Dienste werden dort bereits von 33 Millionen Kunden begeistert genutzt. Ob Japans Trends

jedoch repräsentativ für Deutschland bzw. ganz Europa sind, und die entsprechenden Endgeräte auch hier zu

„Statussymbol“ und „Mittel der Selbstdefinition“ avancieren bleibt fraglich. Jedenfalls bietet Japan in dieser

Beziehung für die europäischen Mobilfunkdienstanbieter ein erfreuliches Beispiel, an dem man sich gerne orien-

tiert („E-plus imitiert“ bereits „japanische Multimediaangebote“).

Qualifizierte digitale Signatur Die Aufnahme der Qualifizierten Digitalen Signatur in die UICC hängt direkt von einer Integration eines ma-

thematischen Coprozessors in der UICC ab, der wiederum eine nicht unerhebliche Investition der Kartenheraus-

geber je Karte bedeuten würde. Die in der UICC verfügbaren Sicherheitsmaßnahmen würden den Einsatz zwar

ermöglichen, allein schon aufgrund der allgemeinen Tendenz auf der Seite der B2B-Anwender zur Ablehnung

dieser Signatur (vgl. [ζ]) ist die tatsächliche Investition seitens der Kartenherausgeber jedoch zweifelhaft.

Die Realisierung einer Vielzahl weiterer mobilen Dienste, wie Haussteuerungssysteme, All-IP-Netze, klassische

Internet-Dienste wie Chat-Räume, Firmenpräsentationen, mobile Partnervermittlungsagenturen, etc. sind mit der

Einführung von UMTS vorstellbar. Die Dienstentwicklung auf dem mobilen Markt wird auch in Zukunft span-

nend bleiben.

97

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________ Literaturverzeichnis: Spezifikationen: Nr.: Konsortium, Nummer, Rel.-Datum, Titel Beschreibung des Inhalts

[1] 3G TR 21.905 v1.0.0 (1999-10), Vocabulary for 3GPP Specifications

Auflistung und kurze Erläuterung des Fachvokabulars und der in 3G Spezifikationen häufig verwendeten Abkürzun-gen. Es handelt sich um eine reine Aufzählung und Bewer-tung von Features.

[2]

3G TS 34.123-2 v1.0.1 (2000-03), Release 99, User Equipment conformance specifica-tion Part 2: Implementation Conformance Statement (ICS)

Bei diesem Dokument handelt es sich um eine tabellarische Erfassung aller auf Implementierungsebene zu unterstützen-den Mechanismen (Funktionen des ME), z.B. Daten zur Kanalkodierung des mobilen Endgerätes (nicht zur tatsäch-lichen Umsetzung), der zu unterstützenden Frequenzen, Ü-bertragungsraten, etc. und den entsprechenden Spezifikatio-nen. Diese Dokumente sind für Programmierer als Quellen-übersichten gedacht, die sie nutzen, um möglichst schell an bestimmte Informationen (wo steht konkret, was wie gefor-dert wird?) zu gelangen. Entsprechend nützlich sind diese Dokumente auch für jeden Anderen, der nicht die Nummern der einzelnen Spezifikationen in Relation zu den Features kennt.

[3] ETSI GSM 02.07 Phase 1 (1995-01), Mobile Stations features

behandelt die grundlegenden Funktionen, die ein mobiles Endgerät unterstützen muss (mandatory, „m“) oder kann (obligatory, „o“). Es handelt sich um eine reine Aufzählung und Bewertung von Features.

[4] ETS 300 505, GSM 02.07 Phase 2 (1998-01), Mobile Stations features

Einige in Phase 1 als obligatory eingestufte Funktionen sind nicht mehr enthalten (-2) und einige neue Features sind hin-zugekommen (+2 m, +2 o) Es handelt sich um eine reine Aufzählung und Bewertung von Features.

[5] ETSI TS 100 906 v7.1.0 (2000-04), Mobile Stations features, Phase 2+

Etliche Erweiterungen zu Phase 2 (+7 o, +3 m), GPRS Un-terstützung ist zu gewährleisten Es handelt sich um eine rei-ne Aufzählung und Bewertung von Features.

[6] ETS 300 511 (1995-07), Phase 2, (GSM 02.30), Man- Machine Interface (MMI) of the Mobile Station (MS)

In dieser Spezifikation wird die Schnittstelle Mensch/Maschine beschrieben, z.B. welche Buchstaben ü-ber welche Tasten zu erreichen sein sollen, welche Schritte ein Benutzer einleiten muss um die MS nutzen zu können (Einlegen der SIM Karte, Laden des Akkus,...), etc.

[7] ETS TS 100 907 v7.1.0 (1999-08), Phase 2+, Man-Machine Interface (MMI) of the Mobile Station (MS) Release 98

Siehe [6], nur für Phase 2+!

[8] ETS 300 086 v3.9.0 (1992-02);Phase 1, Re-lease 92; Man Machine Interface of the Mo-bile Station

Beschreibung siehe [6], hier nur Phase 1

[9] ETS 300 508 v4.7.1 (2000-09), GSM 02.16, Phase 2, International Mobile Station E-quipment Identities (IMEI)

In diesem Dokument sind alle für den Programmierer not-wendigen Informationen zur IMEI aufgeführt.

[10]

ETSI TS 122 003 v3.1.0 (2000-01), Phase 2+ UMTS; Cicuit Teleservices supported by a Public Land Mobile Network (PLMN); (3G TS Version 3.1.0 Release 1999)

Eine Auflistung aller zu implementierenden Teledienste., das Dokument erläutert zunächst, was der entsprechende Teledienst leisten soll und listet dann alle entsprechenden Features mit Bewertung in einer Tabelle auf.

[11] ETS 300 521 (1994-09), GSM 03.01), Phase 2; Network Functions

Hier werden diverse Abläufe aus der Sicht des Netzwerks beschrieben (wer welche Aufgaben zu erfüllen hat).

[12]

ISO/IEC 7861-3; Identification Cards-Integrated circuit(s)Cards with contacts-Part 3, Electronic Signals and transmission protocols, 2te Auflage (1997-12-15)

Dies ist die internationale Standardisierung von Übertra-gungsprotokollen und Signalen bei Chipkarten.

[13]

ISO/IEC 7861-4; Identification Cards-Integrated circuit(s) Cards with contacts-Part 4, Interindustry commands for inter-change

Im vierten Teil dieser Normierung werden alle für Chipkar-ten fest definierten Kommandos beschrieben.

98

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________

[14] ETSI TS 100 922 v8.0.0 (2000-04), Sub-scriber Identity Modules (SIM), Release 99, Phase 2+; Functional characteristics

Dieses Dokument ermöglicht dem Leser einen Überblick über die über die funktionalen Charakteristika des SIM, wie sie dann ausführlich in TS 11.11 [13] beschrieben werden.

[15] 3GPP TS 11.11 V8.5.0 (2001-03), Release 99, Specification of the Subscriber Identity Module, SIM-ME Interface

In dieser Spezifikation ist die SIM Karte bis ins kleinste De-tail (Inhalt Elementary Files) spezifiziert.

[16] 3GPP TS 11.14 V8.8.0 (2001-09), Release 99, Specification of the SIM Application Toolkit for the SIM-ME Interface

Spezifikation der SIM – Funktionserweiterung SAT bis ins kleinste Detail

[17] ETSI TS 102 221 V3.3.0 (2001-05) Release 99, UICC Terminal Interface, Physical and logical characteristics

In dieser für Europa definierten Spezifikation wird die für UMTS zu verwendende Multi Applikation Karte als Smart-card spezifiziert. Auf ihr können SIM, SAT, USIM, USAT, WIM, etc. realisiert werden.

[18] 3G TS 31.102, V3.2.0 (2000-07), Release 99, Characteristics of the USIM Application

In dieser Spezifikation wird das an UMTS angepasste U-SIM (UMTS SIM) bis ins kleinste Detail beschrieben

[19] 3GPP TS 31.111 V3.3.0 (2000-12), Release 1999, USIM Application Toolkit (USAT) , Phase 2+

Hier werden die an UMTS angepassten SAT Anwendungen bis ins kleinste Detail beschrieben (kaum Veränderung zu [16]).

[20] WAP-260-WIM-20010712-a, Version 12-July-2001 Part: Security

In dieser Spezifikation wird das in UMTS wahrscheinlich implementierte Modul WIM beschrieben, dessen wesent-lichste Aufgabe die Realisierung von erweiterten Sicher-heitsmechanismen, wie das Speichern von Zertifikaten und Signaturen sein wird

[21] 3G TS 123.040 V3.7.0 (2001-12), Release 1999, UMTS Technical realisation of the Short Message Service, Phase 2+

Definiert die Umsetzung von SMS für UMTS

[22] 3G TS 23.038 v3.3.0 (2000-01), Release 1999, Phase 2+, UMTS Alphabets and lan-guage-specific information

Hier werden Bit und Byteweise Codierungsschemata ange-geben

[23] ETS 300 527 v4.6.0 (1996-09), GSM 03.09, Phase 2, Handover procedures

In diesem Dokument werden die Funktionen bzgl. der un-terschiedlichen Handover Mechanismen aller Komponenten des GSM Netzes spezifiziert und die einzelnen Szenarien aufgezeigt, die zu einer Handover Entscheidung führen so-wie deren Umsetzung schematisch dargestellt.

[24] ETSI TS 133.102 v3.5.0 (2000-07), 3G Se-curity; Security Architecture, Release 99

In diesem Dokument werden die Sicherheitsparameter des USIM teilweise bis hin zu den verwendeten Algorithmen beschrieben.

[25] 3GPP TS 31.101 v.3.3.0 (2000-07),Release 99; UICC Terminal Interface; Physical and Logical Characteristics

Eine zu [17] fast gleiche Spezifikation, nur dass diese nicht die Verwendung einer Smart Card voraussetzt und weltweit spezifiziert ist. Einige Aspekte sind in dieser Spec. be-schrieben (z.B. die Struktur der EFs auf dem Master Level), auf die [17] verweist, weil diese Daten nicht noch einmal aufgenommen wurden.

Literatur: Nr.: Autor(en), Titel, Jahr [A] M.Mouly, M.- B. Paulet,“ The GSM System for Mobile Communications“, 1992

[B] W.Rankel, W.Effing, „Handbuch der Chipkarten“, Aufbau – Funktionsweise - Einsatz von Smart Cards, Hanser Verlag, 3. vollständig überarbeitete Auflage1999

[C] G. Siegmund, „Technik der Netze“, 4.neubearbeitete und erweiterte Auflage 1999 [D] K. Lipinski (Hrsg.), „Lexikon der Mobilkommunikation“, MITP, DATACOM

99

Kapitel 7: Ausblick: Entwicklungstrends ________________________________________________________________

100

Referenzierte Webseiten: Nr.: Verantwortlicher, Jahr, Adresse Beschreibung

[a] Siemens AG, 2002: http://w3.siemens.de/solutionprovider/_online_lexikon/1/f010321.htm TK- Online-Glossar

[b] Siemens AG, 2002: http://w3.siemens.de/solutionprovider/_online_lexikon/1/f011481.htm TK- Online-Glossar

[c] Siemens AG, 2002: http://www.siemensmobile.de/btob/CDA/presentation/ap_btob_cda_presentation_ front door/0,2950,166,FF.html

TK- Online-Glossar

[d] Siemens AG, 2002: http://w3.siemens.de/solutionprovider/_online_lexikon/3/f009803.htm

Kurz-Präsentation neu-er Techniken der Fa. Siemens

[e] Siemens AG, 2002: http://w3.siemens.de/solutionprovider/_online_lexikon/0/f009170.htm TK- Online-Glossar

[f] UMTS-Forum, 04.2002: http://www.umts-forum.org/licensing.html Stammseite des UMTS-Forums

[g] UMTS-Report.com, Herausgeber Thomas Ottersbach, 2000/2001: http://www.umts-report.com/index.php4?seite=thema&thema=36

Beantwortet einige Fragen zu UMTS. UMTS-Report.com versteht sich als Onli-ne-Mobilfunk-Magazin.

[h] UMTS-Report.com, Herausgeber Thomas Ottersbach, 2000/2001: http://www.umts-report.com/index.php4?seite=thema&thema=26

[i] Physikalisches Institut der Universität Bonn: http://cips02.physik.uni-bonn.de/pool/infos/ascii/table.htm

ASCII Tabelle, wurde in Kap. 4.3 verwendet

[k] Prof. Dr. M. Leischner, M. Kannen: http://www.inf.fh-rhein-sieg.de/person/professoren/leischner/pdf/e-payment.pdf“

Eine Abhandlung über elektronische Zah-lungssysteme

Referenzierte White Papers, Zeitschriftenartikel: Nr.:

[α]

Informationstechnische Gesellschaft im VDE, Fachausschuss 7.2 zum Thema „Funksysteme“. Unterlagen einer öffentlichen Diskussionssitzung vom 16.11.2000 zum Thema „Lokation, Techniken und Dienste“ an der TU-Ilmenau Diverse Beiträge zum Thema LBS u.a. von Eriksson, T-Mobile International, Nokia, Inst. Für Informatik der Universität Ilmenau, u.a.

[β] Joachim M. Strampp, COMPUTER ZEITUNG, Nr. 20, 13. März 2002, S.8: „Wegezoll per Mobilfunk“

[γ] Compter Zeitung, Nr. 36, 2.9.2002, Nachrichten, S.4, (Müchen, ht): „Für Softwareanbieter spielt M-Buisiness kaum noch eine Rolle“

[δ] Compter Zeitung, Nr. 33, 29.07.2002, S.1, (Leinfelden, mr): „Lizenzforderungen für JPEG stellen Open-source infrage“

[ε] Götz Hamann, Die Zeit, 22.8.2002, Wirtschaft, S. 20: „Geliebt wie ein Gucchi-Täschchen“

[ζ] Ulrich Schmitz,Computer Zeitung Nr. 27, 1.07.2002, Nachrichten, S.4: „Umfrage, Anwender ignorieren das Signaturgesetz“