Diplomarbeit von Thomas Badura

Transcrição

Fakultät für Mathematik und Informatik
Security Analysis of Symbian OS Platform Security Architecture(PSA)
Diplomarbeit
von
Thomas Badura
vorgelegt am
Lehrstuhl Praktische Informatik I
Prof. Dr. F. Freiling
Betreuer: Dipl.-Inform. Michael Becher
September 2008
Ehrenwörtliche Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen
entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher
oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Mannheim, den 10. September 2008
......................................
Thomas Badura
Danksagung
Als Erstes möchte ich Prof. Freiling danken, der mir die Möglichkeit gegeben hat, meine
Diplomarbeit an seinem Lehrstuhl zu schreiben.
Weiterer Dank gehört Michael Becher, der mich während meiner Diplomarbeit betreut hat.
Erst durch seine konstruktive Kritik und die anregenden Diskussionen konnte diese Arbeit in
dieser Form entstehen.
Einen großen Dank muss ich meinen Eltern aussprechen, die mich in dieser schwierigen Zeit
unterstützten und mir das Informatikstudium erst ermöglicht haben.
Abschließend möchte ich noch T-Mobile in Bonn danken, für die Bereitstellung der Testgeräte.
Zusammenfassung
Die Ausstattungsmerkmale und Verbindungsmöglichkeiten heutiger Smartphones nehmen stetig zu. Dadurch gewinnen Sicherheitsmechanismen speziell für Smartphones bei dem täglichen
Umgang mit diesen Geräten eine immer größer werdende Bedeutung. Symbian hat mit der
Einführung der „Platform Security Architecture“ in Version 9 ihres Betriebssystems eine neue
Sicherheitsplattform für Symbian Smartphones vorgestellt. Jedoch wie bei jeder neuen Technologie ist mit der Einführung in den meisten Fällen mit Fehlern oder sonstigen Mängeln zu
rechnen.
Im Rahmen dieser Diplomarbeit soll zunächst die Konfiguration der „Platform Security Architecture(PSA)“ verifiziert werden. Dazu werden die erarbeiteten Konfigurationsmöglichkeiten
auf die Konfigurationsparameter der PSA abgebildet. Nachdem die Konfigurationsparameter
identifiziert und die jeweiligen Testbereiche der PSA gefunden wurden, wird das Testsystem
mit möglichst wenig Redundanz implementiert. Dafür implementiert das Testsystem einen
„Intelligent Code-Builder“, der abhängig der Konfigurationsdatei den Quellcode für die Testfälle generiert, einen „Package-Creator“ und einen „Emu-Builder“, die aus den generierten
Quellcode die Testfälle für die jeweilige Plattform erstellen. Jedoch erst durch die Definition
der Testfälle kann mit der entsprechenden Konfigurationsdatei der jeweilige Testbereich der
PSA mit den gefundenen Konfigurationsparametern verifiziert werden. Anhand der Evaluierung der Ergebnisse für die jeweilige Plattform, konnte die spezifizierte Funktionsweise der
PSA-Komponenten zum größten Teil verifiziert werden. Dabei konnte aber auch gezeigt werden, dass mit den entsprechenden Einstellungen in der SWIPolicy, jede Anwendung mit den
höchsten Capabilities ohne ein Zertifikat installiert werden kann. Auffällig in den sonst durch
die SWIPolicy dominierten Einstellmöglichkeiten der PSA war, dass der Benutzer die OCSPPrüfung ein- beziehungsweise ausschalten kann, diese jedoch selbst nicht funktioniert. Weitere
Tests ergaben auch, dass die Integrität der Installationsdateien nicht völlig gegeben ist und
Installationspakete mit unterschiedlichen UIDs nicht installiert werden können, obwohl sie im
Emulator lauffähig sind.
v
Inhaltsverzeichnis
Tabellenverzeichnis
x
Abbildungsverzeichnis
xiii
Quelltextverzeichnis
xv
1. Einleitung
1.1. Motivation . . . . . . . . . . . . . . . . . . . .
1.2. Problem- und Fragestellung der Diplomarbeit
1.3. Aufbau der Diplomarbeit . . . . . . . . . . .
1.4. Schreibkonventionen . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
2. Grundlagen
2.1. Symbian OS . . . . . . . . . . . . . . . . . . .
2.1.1. Entstehung und Marktdurchdringung .
2.1.2. Übersicht . . . . . . . . . . . . . . . .
2.1.3. Unterschiedliche Varianten . . . . . . .
2.1.4. Symbian Versionen . . . . . . . . . . .
2.2. Platform Security Architecture . . . . . . . .
2.2.1. Voraussetzungen . . . . . . . . . . . .
2.2.2. Unit of Trust . . . . . . . . . . . . . .
2.2.3. Capabilities . . . . . . . . . . . . . . .
2.2.4. Data Caging . . . . . . . . . . . . . .
2.2.5. Symbian Signed . . . . . . . . . . . . .
2.2.6. Konzepte hinter der PSA . . . . . . .
2.3. Emulator . . . . . . . . . . . . . . . . . . . .
2.3.1. Übersicht . . . . . . . . . . . . . . . .
2.3.2. Eigenschaften . . . . . . . . . . . . . .
2.3.3. Unterschiede . . . . . . . . . . . . . .
2.4. Programming . . . . . . . . . . . . . . . . . .
2.4.1. SWInstaller . . . . . . . . . . . . . . .
2.4.2. Installationspaket(SIS-Datei) . . . . .
2.4.3. Speicherverwaltung . . . . . . . . . . .
2.4.4. Kernel . . . . . . . . . . . . . . . . . .
2.4.5. Kommunikationsarchitektur . . . . . .
2.4.6. DLL . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
7
8
9
9
9
11
13
15
17
19
19
20
21
23
23
23
26
27
28
30
3. Design und Spezifizierung
3.1. Verifikation der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. Testsystemaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
32
vii
Inhaltsverzeichnis
3.1.2. Testbereiche . . . . . . . . . . . . . .
3.2. Parameter und Konfigurationsmöglichkeiten
3.2.1. SWIPolicy . . . . . . . . . . . . . . .
3.2.2. SWInstaller-Einstellungen . . . . . .
3.2.3. Bedeutung für das Testsystem . . . .
3.3. Erfassung der Vollständigkeit . . . . . . . .
3.3.1. Testbereich . . . . . . . . . . . . . .
3.3.2. Testbarkeit gegen wirklich getestet .
3.4. Mehrdeutigkeiten der Spezifikation . . . . .
4. Testsystem
4.1. Beschreibung der Implementierung . .
4.1.1. File-Logger . . . . . . . . . . .
4.1.2. Testsystem . . . . . . . . . . .
4.2. Beschreibung der Testfälle . . . . . . .
4.2.1. Data Caging . . . . . . . . . .
4.2.2. File Eclipsing . . . . . . . . . .
4.2.3. File Overwriting . . . . . . . .
4.2.4. SWInstaller . . . . . . . . . . .
4.2.5. Certificate . . . . . . . . . . . .
4.2.6. Capabilities . . . . . . . . . . .
4.2.7. Integrity . . . . . . . . . . . . .
4.2.8. Shared-Data . . . . . . . . . . .
4.2.9. IDs . . . . . . . . . . . . . . . .
4.2.10. User-Defined . . . . . . . . . .
4.2.11. API . . . . . . . . . . . . . . .
4.3. Definition/Spezifizierung der Testfälle
4.3.1. Data Caging . . . . . . . . . .
4.3.2. File Eclipsing . . . . . . . . . .
4.3.3. File Overwriting . . . . . . . .
4.3.4. SWInstaller . . . . . . . . . . .
4.3.5. Certificate . . . . . . . . . . . .
4.3.6. Capabilities . . . . . . . . . . .
4.3.7. Integrity . . . . . . . . . . . . .
4.3.8. Shared-Data . . . . . . . . . . .
4.3.9. IDs . . . . . . . . . . . . . . . .
4.3.10. API . . . . . . . . . . . . . . .
5. Ergebnisse und Evaluierung
5.1. Versuchsaufbau . . . . . . . . .
5.1.1. Vorbereitung . . . . . .
5.1.2. Hardware . . . . . . . .
5.1.3. Software . . . . . . . . .
5.2. Marktabbildung der Testgeräte
5.3. Durchführung . . . . . . . . . .
5.3.1. Emulator . . . . . . . .
5.3.2. Testgeräte . . . . . . . .
5.3.3. Schwierigkeiten . . . . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
37
37
38
39
39
39
40
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
46
46
47
48
49
50
50
51
52
53
53
54
55
55
55
56
57
58
58
59
59
60
60
.
.
.
.
.
.
.
.
.
63
63
63
64
65
65
65
65
66
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
5.4. Evaluationskriterien . . . .
5.5. Vorstellung der Ergebnisse .
5.5.1. Data Caging . . . .
5.5.2. File Eclipsing . . . .
5.5.3. File Overwriting . .
5.5.4. SWInstaller . . . . .
5.5.5. Certificate . . . . . .
5.5.6. Capabilities . . . . .
5.5.7. Integrity . . . . . . .
5.5.8. Shared-Data . . . . .
5.5.9. IDs . . . . . . . . . .
5.5.10. API . . . . . . . . .
5.6. Aussagekraft der Ergebnisse
5.6.1. Data Caging . . . .
5.6.2. File Eclipsing . . . .
5.6.3. File Overwriting . .
5.6.4. SWInstaller . . . . .
5.6.5. Certificate . . . . . .
5.6.6. Capabilities . . . . .
5.6.7. Integrity . . . . . . .
5.6.8. Shared-Data . . . . .
5.6.9. IDs . . . . . . . . . .
5.6.10. Emulator . . . . . .
5.7. Fazit der Ergebnisse . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6. Diskussion
6.1. Symbian Signed . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1. Bedeutung und Verantwortung . . . . . . . . . . .
6.1.2. Testkriterien . . . . . . . . . . . . . . . . . . . . .
6.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1. Verantwortung für das Gewähren von Capabilities
6.2.2. Verteilung der Capabilities . . . . . . . . . . . . . .
6.3. SWIPolicy . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4. SWInstaller . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
. 93
. 93
. 94
. 96
. 96
. 97
. 98
. 100
.
.
.
.
.
.
.
.
.
.
.
.
103
103
103
104
104
105
105
105
106
107
107
108
110
7. Privilegien von Software erhöhen
7.1. Beschreibung . . . . . . . . . . . . . . . . .
7.1.1. SWIPolicy modifizieren . . . . . . .
7.1.2. Capabilities zur Laufzeit ausschalten
7.1.3. Root-Zertifikat . . . . . . . . . . . .
7.1.4. ROM-Patcher . . . . . . . . . . . . .
7.1.5. HelloCarbide . . . . . . . . . . . . .
7.2. Gefahrenpotential . . . . . . . . . . . . . . .
7.3. Maßnahmen gegen diese Methoden . . . . .
7.4. Sandbox auf Symbian OS Version 9 . . . . .
7.4.1. Symbian Dateiformat . . . . . . . .
7.4.2. Loader Server . . . . . . . . . . . . .
7.4.3. Übertragbarkeit der MobileSandbox
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
69
70
72
74
76
78
79
82
84
85
87
87
87
87
88
88
89
89
90
90
91
91
91
ix
Inhaltsverzeichnis
8. Fazit und Ausblick
8.1. Offenheit von Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113
113
114
115
Anhang
117
A. Testsystem
A.1. Definition der Testfälle . . . . . . . . . . . . . . .
A.2. Regeln und Hinweise für die Konfigurationsdatei
A.3. Test SWIPolicies . . . . . . . . . . . . . . . . . .
A.3.1. SWInstaller . . . . . . . . . . . . . . . . .
A.3.2. Certificate . . . . . . . . . . . . . . . . . .
.
.
.
.
.
118
119
143
144
144
145
B. CD-Inhalt
B.1. Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2. Testsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3. Privilegien erhöhen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
147
147
147
148
Literaturverzeichnis
149
x
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
User Capabilities . . . . . . . . .
System Capabilities . . . . . . . .
Device Manufacturer Capabilities
Capability-Regeln . . . . . . . . .
Data-Caging-Zugangsregeln . . .
Aufteilung der UID-Bereiche [1] .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
13
14
14
15
25
5.1. Testgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Installations- und Deinstallationsdauer . . . . . . . . . . . . . . . . . . . . . .
64
68
xi
Abbildungsverzeichnis
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Absatzübersicht weltweit . . . . .
Symbian OS Übersicht [2] . . . .
Trusted Computing Platform [1]
Symbian Signed Prozess [3] . . .
Emulator Übersicht [2] . . . . . .
Virtuelle Speicherabbildung . . .
Publish & Subscribe Übersicht [2]
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
10
16
20
27
30
3.1. Testsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Vollständiges PSA-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
40
4.1. Definition der Capability-Regeln . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.1. Verteilung von Symbian v9 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Ergebnisse DLL-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
80
6.1. Symbian Logo für Symbian Signed Anwendungen . . . . . . . . . . . . . . . .
6.2. Symbian Signed Testkriterien [4] . . . . . . . . . . . . . . . . . . . . . . . . .
94
95
7.1. Anfrage an den Loader Server [2] . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2. Vervollständigung der Anfrage [2] . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3. MobileSandbox IAT Patching [5] . . . . . . . . . . . . . . . . . . . . . . . . . 111
xiii
Quelltextverzeichnis
4.1. Beispiel
4.2. Beispiel
4.3. Beispiel
4.4. Beispiel
4.5. Beispiel
4.6. Beispiel
4.7. Beispiel
4.8. Beispiel
4.9. Beispiel
4.10. Beispiel
4.11. Beispiel
für einen Data-Caging-Testfall
File Eclipsing . . . . . . . . .
File Overwriting . . . . . . . .
SWInstaller . . . . . . . . . .
Certificate . . . . . . . . . . .
Capabilities . . . . . . . . . .
Integrity . . . . . . . . . . . .
Shared-Data . . . . . . . . . .
IDs . . . . . . . . . . . . . . .
User-Defined . . . . . . . . . .
API . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
47
48
49
50
51
52
52
53
54
54
6.1. Konfiguration der SWIPolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
xv
1. Einleitung
Im ersten Kapitel dieser Diplomarbeit soll ein grober Überblick der gesamten Arbeit vermittelt werden. Dazu motiviert der erste Abschnitt das Thema, um im nächsten Abschnitt die
Problem- und Fragestellung der vorliegenden Arbeit zu erläutern. In den beiden abschließenden Abschnitten werden der Aufbau und die Schreibkonventionen der gesamten Diplomarbeit
beschrieben.
1.1. Motivation
In der heutigen Zeit sind Mobiltelefone in unserem Leben nicht mehr wegzudenken. Neben
Mobiltelefonen, die nur zum Telefonieren entwickelt wurden, erfreuen sich so genannte Smartphones einer immer größer werdenden Beliebtheit. Die heutigen Smartphones kombinieren das
Mobiltelefon mit verschiedenen Technologien aus dem Kommunikations- und Multimediabereich und stellen diese Funktionalität in den meisten Fällen durch ein offenes Betriebssystem
zur Verfügung. Dabei unterstützen die meisten Smartphones Verbindungsmöglichkeiten über
3G/UMTS, 2.5G (EDGE und GPRS), WiFi (802.11b) sowie Bluetooth und Infrarot. Die neusten Modelle überbieten sich mit den jeweiligen Ausstattungsmerkmalen wie zum Beispiel einer
8-Mega-Pixel-Kamera, integriertem GPS-Empfänger, FM-Transmitter oder DVB-H/T. Diese
Vielzahl an Ausstattungsmerkmalen und der Möglichkeit, weitere Software auf diesen Smartphones zu installieren, weckt nicht nur das Interesse bei den Entwicklern, sondern auch bei
potentiellen Angreifern. Durch die verschiedenen Verbindungsmöglichkeiten, die ein heutiges
Smartphone bietet, können immer und überall Daten ausgetauscht oder zusätzliche Anwendungen installiert werden. Damit die privaten Daten (beispielsweise Kontakte, Nachrichten,
Notizen oder Bilder) nicht ungehindert an potentielle Angreifer gelangen können oder die
Integrität des Mobiltelefons nicht beeinträchtigt wird, existieren teilweise Sicherheitsmechanismen, die das verhindern sollen.
Symbian stellte mit der Einführung ihres Betriebssystems in der Version 9 eine neue Sicherheitsarchitektur vor. Die „Platform Security Architecture“ sollte dabei die Offenheit von
Symbian OS bewahren und gleichzeitig ausreichenden Schutz vor bösartigen Anwendungen
bieten. Jedoch ist jede neue Technologie von Mängeln oder sonstigen Unzulänglichkeiten bei
ihrer Einführung begleitet. Es kann also durchaus in der ersten Version der „Platform Security
Architecture“ vorkommen, dass nicht alle spezifizierten Sicherheitsmerkmale tatsächlich ihre
Funktionsweise gewährleisten. Hierbei könnten verschiedene Symbian Version 9 Mobiltelefone zu unterschiedlichen Verhaltensweisen führen, da unter Umständen die Konfigurationsparameter der Plattform noch nicht ausreichend für die jeweiligen Anforderungen eingestellt
wurden.
1
1. Einleitung
1.2. Problem- und Fragestellung der Diplomarbeit
Mit Einführung der Version 9 von Symbian OS und der damit verbundenen neuen Sicherheitsarchitektur „Platform Security Architecture (PSA)“ hat Symbian nicht nur die Offenheit des
Betriebssystems gewahrt, sondern auch viele bekannte Sicherheitskonzepte aus dem DesktopBereich mit der „PSA“ in Symbian OS eingeführt. Eine neue Sicherheitsarchitektur birgt in
der Einführungsphase immer Risiken und anfängliche Fehler.
Das Hauptziel der Diplomarbeit ist zunächst die Verifikation der Konfiguration der „PSA“.
Dadurch sollte die richtige und spezifizierte Funktionsweise der „PSA“ festgestellt werden.
Damit jedoch die Konfiguration der „PSA“ verifiziert werden kann, müssen die Einstellungsmöglichkeiten erarbeitet werden. Aus diesen Einstellungen können anschließend die Konfigurationsparameter für die „PSA“ abgeleitet werden. Mit diesen Konfigurationsparametern
können die Möglichkeiten zur Konfiguration der „PSA“ gefunden und so sinnvolle Konfigurationen gebildet werden, die dabei helfen sollen die Plattform zu verifizieren. Damit jedoch die
Konfigurationsparameter genutzt werden können um die Funktionalität der „PSA“ zu verifizieren, muss ein entsprechendes Testsystem implementiert werden. Das Testsystem soll dabei
möglichst alle Komponenten der „PSA“ umfassen, damit auch eine möglichst vollständige Analyse der „PSA“ möglich ist. An das Testsystem werden zusätzlich noch zwei Anforderungen
gestellt. Zunächst sollte es mit möglichst wenig Redundanz geschrieben werden. Die zweite
Anforderung richtet sich an die Testfälle, die nur durch die Definition der jeweiligen Tests
automatisch generiert werden sollen. Hierfür sollte das Testsystem eine Konfigurationsdatei
bereitstellen, mit deren Hilfe das Testsystem automatisch Testfälle generieren sollte. Insgesamt soll das Testsystem so flexibel implementiert sein, dass verschiedene Mobiltelefone mit
Symbian Version 9 untersucht, miteinander verglichen und ausgewertet werden können.
1.3. Aufbau der Diplomarbeit
Die Diplomarbeit ist insgesamt in acht Kapitel und einen anschließenden Anhang unterteilt.
In den Grundlagen wird das Wissen vermittelt, das zum Verständnis der darauf folgenden Kapitel benötigt wird. Nach den Grundlagen werden zuerst das Design des Testsystems und die
Parameter sowie Konfigurationsmöglichkeiten, die die Symbian OS „Platform Security Architecture“ bereitstellt, beschrieben. Im nächsten Schritt folgt die Beschreibung der Implementierung des Testsystems sowie der einzelnen Testfälle, die das Testsystem für die Verifikation
der Konfiguration der „PSA“ bereithält. Der letzte Abschnitt in diesem Kapitel schildert die
Definition der jeweiligen Testfälle. Nachdem das Testsystem im dritten Kapitel spezifiziert
und im vierten Kapitel die Implementierung des Testsystems beschrieben wurde, folgen im
fünften Kapitel die Ergebnisse und die Evaluierung dieser. Das darauf folgende Kapitel diskutiert die wesentlichen Bezugspunkte von Symbian OS und deren Bedeutung. Im nächsten
Kapitel werden die Methoden beschrieben, wie Privilegien von Symbian OS Anwendungen
erhöht werden können und welches Gefahrenpotential von diesen Methoden ausgeht. Darüber
hinaus werden die bisherigen Maßnahmen der Mobiltelefonhersteller gegen diese Methoden
erläutert. Der abschließende Teil dieses Abschnitts beschreibt die Möglichkeit, die „MobileSandbox“ auf Symbian OS Version 9 zu übertragen. Das letzte Kapitel zieht ein Fazit dieser
2
1.4. Schreibkonventionen
Diplomarbeit und gibt einen Ausblick auf mögliche Themen, die aufbauend auf dieser Arbeit weiter bearbeitet werden könnten. Dabei wird auch rückblickend auf die Offenheit von
Symbian OS eingegangen.
Im Anhang sind zunächst die Definitionen der Testfälle und die Regeln, die bei der Definition
beachtet werden müssen, aufgeführt. Zusätzlich sind noch die verwendeten SWIPolicies für
die SWInstaller-Tests enthalten. Der abschließende Punkt im Anhang beschreibt den Inhalt
der beigefügten CD.
1.4. Schreibkonventionen
Aufgrund der zahlreichen englischen Ausdrücke in dieser Diplomarbeit und ihrer Verwendung zusammen mit deutschen Ausdrücken soll hier kurz ihre Schreibweise dargelegt werden.
Darüber hinaus beschreibt der Anschnitt auch die allgemeinen Schreibkonventionen dieser
Diplomarbeit. Die nachfolgende Darstellung gibt eine Übersicht der verwendeten Konventionen:
• Ein kursiv dargestellter Ausdruck stellt eine Definition des Ausdrucks dar und wird
anschließend in normaler Schreibweise genutzt.
• Der Schreibmaschinenschrift-Stil eines Ausdrucks symbolisiert dabei die Herkunft des
Ausdrucks aus einer Text- oder Quelltext-Datei.
• Fett dargestellte Ausdrücke stellen in den meisten Fällen eine Hervorhebung des Ausdrucks dar.
• Deutsche Ausdrücke in Anführungszeichen dienen in den meisten Fällen der Hervorhebung des Ausdrucks, wohingegen englische Ausdrücke in Anführungszeichen neue Begrifflichkeiten aus dem englischen Kontext einführen.
• Ausdrücke in Anführungszeichen, durch einen Bindestrich mit anderen Ausdrücken zusammengefügt, beschreiben in den meisten Fällen die Verbindung aus zwei englischen
Begriffen, die in Verbindung mit einem deutschen Begriff nicht durch Bindestriche zusammengeschrieben werden können, sodass die erste genannte Methode den Lesefluss
nicht behindert.
• Zusammengesetzte Ausdrücke mit Bindestrichen aus mehreren Ausdrücken werden verwendet, wenn beispielsweise zwei Begriffe nicht als ein Wort geschrieben werden können,
von der Bedeutung her jedoch zusammengehören.
3
2. Grundlagen
Dieses Kapitel soll die Grundlagen vermitteln, die zum Verständnis dieser Diplomarbeit benötigt werden. Dabei werden neben einer kurzen Einführung in Symbian OS die Eigenschaften
und Merkmale der PSA vorgestellt. Anschließend wird der Symbian OS Emulator eingeführt
und eine kurze Übersicht der Symbian Programmier-Konzepte gegeben.
2.1. Symbian OS
Im ersten Abschnitt der Grundlagen wird Symbian OS kurz vorgestellt. Dabei wird zunächst
die Entstehung und die aktuelle Marktdurchdringung von Symbian OS beschrieben. Anschließend werden neben einer Übersicht die verschiedenen Varianten und Versionen von Symbian
OS präsentiert.
2.1.1. Entstehung und Marktdurchdringung
Die Entstehung von Symbian OS kann in die frühen Achtzigerjahre zu einem SoftwareEntwicklungsunternehmen namens Psion zurückverfolgt werden. Die damaligen Pioniere im
Handheld-Computer-Markt entwickelten nach mehreren erfolgreichen Generationen ihrer Software für Handheld-Geräte ein objektorientiertes Betriebssystem, das EPOC genannt wurde.
EPOC wurde speziell für die besonderen Bedürfnisse mobiler Computer entworfen. Psion erkannte die damalige Nachfrage nach einem mobilen Betriebssystem, das andere Hersteller
für ihre mobilen Produkte hätten lizenzieren können. Ihr EPOC-Betriebssystem schien diese Nachfrage zu erfüllen, sodass viele Mobiltelefonhersteller an EPOC interessiert waren. Im
Juni 1998 entstand schließlich Symbian als gemeinsames Unternehmen der damaligen großen
Mobiltelefonhersteller(Nokia, Ericsson und Motorola) und Psion. In der heutigen Zeit ist Symbian‘s Betriebssystem, besser bekannt als Symbian OS, das dominierende Betriebssystem im
Mobiltelefonmarkt. Eine aktuelle Marktanalyse von Canalys [6] verdeutlicht diese Aussage
und ist in Abbildung 2.1 noch einmal grafisch dargestellt.
2.1.2. Übersicht
Symbian OS wurde von Grund auf für mobile Kommunikationsgeräte geschaffen. Während
andere Betriebssysteme, zum Beispiel Microsoft Windows Mobile für Smartphones, aus bestehenden Betriebssystemen hervorgegangen sind, entstand Symbian OS aus den entgegengesetzten Ansatz. Die frühere Version EPOC beispielsweise, könnte auf Geräten mit weniger als
zwei Megabyte Speicher ausgeführt werden.
5
2. Grundlagen
Abbildung 2.1.: Absatzübersicht weltweit
Symbian OS und der aktuelle Kernel EKA2 (EPOC Kernel Architecture 2 ) sind modular. Die
Betriebssystemfunktionalität wird durch unterschiedliche Bausteine bereitgestellt und nicht
durch eine monolithische Einheit. Beispielsweise werden Dateizugriffe durch einen „File Server“ ausgeführt, während Benutzereingaben und Bildschirmausgaben vom „Window Server“
verarbeitet beziehungsweise dargestellt werden. Abbildung 2.2 verdeutlicht die Modularität
und den Aufbau.
Symbian OS ist ein Single-User-Betriebssystem. Es gibt kein Konzept, das es mehreren
Benutzern ermöglicht, sich auf dem System einzuloggen, wie es zum Beispiel bei Linux oder
Windows der Fall ist.
Symbian OS ist ein Multitasking-Betriebssystem, das die CPU-Zeit den einzelnen Threads
zuteilt. Auf diese Art entsteht beim Benutzer der Eindruck, dass mehrere Anwendungen gleichzeitig ausgeführt werden.
Symbian OS ist ein präemptives Multitasking-Betriebssystem. Der Kernel verlässt sich nicht
darauf, dass ein Thread seine CPU-Zeit von sich aus einem anderen Thread überlässt, sondern
teilt die CPU-Zeit zwangsläufig einem anderen Thread zu.
Symbian OS ist ein prioritätsbasiertes Multitasking-Betriebssystem mit Prioritätsvererbung.
Symbian OS ist ein Echtzeit-Betriebssystem, sodass seine Dienste innerhalb eines bestimmten
Zeitintervalls ausgeführt werden.
Symbian OS kann ROM-basiert sein und eignet sich für offene, leistungsbeschränkte
Umgebungen.
6
2.1. Symbian OS
Abbildung 2.2.: Symbian OS Übersicht [2]
2.1.3. Unterschiedliche Varianten
Es ist schwierig, ein Betriebssystem zu entwickeln, das gemeinsame Kernfähigkeiten besitzt
und auf der anderen Seite eine einheitliche Programmierumgebung für alle Smartphones aufweist. Heutige Smartphones existieren in unterschiedlichen Größen, Formen, Bildschirmgrößen und Eingabemöglichkeiten. Damit die Benutzerschnittstelle diesen Bedürfnissen gerecht
werden kann, muss die sich den jeweiligen Gegebenheiten anpassen. Aus diesem Grund besitzt Symbian eine flexible Architektur, die es den unterschiedlichen Benutzerschnittstellen
erlaubt, auf der Kernfunktionalität von Symbian OS aufzusetzen. Um nun den Mobiltelefonherstellern einen Startpunkt zu geben, entwickelte Symbian einige Referenzplattformen. Diese
Referenzplattformen beinhalten die Symbian OS Kernfunktionalität zusammen mit einer Benutzerschnittstelle, die einen Basis-Smartphone-Typ einer Baugruppe (Bildschirmgröße und
Eingabemöglichkeiten) repräsentiert. Zwei dieser Referenzplattformen sind als Beispiel aufgeführt.
• Nokia S60
Diese auch als „Series 60“ bekannte Version existiert schon in der dritten Version seit
2001. Ihre Hauptmerkmale zeichnen sich durch beschränkte Eingabemöglichkeiten, ein
nummerisches Tastenfeld zur Texteingabe und eine geringe Bildschirmgröße (typisch
240x320 Bildpunkte) aus.
• UIQ
Diese Plattform wird von UIQ Technology lizenziert, entwickelt und gewartet. UIQ ist
im Gegensatz zur S60 für stiftbasierte (zum Beispiel Touchscreens) Smartphones ent-
7
2. Grundlagen
wickelt worden. Mobile Geräte, die auf dieser Plattform aufbauen, besitzen meistens
keine Tastatur. Dieser Nachteil wird aber durch eine virtuelle Tastatur und Handschrifterkennung ausgeglichen. Die Bildschirmgröße variiert zwischen den Modellen, 240x320
Bildpunkte sind jedoch auch hier typisch.
2.1.4. Symbian Versionen
Symbian OS Version 9
Mit der Symbian Version 9 führte Symbian zahlreiche Verbesserungen und Neuerungen ein.
Es ist nicht nur eine neue Version des Betriebssystems, sondern dieser Versionssprung brachte
viele Neuerungen wie eine „Platform Security“, einen Echtzeit-Kernel und neue Entwicklerwerkzeuge. Durch all diese Neuerungen sind frühere Symbian-Anwendungen nicht mit der
aktuellen Version 9 kompatibel. Da Symbian seine Betriebssystem-Software ständig verbessert, sind bereits zwei Versionssprünge zu verzeichnen, die hier kurz dargestellt werden.
• v9.1:
Version 9.1 stellt die erste Iteration der neuen Symbian OS Generation dar und hatte
somit auch viele Neuerungen vorzuweisen. Symbian OS v9.1 ist auf dem Echtzeit-Kernel
EKA2 aufgebaut. Der alte Kernel (EKA1) ist nicht mehr verfügbar. Die einzelnen Neuerungen sind generische „File Server Hooks“, Bluetooth Stereo-Headset Unterstützung,
RTP (Realtime Transport Protocol), generisches QoS, OMA Standards wie „OMA Data
Dynchronisation 1.1“, „OMA Device Management v1.1.2“ und „OMA Client Provisioning
v1.2“. Aber auch neue APIs zu neuen Diensten wie „Publish & Subscribe“, „Message
Queues“, „Shared Buffer I/O“ und ein neuer sicherer „SendAs Server“ sind hinzugekommen. Die Grafik-APIs und Benutzerschnittstellen wurden ebenfalls überarbeitet. Die
„MIDP Java 2.0“ Plattform wurde vollständig in Symbian OS v9.1 integriert.
• v9.2:
Verbesserungen, die seit der Version 9.1 vorgestellt wurden, enthalten Grafik- und Multimediaverbesserungen durch zusätzliche Eingabedatentypen wie das YUV- und YCbCrModell, sowie Verbesserungen in der Kamera-API. Symbian OS v9.2 unterstützt nun
auch die ARMv6-Architektur und neue IP-Telefonie sowie Netzwerkprotokolle wie RTCP, SIP und SDP. Ein weitere Neuerung ist die Einführung von OCSP-basiertem Widerruf von Anwendungen. Das „Device Management“ wurde aktualisiert zu „OMA Data
Synchronisation 1.2“. Die Benutzerschnittstelle wurde verbessert und unterstützt nun
SVGA-Icons. Weitere Sprachunterstützungen wie Vietnamesisch und Hindi ist hinzugekommen.
• v9.3:
Die Version 9.3 brachte für den Entwickler weniger interessante Neuerungen, verglichen
mit früheren Versionen, mit. Diese Version ist primär auf den Gerätehersteller ausgerichtet. Die einzelnen Verbesserungen seit Version 9.2 umfassen IP-Telefonie, insbesondere
Unterstützung für „3GPP R5“, „Short Link“, „PIM“ und Datentransfer. Zusätzlich wurde
der Low-Level-Code verbessert und neue Hardware-Unterstützung hinzugefügt.
8
2.2. Platform Security Architecture
In diesem Abschnitt werden die Grundlagen der PSA vorgestellt. Dazu werden zunächst die
Voraussetzungen für den Einsatz von Symbian OS Version 9 beschrieben, um anschließend die
PSA-Konzepte „Unit of Trust“, „Capabilities“ und „Data Caging“ zu präsentieren. Symbian
Signed und die jeweiligen Konzepte hinter der PSA werden in den abschließenden Teilen
erklärt.
2.2.1. Voraussetzungen
Damit Symbian OS Version 9 auf einem Mobiltelefon eingesetzt werden kann, müssen bestimmte Voraussetzungen gegeben sein. Symbian OS benötigt einen 32-Bit-Mikroprozessor,
der im Vergleich zum Energiebedarf, eine hohe Rechenleistung bietet. Die Byte-Anordnung
sollte „Little Endian“ sein und die CPU zudem „Interrupts“ und „Exceptions“ unterstützen.
Des Weiteren sollte die CPU einen „User Mode“ und einen „Supervisor Mode“ bereitstellen.
Typische Taktungen bei aktuellen Mobiltelefonen mit Symbian OS sind 100 - 200 MHz, aber
es werden schon teilweise Geschwindigkeiten von 300 - 400 MHz benötigt.
Die ARM-CPUs erfüllt genau alle oben genannten Voraussetzungen, sodass fast alle Smartphones mit einem ARM-Prozessor ausgestattet sind. ARM verwendet für ihre CPUs die RISCArchitektur und das schon seit ca. 20 Jahren. Aufgrund der Verbreitung der ARM-CPUs,
benötigt Symbian den ARMv5TE-Instruktionssatz oder besser. Eine weitere sehr wichtige
Anforderung ist die „Memory Management Unit“ (MMU), die die Virtualisierung des Speichers erlaubt.
2.2.2. Unit of Trust
Es gibt drei Konzepte, die die Basis der Symbian OS Platform Security darstellen. Der erste
Abschnitt beschäftigt sich mit der Frage, was die Unit of Trust ist. Oder mit anderen Worten, was ist die kleinste Einheit, über die Symbian OS eine Entscheidung hinsichtlich seiner
Vertrauenswürdigkeit treffen kann.
Das Sicherheitssystem braucht die Vertrauenswürdigkeit des Benutzers nicht in Frage zu stellen. Wenn der Benutzer in der Lage, ist das Mobiltelefon zu benutzen, so ist er auch implizit
autorisiert, das zu tun. Symbian sollte jedoch die Vertrauenswürdigkeit der Prozesse, die auf
dem Gerät ausgeführt werden, in Frage stellen. Denn abhängig vom Verhalten des Benutzers
kann dieser zusätzliche Anwendungen installieren, die dann beispielsweise die Funktionen des
Mobiltelefons beeinträchtigen können. Symbians Platform Security Architecture wurde entwickelt, um zu kontrollieren, was ein Prozess tun kann. Ein Prozess kann nur dann seine
Funktionen ausführen, wenn er für diese Funktionen die entsprechenden Privilegien besitzt.
Besitzt ein Prozess nicht die benötigen Privilegien, verweigert Symbian OS die Ausführung
der Funktionen aus dem Grund, dass der Prozess als nicht vertrauenswürdig genug eingestuft
wird.
In Symbian OS besitz ein Prozess mindestens einen Ausführungsthread und seine Ressourcen,
die in physischen Speicherblocks von der MMU in der Hardware verwaltet werden. Der Prozess bildet die Einheit auf der der Speicherschutz auf Hardwareebene angewendet wird. Die
9
2. Grundlagen
Hardware löst einen Prozessorfehler aus, wenn der Prozess versucht, auf einen Adressbereich
zuzugreifen, der nicht in seinem virtuellen Adressbereich liegt. Dieser durch Hardware unterstützte Speicherschutz bildet die Basis des Software-Sicherheitssystems. Symbian OS kann
einem Prozess vertrauen, nicht direkt auf einen anderen virtuellen Adressbereich zuzugreifen.
Die Hardware würde das nicht zu lassen.
Symbian OS stellt eine Trusted Computing Plattform dar. Diese besteht aus der „Trusted
Computing Base (TCB)“, der „Trusted Computing Environment (TCE)“, anderer signierter
Software und dem Rest der Plattform. Grob können die laufenden Prozesse in Symbian OS
in vier Schichten aufgeteilt werden, von komplett vertrauenswürdig bis überhaupt nicht vertrauenswürdig. Abbildung 2.3 verdeutlicht diesen Zusammenhang. Beispielsweise ist Software,
Abbildung 2.3.: Trusted Computing Platform [1]
die sich auf einen schreibgeschützten Speichermedium (typischerweise im ROM) befindet, als
vertrauenswürdig eingestuft, wohingegen zusätzliche Software anhand ihrer digitalen Signatur
beurteilt wird.
TCB
Die Trusted Computing Base oder TCB ist der vertrauenswürdigster Teil von Symbian OS.
Er stellt die niedrigsten Sicherheitsmechanismen zur Verfügung und ist außerdem für die Integrität des gesamten Systems verantwortlich. Die TCB wurde von ihrem Umfang so klein wie
möglich gehalten, sodass nur der „System Kernel“, der „File Server (F32)“ und der „SWInstaller“ (siehe Gliederungspunkt 2.4.1) mit den höchsten Privilegien ausgestattet werden mussten.
Der Kernel verwaltet die Prozesse und die ihnen zugewiesenen Privilegien. Um Prozesse zu
erstellen, muss der „File Server“ den Programmcode des entsprechenden Prozesses laden, sodass der „File Server“ auch in der TCB-Schicht enthalten sein muss. Die Komponenten der
TCB-Schicht wurden sorgfältig geprüft um sicherzustellen, dass sie sich richtig verhalten und
somit auch als vollkommen vertrauenswürdig bezeichnet werden können.
10
TCE
Die Trusted Computing Evironment oder TCE besteht aus weiterer vertrauenswürdiger Software von Symbian OS, aber auch von den UI-Plattform Anbietern und den Mobiltelefonherstellern. Dieser Teil der Trusted Computing Platfrom wird immer noch als vertrauenswürdig
angesehen, muss aber nicht mit den höchsten Privilegien ausgeführt werden. Dies führt dazu,
dass der TCE Code etwas weniger vertrauenswürdig als der TCB Code ist. Der TCE-Code
implementiert meistens einen „System Server“-Prozess, der die Integrität des gesamten Systems nicht beeinträchtigen kann. Bei einem Fehler des Servers kann der Kernel den Server neu
starten und den alten Zustand wieder herstellen.
Signierte Software
Mit Hilfe von signierter Software es ist möglich, Komponenten in der TCB oder TCE hinzuzufügen und zu modifizieren. Jedoch nur, wenn die Software durch eine vertrauenswürdige
Zertifizierungsstelle signiert wurde und es dieser Zertifizierungsstelle auch erlaubt ist, die benötigten Privilegien zu gewähren. Signierte Software außerhalb der TCE ist deshalb weniger
vertrauenswürdig als Software innerhalb der TCE.
Unsignierte Software
Bei nicht signierter oder in der Tat signierter Software, die nicht durch eine der vertrauenswürdigen Zertifizierungsstellen signiert wurde, hat das System keine Basis, um die Vertrauenswürdigkeit zu bestimmen. Deshalb wird die Software als nicht vertrauenswürdig behandelt.
Das bedeutet nicht, dass unsignierte Software schlecht oder böse ist, sondern lediglich dass die
Operationen keine Privilegien benötigen und somit keine sicherheitskritischen Konsequenzen
für das System haben.
2.2.3. Capabilities
Das zweite Konzept, das die Symbian Platform Security Architecture untermauert, ist das
Privilegienmodell.
A token [is] usually an unforgeable data value (sometime called a ’ticket’) that
gives the bearer or holder the right to access a system resource. Possesion of the
token is accepted by a system as proof that the holder has been authorized to
access the resource named or indicated by the token. [7]
Eine Capability ist ein Token, das vorhanden sein muss, um Zugang zu System Ressourcen zu
erhalten. System Ressourcen sind in Symbian OS Dienste, die über APIs zur Verfügung gestellt
werden. Unterschiedliche APIs können unterschiedliche Capabilities benötigen, um Zugang zu
beschränkten Diensten zu erhalten. Besitzt ein Prozess die entsprechende Capability, wird er
als vertrauenswürdig angesehen, die Ressourcen, die durch die Capability geschützt werden,
nicht zu missbrauchen. In den vorherigen Abschnitten habe ich das Wort Privilegien benutzt,
um Software zu beschreiben, die zur Ausführung von sensiblen Funktionen autorisiert sein
musste, das auch tun zu dürfen.
11
2. Grundlagen
Capability
LocalServices
Location
NetworkServices
ReadUserData
UserEnvironment
WriteUserData
Tabelle 2.1.: User Capabilities
Gewährte Privilegien
Zugang zu Kurzstreckenverbindungen wie Bluetooth
oder Infrarot. Hierbei sollten keine Kosten entstehen.
Zugang zu standortbezogenen Daten des Telefons.
Zugang
zu
Remote-Diensten
(z.B.
WiFiNetzwerkzugang). Diese Dienste können Kosten
verursachen.
Lesezugang zu vertraulichen Benutzerdaten.
Zugang zu aktuellen Daten des Benutzers und seiner
unmittelbarer Umgebung.
Schreibzugang zu vertraulichen Benutzerdaten.
Platform Security Architecture ist um Capabilities herum gebaut worden, um diese Zugangsprivilegien zu repräsentieren. Ausführbare Dateien in Symbian OS können dabei eine, keine
oder eine Ansammlung von Capabilities besitzen.
Symbian OS definiert insgesamt 20 Capabilities, die mit unterschiedlichen Privilegien ausgestattet sind. Grob können die Capabilities in drei Kategorien unterteilt werden: „User Capabilities“, „System Capabilities“ und „Device Manufacturer Capabilities“. User Capabilities
(Tabelle 2.1) bezeichnen eine kleine Gruppe Capabilities, die für den Mobiltelefonbenutzer bedeutungsvoll sind. Insbesondere schützen die Capabilities die Ressourcen, von denen ausgegangen werden kann, dass der Benutzer sie versteht und sie ihm etwas bedeuten. Auf Grundlage
dieser Informationen ist es auch sinnvoll, dem Benutzer die Entscheidung über das Gewähren dieser Capabilities zu überlassen. System Capabilities (Tabelle 2.2) sind auf der anderen
Seite für den Benutzer weniger aussagekräftig, da diese Capabilities Ressourcen umfassen, die
die Integrität des Gerätes oder sogar des Mobilfunknetzes beeinflussen. Device Manufacturer
Capabilities (Tabelle 2.3) stellen die sensibelsten Capabilities dar, die das System gewähren
kann.
Capabilities sind diskret und orthogonal. Das bedeutet, es gibt keine hierarchische Menge der
Capabilities. Ein Prozess kann somit nicht die TCB Capability erreichen oder irgendeine andere Capability, indem alle anderen Capabilities dem Prozess hinzugefügt werden, bis schließlich
die Ebene der TCB Capability erreicht wird. Stattdessen wird jede geschützte Ressource durch
nur eine spezielle Capability geschützt. Jeder Prozess, der diese Ressource benutzen will, muss
die entsprechende Capability besitzen, auch TCB-Prozesse.
Wenn der Kernel einen Prozess erstellt, liest er die Capabilities aus dem Header der Programmdatei und assoziiert diese Capabilities mit dem Prozess für den Rest seiner Lebensdauer. Der
Kernel legt die Capabilities im Speicher ab, der für User-Mode-Prozesse nicht zugänglich ist.
Zusätzlich stellt der Kernel benutzerseitige APIs zur Verfügung. Diese APIs erlauben benutzerseitigem Code, einen Prozess, der einen Dienst anfordert, zu prüfen, ob er die entsprechende
Menge an Capabilities bereitstellt.
Nachdem eine Anwendung erfolgreich installiert wurde oder bereits im ROM vorhanden war,
kann Symbian OS annehmen, dass die Anwendung hinreichend vertrauenswürdig ist, die deklarierten Capabilities der Anwendung auch zu gewähren. Für eine EXE bedeutet es, dass
der entsprechende Prozess mit den deklarierten Privilegien ausgeführt wird. Im Gegensatz
12
Capability
CommDD
DiskAdmin
MultimediaDD
NetworkControl
PowerMgmt
ProtServ
ReadDeviceData
SurroundingsDD
SwEvent
TrustedUI
WriteDeviceData
Tabelle 2.2.: System Capabilities
Direkter Zugang zu allen Kommunikationsgerätetreibern.
Zugang zu den administriven Operationen des Dateisystems.
Zugang zu den kritischen Multimediafunktionen, die
Zugang zu verknüpften Gerätetreibern gewähren.
Fähigkeit, Netzwerkprotokolle zu kontrollieren.
Fähigkeit, Prozesse zu beenden, unbenutzte Peripheriegeräte auszuschalten und das Gerät selbst in Standby zu versetzen oder auszuschalten.
Erlaubt einem Serverprozess, sich mit einem geschützten Namen zu registrieren.
Lesezugang
zu
vertraulichen
Telefonnetz-,
Mobiltelefonhersteller- und Geräteeinstellungen.
Zugang zu logischen Gerätetreibern, die Informationen über das Umfeld des Mobiltelefons preisgeben, z.B.
GPS.
Fähigkeit, gedrückte Tasten zu simulieren und TastenEvents von allen anderen Programmen zu erfassen.
Fähigkeit, vertrauenswürdige UI-Sessions zu erstellen.
Schreibzugang zu Einstellungen, die das Verhalten des
Gerätes kontrollieren.
dazu geben die deklarierten Capabilities innerhalb einer DLL nur den Grad ihrer Vertrauenswürdigkeit an. Eine DLL kann in einen anderen Prozess mit weniger Capabilities geladen
werden. Somit kann eine DLL nicht annehmen, dass sie mit den gleichen Capabilities ausgeführt wird, wie sie in ihr definiert wurden, wohingegen eine EXE das sehr wohl annehmen
kann. Daraus folgt die erste Capability-Regel (Tabelle 2.4). Wurden die Capabilities für einen
Prozess schon durch den Kernel bestimmt, so ändern sich die Capabilities nie bis der Prozess
beendet wird. Wenn ein Prozess eine DLL lädt, wird weder seine Capability-Menge verkleinert
noch vergrößert. Das Laden der DLL wird jedoch misslingen, wenn die DLL nicht die Obermenge (oder zumindest die gleiche Menge) der Capabilities des ladenden Prozesses enthält
(Capability-Regel 2).
2.2.4. Data Caging
Das dritte Konzept der Platform Securtiy Architecture ist das Zugangskontrollmodell. Der
Abschnitt gibt eine kurze Übersicht, wie die Integrität und Vertraulichkeit der gespeicherten
Dateien bewahrt wird.
Data Caging wird benutzt, um wichtige Dateien zu schützen. Das können sowohl Systemals auch Benutzerdateien sein. Das System muss sicherstellen, dass der Programmcode nicht
13
2. Grundlagen
Capability
TCB
AllFiles
DRM
Tabelle 2.3.: Device Manufacturer Capabilities
Schreibzugang zu ausführbaren Dateien und zum
\resource Verzeichnis.
Lesezugang zum gesamten Dateisystem und Schreibzugang zu den \private Verzeichnissen der anderen
Prozesse.
Zugang zu DRM-geschütztem Inhalt.
Tabelle 2.4.: Capability-Regeln
Regel 1: Jeder Prozess hat eine Menge an Capabilities (definiert durch seine EXE) und
diese Capabilities ändern sich nie während seiner Lebensdauer.
Regel 2: Ein Prozess kann nur eine DLL laden, wenn die DLL selbst vertrauenswürdig ist
und zumindest die Capabilities besitzt die der Prozess auch.
Regel 2b: Eine DLL kann nicht statisch zu einer DLL, die eine kleinere Menge an
Capabilities besitzt als sie selbst, gelinkt werden.
fälschlicherweise korrumpiert wird und unerwünschter Zugang zu systemkritischen oder vertraulichen Daten verhindert wird. Data Caging wird nur dort angewendet, wo es auch wirklich
gebraucht wird. Symbian OS erreicht Data Caging durch spezielle Verzeichnisse, in denen die
darin liegenden Dateien in privaten Bereichen „weggeschlossen“ werden. Es gibt drei spezielle
Hauptverzeichnisse: \sys, \resource und \private. Die Beschränkungen gelten nur für diese
drei Verzeichnisse und deren Unterverzeichnisse. Alle sonstigen Verzeichnisse bleiben öffentlich zugänglich. Der Zugang zu einer Datei ist somit völlig von ihrem Pfad bestimmt, ganz
ungeachtet dessen, auf welchem Laufwerk sich die Datei befindet. Es werden keine explizieten
Zugangskontrolllisten für jede Datei benötigt, um festzustellen, welcher Prozess auf welche
Datei zugreifen darf.
\sys
Nur TCB-Code hat Zugang zum \sys Verzeichnis und seinen Unterverzeichnissen. Im \sys
\bin Verzeichnis werden alle ausführbaren Dateien gespeichert. Auf diese Weise kann sichergestellt werden, dass nur TCB-Software ausführbare Dateien erstellen oder ausführbare Dateien
in den Speicher laden kann. Ausführbare Dateien in irgendeinem anderen Verzeichnis werden
nicht ausgeführt.
\resource
Dieses Verzeichnis ist für schreibgeschützte Ressource-Dateien gedacht. Ressource-Dateien
werden normalerweise nach der Installation nicht mehr verändert. Nur TCB kann in dieses
Verzeichnis schreiben.
\private
Jede EXE-Datei hat ihren eigenen Data-Caging-Bereich als Unterverzeichnis vom \private
14
Verzeichnis. Die Unterverzeichnisse werden durch die „SID“ (Abschnitt 2.4.2) der EXE-Datei
identifiziert.
Die beiden Konzepte der Capabilities und des Data Caging sind stark miteinander verbunden
und bieten somit flexible Möglichkeiten, den Zugang zu Programmdaten zu kontrollieren. Wie
aus Tabelle 2.5 entnommen werden kann, gibt es zwei Capabilities, die es Prozessen erlauben,
das normale Data Caging zu umgehen. Die bereits in Anschnitt 2.2.3 vorgestellten Capabilities Tcb und AllFiles ermöglichen Schreibzugang zu ausführbaren und schreibgeschützten
Ressourcen beziehungsweise Lesezugang zum gesamten Dateisystem und Schreibzugang zum
\private Verzeichnis.
Tabelle 2.5.: Data-Caging-Zugangsregeln
Capability wird benötigt zum:
Verzeichnispfad
Lesen
Schreiben
\sys
AllFiles
Tcb
\resource
none
Tcb
\private\hownSIDi none
none
\private\hotherSIDi AllFiles
AllFiles
\hotheri
none
none
2.2.5. Symbian Signed
Symbian Signed bietet ein Zertifizierungsprogramm, das eine formale Verbindung zwischen
der Anwendung und ihrer Herkunft herstellen soll. Symbian Signed liefert die Infrastruktur
und den Prozess, der benötigt wird, um eine Anwendung zu identifizieren und zu verifizieren. Es ist eine sichere Methode, eine Anwendung zu identifizieren und den Entwickler der
Anwendung zu authentifizieren. Weiter definiert Symbian Signed eine Menge an Testkriterien, die das Testen der Anwendungen durch unabhängige Testhäuser und Symbian Signed
ermöglichen soll. Anhand von manipulationssicheren digitalen Zertifikaten kann Symbian Signed sicherstellen, dass die Anwendung nach dem Testen und Signieren nicht mehr verändert
worden ist. Symbian Signed liefert somit eine Basis für vertrauenswürdige Software.
Für das Signieren der Anwendungen stehen drei unterschiedliche Möglichkeiten zur Verfügung:
• Open Signed
Ermöglicht dem Entwickler, seine Anwendung durch ein Developer-Zertifikat zu signieren. Abhängig von einer Publisher-ID ist das Open Signed „On“- beziehungsweise „Offline“ möglich.
• Express Signed
Ermöglicht dem Entwickler, mit einer Publisher-ID Software selbst zu signieren und
diese kommerziell zu vertreiben. Hierbei werden keine unabhängigen Tests benötigt,
solange nicht die sensibelsten Capabilities gebraucht werden.
15
2. Grundlagen
• Certified Signed
Stellt die Hauptoption für die kommerzielle Softwareentwicklung dar. Es werden unabhängige Tests und eine Publisher-ID benötigt. Mit Einverständnis der Mobiltelefonhersteller können hier die sensibelsten Capabilities gewährt werden.
Signaturschemata - Prozess
1. Ein digitales Zertifikat wird durch eine Zertifizierungsstelle (in Symbians Fall VeriSign)
erstellt. Dieses Zertifikat wird als „Symbain Root“-Zertifikat definiert. Dieser Schritt
erfolgt nur einmal.
2. Eine Kopie dieses „Symbian Root“-Zertifikates befindet sich auf dem Mobiltelefon.
3. Ein Entwickler, der seine Anwendung zum Signieren einreichen will, signiert diese mit
seiner „Authenticated Content Signing (ACS) Publisher ID“, die er von einer Zertifizierungsstelle gegen eine nominelle Gebühr erhält.
4. Die Anwendung wird zum Testen eingereicht und anhand der Testkriterien, die benötigt
werden, um eine digitale Signatur zu erhalten, getestet. Besteht die Anwendung alle
Tests, wird die Anwendung zur Signierungsstelle gebracht.
5. Die Signierungsstelle erstellt ein eindeutiges Anwendungszertifikat, das vom „Symbian
Root“-Zertifikat abgeleitet ist und signiert schließlich die Anwendung mit diesem Zertifikat.
Abbildung 2.4.: Symbian Signed Prozess [3]
Testkriterien
Symbian Signed definiert eine Menge an Testkriterien, die hier kurz zusammengefasst sind:
16
• Mögliche Namenskollisionen bei DLLs, angemessenes Startverhalten der Anwendungen,
Erstellen von Dateien nur in den erlaubten Bereichen, restlose Deinstallation und erfolgreiche Reinstallation, Anwendung sollte in der „Taskleiste“ zu sehen sein und von
der „Taskleiste“ auch beendet werden können.
• UIDs sollten gültig und korrekt sein und der einreichenden Organisation oder Person gehören. Das Installationspaket sollte eine korrekte und einheitliche Version besitzen, der Zugang zu Plattform/Hersteller-Capabilities sollte regelrecht bewilligt sein.
Die Publisher-ID sollte gültig sein.
• Anwendung sollte ihre Funktionsspezifikation einhalten, darf andere System-Programme
nicht behindern oder System-Events unterdrücken.
• Stresstests mit unterschiedlichen Fehlerbehandlungen durchstehen.
Widerruf einer Anwendung
Der Widerruf einer Anwendung stellt eine letzte Maßnahme dar, eine mögliche Anwendung,
die die Benutzer-, Gerät- und Netzwerksicherheit gefährden kann, zu handhaben. Der Widerruf einer Anwendung geschieht durch den Widerruf des „ContentID“-Zertifikates, mit dem die
Anwendung signiert wurde. Auf diese Art bietet der Widerruf eine letzte Verteidigungsline
und beugt der Verbreitung einer solchen Anwendung vor, sobald sie einmal entdeckt wurde.
Für einen Entwickler, der klar erkennbar nur bösartige Absichten verfolgt, gibt es außerdem die Möglichkeit, die „ACS Publisher ID“ dem Entwickler zu entziehen. Dadurch kann
der Entwickler davon abgehalten werden, weitere Software einzureihen. Wird eine erhebliche
Sicherheitsbedrohung erkannt, kann das Zertifikat durch die Zertifizierungsstelle widerrufen
werden, indem der Status des Zertifikates in der Revocation-Datenbank verändert wird. Wenn
in Zukunft eine Statusanfrage an dieses Zertifikat gestellt wird, kann die signierte Anwendung
von der Installation gehindert werden oder der Benutzer wird informiert, dass sich der Status
der Anwendung verändert hat.
Zu diesem Zweck implementiert Symbian OS das Online Certificate Status Protocol (OCSP)
[8]. Hierfür sendet das Mobiltelefon direkt eine Anfrage an die Revocation-Datenbank der
Zertifizierungsstelle, um eine Bestätigung für den Status der Anwendung zu suchen. Dieser
Check wird gewöhnlich bei der Installation durchgeführt. Seit Symbian OS Version 9.2 kann
der OCSP Check auch manuell zu jeder Zeit durchgeführt werden, um zu überprüfen, ob die
Anwendung nicht seit der Installation widerrufen wurde. Symbian implementiert auch einen
„push“-Mechanismus, der es erlaubt, Benachrichtigungen automatisch zum Mobiltelefon zu
senden, sobald sich der Status der Anwendung ändert.
2.2.6. Konzepte hinter der PSA
Symbian hat eine lange Tradition der Wiederverwendung. Angefangen bei Psion bis hin zum
objektorientierten Entwurf von Symbian OS blieb Symbian diesem Prinzip auch bei der Entwicklung der PSA treu. Es finden sich zahlreiche bereits etablierte und getestete Konzepte in
der PSA-Architektur wieder.
17
2. Grundlagen
Reference Monitor
Das Konzept des Reference Monitor autorisiert Zugangsbeziehungen zwischen Subjekt und
Objekt eines Systems. Der Reference Monitor wurde erstmals in [9] vorgestellt. Danach muss
ein Reference Monitor drei Eigenschaften erfüllen:
• Der Referenzmonitor selbst muss vor Manipulation geschützt sein.
• Der Referenzmonitor muss immer aufgerufen werden.
• Der Referenzmonitor sollte klein genug sein, um Subjekt für Analysen und Tests zu sein,
sodass die Vollständigkeit garantiert werden kann.
Entwurfsprinzipien der Schutzmechanismen
Gemäß [10] gibt es acht Entwurfsprinzipien, die auch Symbian bei dem Entwurf der PSA
herangezogen hat.
1. „Economy of mechanism“
Symbian realisiert dieses Konzept mit der TCB, die so klein wie möglich gehalten wurde,
sodass auch der Quellcode Zeile für Zeile überprüft werden kann.
2. „Fail-safe defaults“
Software hat standardmäßig in Symbian OS keine Privilegien. Erst durch entsprechende Verfahren (z.B. Symbian Signed) können Privilegien vertrauenswürdiger Software
gewährt werden.
3. „Complete mediation“
Dieses Architekturprinzip realisiert Symbian durch das Client/Server-Framework.
4. „Open design“
Symbian OS ist von Grund auf ein offenes Betriebssystem.
5. „Separation of privilege“
Symbian besitzt auch die Fähigkeit, Anwendungen mit mehr als einer Signatur zu fordern um entsprechende Privilegien zu gewähren.
6. „Least privilege“
Wird in Symbian OS durch Kontrolle der Privilegien und das Benutzen verschiedener
Capabilities erreicht.
7. „Least common mechanism“
Das beste Beispiel für dieses Prinzip in Symbian OS sind DLLs. Die DLL-Regeln stellen
sicher, dass ein privilegierter Prozess eine DLL nur dann verwenden kann, wenn die DLL
mindestens die Privilegien besitzt, die der Prozess auch.
8. „Psychological acceptability“
Symbian bietet sicherheitsrelevante Hinweise wenn Software installiert wird und versucht
außerdem auftretende Sicherheitshinweise zur Laufzeit zu minimieren.
18
2.3. Emulator
Capability basierendes Sicherheitsmodell
In [11] wurde ein Mechanismus „Schutz der ausführenden Instanzen vor unbefugtem Zugriff“
vorgestellt. In diesem Paper wurde der Begriff der „Capability Liste“ eingeführt. Demnach
hat jeder Prozess im System eine Capability-Liste, in der festgelegt wird, auf welche geschützten Ressourcen jeder Prozess zugreifen darf und welche Zugangsrechte er besitzt. Symbian
betrachtet die essentiellen Eigenschaften der Capability als ein persistents Attribut eines
Prozesses. Dieses Attribut wird bevor ein Prozess erstellt wird bestimmt und definiert die
vollständigen Zugangsrechte zu geschützten Bereichen.
Architektonische Ziele
Symbian hat sich einige architektonische Ziele für die PSA gesetzt, die hier kurz zusammengefasst sind:
• Sicherstellung der Verständlichkeit
Wenn dem Benutzer das Sicherheitssystem vorlegt wird, sollte er in der Lage sein es zu
verstehen.
• Unterstützung von offenen Mobiltelefonen
Eine erweitere Sicherheitsplattform sollte Dritthersteller nicht davon abhalten, auch
weiterhin interessante Software für Symbian OS herzustellen.
• Schutz der Netzwerks
Die Netzwerkinfrastruktur sollte durch offene Mobiltelefone nicht gefährdet werden.
2.3. Emulator
In diesem Abschnitt wird der Symbian OS Emulator eingeführt. Dafür wird zunächst eine
Übersicht der Emulator-Plattform gegeben, um anschließend die Eigenschaften und Unterschiede des Symbian OS Emulators zu erklären.
2.3.1. Übersicht
Der Symbian OS Emulator wurde in erster Linie für die Entwicklung und das Debugging von
Symbian OS Software entwickelt. Für die meisten Entwicklungszwecke kann der identische
Quellcode sowohl für Symbian OS Mobiltelefone als auch für die Emulatorplattform verwendet
werden. Der Basis-Emulator wird von Symbian geliefert, aber der endgültige Emulator wird
für die gewählte Variante beispielsweise S60 oder UI maßgeschneidert.
Der Emulator ist als Portierung des EKA2-Kernels geschrieben worden. Auf diese Art ist es
möglich, so wenig Windows-APIs wie möglich zu benutzen und dadurch den größtmöglichen
Symbian OS Code zwischen dem Emulator und der Implementierung auf einem realen Gerät
zu verwenden. In Abbildung 2.5 ist der Vergleich zwischen dem Quellcode, der auf dem Emulator und dem Quellcode der auf dem realen Gerät ausgeführt wird, dargestellt. Hier wird
deutlich, dass nur auf der architekturspezifischen Ebene des Nanokernels eine „Win32“-CPU
emuliert wird anstelle einer ARM-CPU oder einer X86-CPU. Tatsächlich bedeutet das, dass
19
2. Grundlagen
der Emulator auf einen anderen Prozessor portiert wurde. Die im Emulator geladenen ImageDateien sind Standard „Win32 PE EXE“-Dateien, mit deren Hilfe sich auch Standard Tools
der Gastplattform zum Debuggen auf Quellcodeebene einsetzen lassen.
Abbildung 2.5.: Emulator Übersicht [2]
2.3.2. Eigenschaften
Die folgenden Punkte geben einen kurzen Überblick über die Eigenschaften des Symbian OS
S60 3rd Emulators:
• Diagnose- und Überwachungswerkzeuge
Die wesentliche Eigenschaft des Emulators besteht darin, den Entwickler bei seinem
Entwicklungsprozess zu unterstützen. Zu diesem Zweck bietet der Emulator zahlreiche
Möglichkeiten, die Funktionsfähigkeit der Anwendung zu untersuchen und zu überwachen. Hier stehen dem Entwickler Diagnosewerkzeuge zur Verfügung, mit denen zum
Beispiel die CPU-Auslastung oder die Speicherbelegung überwacht werden kann. Aber
auch die Unterstützung für das Protokollieren sämtlicher Vorgänge im Emulator und interaktiver Debugger Programme, die mit Hilfe des Emulators ausgeführt werden können.
Um mögliche auftretende Ereignisse wie zum Beispiel einen sehr geringen Batteriestand
besser verarbeiten zu können, bietet der Emulator zahlreiche solcher simulierten Ereignisse auf Abruf.
• Kommunikation
Im Emulator kann eine Vielzahl an Kommunikationsmethoden wie Bluetooth, Infrarot
oder Internetverbindungen über TCP/IP benutzt werden. In der „S60 3rd FP1 Version“
unterstützt der Emulator auch einen „USB Bluetooth Dongle“.
• Verschiedene Einstellmöglichkeiten
20
2.3. Emulator
Der Emulator bietet dem Entwickler nicht nur Diagnose- und Überwachungswerkzeuge,
sondern auch viele Einstellmöglichkeiten. Besonders in Hinblick auf die PSA kann hier
die Sicherheitsprüfung der Capabilities oder sonstigen Plattform-Sicherheitsrichtlinien
ein- beziehungsweise ausgeschaltet werden. Es können aber auch entsprechende Capabilities eingestellt werden, die ohne Prüfung allen Prozessen gewährt werden können.
• Virtuelle Laufwerke
Neben den simulierten ROM und Flash-Laufwerken, die auf entsprechende Verzeichnisse auf der Gastplattform abgebildet werden, können weitere virtuelle Laufwerke dem
Emulator hinzugefügt werden.
2.3.3. Unterschiede
Da es sich bei dem Symbian-Emulator um eine Portierung des Symbian OS Kernels auf eine
Win32-Plattform handelt, gibt es wesentliche Unterschiede zwischen dem Emulator und der
Ausführung auf einem realen Gerät. Die einzelnen Unterschiede sind in den untenstehenden
Punkten kurz zusammengefasst:
• SWInstaller und Zertifikatsprüfung
Der Emulator benötigt keinen „SWInstaller“, der die Installationsdateien an die richtige
Stelle kopiert, sondern die Installationsdateien werden bereits bei der Kompilierung
für die native x86-Plattform in die richtigen Verzeichnisse des Emulators kopiert. Das
Nichtvorhandensein der SWInstallers hat aber zur Folge, dass keine Installationspakete
erstellt und auch nicht signiert werden müssen. Für den Entwicklungsprozess ist es von
Vorteil, nicht immer das Installationspaket signieren zu müssen.
• Dateisystem Unterstützung
Der Emulator kann eine Vielfalt an Dateisystemen und Laufwerkstypen emulieren.
Das beinhaltet ROFS/FAT auf NAND-Flash Speicher, LFFS auf NOR-Flash Speicher,
MMC- und RAM-Laufwerke. All diese Laufwerke werden auf einzelne Dateien im lokalen Windows-Laufwerk abgebildet. Die Leistung und Größe solcher emulierter Laufwerke
kann sich anders verhalten als von der realen Hardware erwartet. Hierbei ist auch zu
beachten, dass die Größe des emulierten Laufwerkes C: nicht beschränkt werden kann.
Jedoch kann die maximale Größe des emulierten RAM-Laufwerkes durch das Schlüsselwort RamDriveMaxSize in der epoc.ini geändert werden.
• Fließkomma-Verhalten
Symbian OS unterstützt die einfache und doppelte Genauigkeit der Fließkommazahlen
nach IEEE-754 und repräsentiert diese Typen durch TReal32 (ein C++ float-Typ) beziehungsweise TReal64 (ein C++ double-Typ). Da der Emulator auf der x86-Plattform
implementiert wurde, unterstützt dieser Fließkommazahlen in Hardware. Die Hardware
der Zielplattform muss nicht unbedingt Fließkommazahlen in Hardware unterstützen,
sodass der Compiler die Berechnung in Software durchführen muss.
21
2. Grundlagen
• Maschinen Wörter
ARM-Prozessoren verwenden eine 32-Bit-RISC-Architektur. Eine Konsequenz dessen
ist, dass 32-Bit-Größen zur 32-Bit-Maschinenwortgrenze ausgerichtet sein müssen. Oder
anderes ausgedrückt, ihre Adresse muss ein Vielfaches von vier sein. Auf dem Emulator
gibt es diese Beschränkung aufgrund der x86-Architektur nicht.
• Speicherbeschränkungen
Standardmäßig emuliert der Emulator ein Gerät mit einer maximalen Heapgröße von 64
Megabyte. Dieser Wert kann aber durch das Schlüsselwort MegabytesOfFreeMemory verändert werden. Die initiale und maximale Heapgröße kann individuell für jeden Prozess
durch das Schlüsselwort epochheapsize in der „MMP-Datei“ angegeben werden. Die
Stackgröße in standardmäßig auf dem realen Gerät auf 8 Kilobyte gesetzt. Im Gegensatz dazu, vergrößert sich die Stackgröße nach Bedarf im Emulator. Auf dem Gerät kann
die Stackgröße durch das Schlüsselwort epocstacksize in der „MMP-Datei“ definiert
werden. Hier besteht jedoch das Problem, dass dieses Schlüsselwort für die Emulator
Plattform nicht unterstützt wird.
• Prozess Emulation
Es gibt keinen Speicherschutz zwischen den emulierten Prozessen. Das bedeutet, dass
ein Prozess beispielsweise durch einen Zeiger-Fehler in einen Adressbereich eines anderen Prozesses schreiben könnte. Im Emulator würde das zur keiner „Exception“ führen,
wohingegen das identische Programmverhalten auf einem realen Gerät zur einer Speicherschutzverletzung führen würde.
• Scheduling
Symbian OS stellt 64 Prioritätlevel für Threads zur Verfügung, während Windows nur
fünf voneinander verschiedene Prioritätslevel innerhalb eines Prozesses bereitstellt. Das
hat dann zur Folge, dass der Emulator keine Echtzeitgarantien bieten kann, wie sie der
EKA2-Kernel auf der Zielhardware bereitstellen kann.
• Timer
1
Die Standard Timer-Genauigkeit von 64
-Sekunden ist für alle Plattformen gleich, den
Emulator eingeschlossen. Ein etwas feinerer Timer auf der Referenzplattform hat eine
Genauigkeit von einer Millisekunde, im Emulator ist aber die Genauigkeit dieser Timer
standardmäßig auf fünf Millisekunden gesetzt. Aber auch hier kann die Genauigkeit in
der epoc.ini angepasst werden.
• USB
Symbian OS bietet eine USB-Client-Unterstützung auf der Referenzplattform, jedoch
steht das dem Emulator nicht zur Verfügung.
22
2.4. Programming
2.4. Programming
Der abschließende Abschnitt der Grundlagen beschreibt den Systemaufbau und die ProgrammierKonzepte von Symbian OS. Dabei werden zunächst der SWInstaller und das Installationspaket
mit den entsprechenden Installationsregeln näher beschrieben. Anschließend wird die Speicherverwaltung in Symbian OS skizziert und der Kernel kurz vorgestellt. Den abschließenden Teil
bilden die Kommunikationsarchitektur und das DLL-Konzept.
2.4.1. SWInstaller
Der native Software Installer ist eine Symbian OS Komponente, die die Installation von AddOn Software-Paketen verwaltet. Der Software Installer ist zusätzlich für die folgenden Punkte
verantwortlich:
• Validierung und Installation von Software-Paketen (SIS-Dateien) auf dem Mobiltelefon.
• Validierung der Software, die in vorinstallierter Form auf einer Speicherkarte bereitgestellt wird.
• Verwaltung der Aktualisierung und Deinstallation vorhandener Software.
• Bereitstellung eines Paket-Managements für den Rest der Plattform.
Der Software Installer als Teil der TCB kann selbst privilegierte Operationen ausführen, um
beispielsweise Dateien in die geschützten Bereiche zu kopieren.
2.4.2. Installationspaket(SIS-Datei)
Update-Typen
Symbian OS bietet verschiedene Möglichkeiten, eine vorhandene Anwendung zu aktualisieren
oder diese neu zu installieren:
• Standard Upgrade (SA)
Das Standard Upgrade installiert das gleiche Paket erneut. Während des Upgrades wird
das originale Paket gelöscht und durch das neue ersetzt. Es wird jedoch eine neue Versionsnummer für das Installationspaket benötigt.
• Partial Upgrade (PU)
Bei diesem Update Typ werden nur die benötigten Dateien modifiziert oder neue Dateien hinzugefügt. Auch hier wird eine neue Versionsnummer benötigt. Während der
Deinstallation wird das gesamte Paket gelöscht, eine vorherige Version kann nicht wiederhergestellt werden.
• SIS Patch (SP)
Dieser Update Typ unterstützt nur das Hinzufügen neuer Dateien. Jedoch dürfen die
neuen Dateien nicht in Konflikt mit bereits vorhandenen Dateien stehen. Ein SIS Patch
kann nachträglich identifiziert und somit auch wieder deinstalliert werden.
23
2. Grundlagen
• Preinstalled Application (PA)
Preinstalled Application ist kein Update-Typ, sondern bezeichnet Anwendungen, deren
Programmdaten und ausführbare Dateien sich bereits in den Zielverzeichnissen auf der
Speicherkarte befinden. Beim Einlegen der Speicherkarte in das Mobiltelefon wird die
Anwendung automatisch installiert.
File Eclipsing
Eine Eclipsing-Situation kann genau dann auftreten, wenn der gleiche Pfad und die gleiche
Datei auf zwei oder mehr Laufwerken vorhanden sind. Denn in Symbian OS sucht der „Loader“
eine Datei in umgekehrter alphabetischer Reihenfolge von Y: zu A: und am Ende Z:, bis er den
richtigen Dateinamen findet. In der Praxis wird der SWInstaller diese Möglichkeiten erkennen
und durch folgende Eclipsing-Regeln versuchen, es zu verhindern:
• Wenn ein vertrauenswürdiges Paket versucht eine Datei zu installieren, die eine EclipsingSituation mit einer Datei eines anderen nicht vertrauenswürdigen Pakets hervorruft,
kann der Benutzer gefragt werden, ob die Datei des nicht vertrauenswürdigen Pakets
gelöscht werden soll.
• Wenn ein Versuch unternommen wird eine Eclipsing-Situation im ROM herzustellen,
wird der Versuch misslingen, außer es gibt eine verknüpfte „SIS-Stub-Datei“ im ROM,
die der SWInstaller nutzen kann, um die Ersatzdatei als originale Update-Datei zu
identifizieren.
File Overwriting
Das Überschreiben vorhandener Dateien ist weder absichtlich noch zufällig oder in sonstiger
Art erlaubt. Aber es gibt hier auch zwei Ausnahmen:
• Wenn es sich um einen Update-Typ wie in Abschnitt 2.4.2 handelt, wird das Überschreiben erlaubt.
• Versucht ein vertrauenswürdiges Paket eine Datei eines nicht vertrauenswürdigen Pakets
zu überschreiben, so kann abhängig von der Konfiguration des Mobiltelefonherstellers
der Benutzer gefragt werden, ob die Datei des nicht vertrauenswürdigen Pakets entfernt
werden soll.
Tritt bei der Installation keine dieser Bedingungen ein, kann die Installation nicht fortgeführt werden. Die Benutzerschnittstelle sollte in diesem Fall einen Konflikt melden und das
blockierende Paket angeben.
IDs
Eine UID ist eine vorzeichenbehaftete 32-Bit-Nummer, die von Symbian vergeben wird. In
Symbian gibt es mehrere UIDs, die unterschiedlichen Zwecken dienen:
24
2.4. Programming
• SID
SID oder Secure ID identifiziert einen Prozess zur Laufzeit eindeutig. Die SID dient
außerdem der Kontrolle, um Zugang zu geschützen Ressourcen (z.B. den privaten Verzeichnissen) zu bekommen. Weiter werden die SIDs in zwei Bereiche unterteilt, einen
geschützten 0x00000000-0x7FFFFFFF und einen ungeschützten Bereich 0x800000000xFFFFFFFF. Eine detaillierte Aufteilung der UID-Bereiche ist in Tabelle 2.6 gegeben.
• VID
Der Vendor Identifier ist ein weiteres Attribut, um den Zugang zu geschützten Ressourcen zu kontrollieren. Die VID muss nicht eindeutig sein und eine EXE benötigt nicht
unbedingt eine VID.
• UID1
Systemweiter Bezeichner, der zwischen EXEs (KExecutableImageUid = 0x1000007a)
und DLLs (KDynamic- LibraryUid = 0x10000079) unterscheidet. Wird durch die BuildTools automatisch erstellt.
• UID2
Repräsentiert die Interface-Definition, die mit der ausführbaren Datei übereinstimmt
(z.B. KUidApp = 0x100039CE).
• UID3
Identifiziert eine Komponente eindeutig. Um sicherzustellen, dass jede ausführbare Datei
eine unterscheidbare und eindeutige UID bekommt, verwaltet Symbian eine zentrale
Datenbank zur Vergabe der UIDs. Ist die SID nicht spezifiziert, wird die UID3 benutzt.
• pUID
Die Package UID ist im Wesentlichen der eindeutige Bezeichner für das SIS-Installationspaket und wird in der „Paketdatei“ spezifiziert.
Tabelle 2.6.: Aufteilung der UID-Bereiche [1]
UID-Bereich
Vorgesehene Verwendung
0x00000000
KNullUID
0x00000001 - 0x0FFFFFFF Reserviert für zukünftigen Gebrauch
0x20000000 - 0x2FFFFFFF Geschützter UID/SID-Bereich ab Version 9
0x70000000 - 0x7FFFFFFF Vendor IDs (VIDs)
0xA0000000 - 0xAFFFFFFF Nicht geschützter UID/SID-Bereich ab Version 9
0xB0000000 - 0xE0FFFFFF Reserviert für zukünftigen Gebrauch
0xE1000000 - 0xEFFFFFFF Neuer Testbereich ab Version 9
0xF0000000 - 0xFFFFFFFF Alter UID-Kompatibilitätsbereich
25
2. Grundlagen
2.4.3. Speicherverwaltung
MMU
Symbian OS setzt für die Platform Security eine MMU voraus. Mit Hilfe der MMU ist es der
System-Software möglich, virtuelle Adressen flexibel auf physische Adressen abzubilden. Zusätzlich zur Adressübersetzung besitzt die MMU die Fähigkeit, Speicherregionen von Zugriffen
durch Software mit unzureichenden Privilegien zu schützen.
Chunks
Symbian OS benutzt Chunks, um fortlaufende Regionen im virtuellen Speicher zu repräsentieren. Die Größe eines Chunks ist variabel.
Prozess im Speicher
Wenn ein Prozess erstellt wird, erzeugt Symbian OS mindestens die folgenden Chunks für
diesen Prozess:
Statische Daten und Stack Chunk Beschreibt den Chunk, indem sich der Stack sowie die
statischen Daten für den Prozess und all seine Threads befinden.
Heaps Chunk(s) In diesem Chunk wird der Heap gespeichert. Für jeden Thread kann es einen
Heap Chunk geben. Heap Chunks können zwischen allen Threads gemeinsam genutzt
werden.
Code Chunk Der Code Chunk enthält eine Kopie des Codes und existiert nur einmal im
Speicher. Alle Instanzen des Prozesses benutzen diesen Code Chunk untereinander. Anwendungen, die sich im ROM des Mobiltelefons befinden, werden auch an dieser Stelle
ausgeführt, ohne den Code in den Code Chunk zu kopieren.
Speicherabbildung
Die Basisabbildung des virtuellen Speichers, wie sie in Symbian OS benutzt wird, ist in Abbildung 2.6 dargestellt. Die beiden interessanten Bereiche sind die „home area“ und die „run area“.
Im home area Bereich werden die Daten-Chunks gehalten wenn ein Prozess gestartet wurde,
der aber zurzeit nicht aktiv ist. Der home area Bereich ist ein geschützter Speicherbereich,
in dem nur der Kernel lesen und schreiben kann. Ist ein Thread zur Ausführung bereit, so
wird der Daten-Chunk, der mit diesem Prozess verknüpft ist, von der home area im virtuellen
Speicher in die run area mit Hilfe der MMU verschoben. Danach kann der Thread ausgeführt
werden. Im Gegensatz dazu werden Code Chunks nie in die run area verschoben. Zum einen
sind keine separaten Codekopien für jede Prozessinstanz vorhanden und zum anderen kann
der Code von seinem Bereich in der home area ausgeführt werden.
26
2.4. Programming
Abbildung 2.6.: Virtuelle Speicherabbildung
Schutz der Prozesse voreinander
„User Mode“-Programme können nur auf die run area (plus die Code Chunks) zugreifen. Auf
den Rest des Speichers kann nur im privilegierten Modus der CPU zugegriffen werden, also nur
der Kernel, die Gerätetreiber und andere ausgewählte OEM-Komponenten können auf diesen
Teil des Speichers zugreifen. Das bedeutet, dass ein User-Prozess keinen direkten Zugang zu
Daten eines anderen Prozesses hat. Darüber hinaus hat ein User-Prozess keinen Zugang zu
Hardware-Geräten oder CPU-Datenstrukturen wie der MMU-Seitentabelle. Die run area kann
auch als „Sandbox“ bezeichnet werden, da die Prozesse in einem isolierten Bereich ausgeführt
werden.
2.4.4. Kernel
Der Symbian OS Kernel besteht aus einer Menge an ausführbaren Dateien und Daten, die im
privilegierten Modus der CPU ausgeführt werden. Der Kernel verarbeitet das Erstellen und
Scheduling von Threads und Prozessen. Er verwaltet die Kommunikation zwischen Threads
und Prozessen mit Objekten wie Mutexen und Semaphoren genauso wie die Vermittlung von
Daten zwischen den einzelnen Prozessen. Zudem verwaltet der Kernel den gesamten Systemspeicher und dient als Schnittstelle zur Geräte-Hardware.
Der Symbian Kernel beinhaltet als Teil seiner Architektur einen Nanokernel. Obwohl der Nanokernel nur einen geringen Teil des Kernels ausmacht, bietet er Basisdienste wie einfache
„Supervisor Mode“-Threads zusammen mit ihren Scheduling- und Synchronisationsoperationen. Der Nanokernel verarbeitet auch die initialen System-Interrupts und beinhaltet andere
Mechanismen, um sicherzustellen, dass das System ein vorhersagbares Antwortverhalten bietet.
27
2. Grundlagen
EKA2 und EKA1
Symbian OS führte EKA2 (EPCO Kernel Architecture 2) mit der Version 8.1b ein und mittlerweile wird EKA2 in allen Symbian Version 9 basierenden (S60 3rd Edition und UIQ3)
Mobiltelefonen benutzt. Eine erhebliche Verbesserung in EKA2 ist die Fähigkeit, Symbian
OS auf Mobiltelefonen mit nur einem Prozessor auszuführen. Das wurde dadurch erreicht,
dass in EKA2 eine Echtzeitfähigkeit implementiert wurde, die es sowohl der integrierten „Radio Software“ als auch den Anwendungen erlaubt, den gleichen Prozessor nutzen zu können.
2.4.5. Kommunikationsarchitektur
Client/Server
Symbian OS baut eine Vielzahl seiner Funktionalität auf der Client/Server-Architektur auf.
Im Wesentlichen stellt ein Server nur die Methoden bereit, um Clients Zugang zu gemeinsamen Ressourcen oder sonstigen Funktionalitäten zu gewähren. Dabei wartet er auf Befehle
vom Client, führt die damit verbundenen Dienste aus, gibt die Resultate an den Client wieder
zurück und wartet auf neue Anweisungen. Ein Server hat normalerweise keine grafische Benutzeroberfläche. In den meisten Fällen wird ein Server in einem eigenen Prozess ausgeführt,
um so mehr Schutz und Modularität zu gewährleisten. Viele Server bieten eine client-seitige
Bibliothek an, um das Client/Server-Protokoll zu kapseln.
Ein Client-Programm benutzt einen Server durch eine client-seitige Implementierungsklasse. Dabei werden Funktionen des Servers über Methoden der Client-Klasse aufgerufen. Jede
Methode sendet eine passende Anweisung an den Server und empfängt die Ergebnisse der
Anweisung, um sie der aufrufenden Methode zu übergeben. Die Client-Klasse ist auch für den
Aufbau der Session mit dem entsprechenden Server verantwortlich.
Das Client/Server-Konzept bietet aber auch durch die PSA zahlreiche Sicherheitsmechanismen.
File Handle
Symbian OS besitzt die Möglichkeit, vorübergehend eine Datei gemeinsam mit einem anderen Prozess unter kontrollierten Bedingungen zu nutzen. Der Kernel bietet grundlegende
Unterstützung für das gemeinsame Nutzen von Handles über Prozessgrenzen hinaus. Der „File
Server“ baut darauf auf:
• Der öffnende Prozess öffnet eine Datei in einem Modus, der von dem empfangenden
Prozess unter normalen Bedingungen nicht verändert werden kann.
• Der empfangende Prozess greift über das erhaltene Handle auf die Datei zu, kann aber
nicht auf das private Verzeichnis der gemeinsam genutzten Datei zugreifen.
• Der öffnende Prozess teilt sich eine „File Server Session“ mit dem empfangenden Prozess.
• Die Aufhebung der gemeinsamen Nutzung der Datei ist nicht möglich.
28
2.4. Programming
File Handles sind keine Handles im Sinne von Referenzen zu Kernelobjekten, sondern eindeutige Bezeichner zu einer offenen Datei innerhalb einer „File Server Session“.
Speicher Chunks
Symbian OS unterstützt auch gemeinsam genutzte Speicherregionen, auf die mehrere Prozesse
direkt zugreifen können. Diese gemeinsam genutzten Regionen werden als Speicher Chunks
bezeichnet. Damit ein Speicher Chunk gemeinsam mit anderen Prozessen genutzt werden
kann, muss dieser als globaler Chunk erstellt werden. Jeder andere Prozess im System kann
diesem Speicher Chunk auslesen oder auch beschreiben, wenn er den Namen des Chunks
kennt. Zusätzlich zu seinen Namen muss noch die Größe im physischen RAM des Chunks
angegeben werden und der virtuelle Speicher, der reserviert werden muss. Dabei kann der
virtuelle Speicher größer sein als die tatsächliche Größe im physischen RAM des Chunks.
Wenn die letzte Referenz zu einem globalen Chunk geschlossen wurde, wird der globale Chunk
automatisch gelöscht. Ein etwas sicherer Weg, globale Chunks zwischen Prozessen zu benutzen,
ist, die Chunks ohne einen Namen zu erstellen und über ihre Handles zu referenzieren. Auf
diese Weise können die Chunks nicht mehr gefunden und somit auch nicht durch andere
Prozesse benutzt werden.
Publish & Subscribe
Publish & Subscribe wurde in Symbian Version 9 eingeführt. Es erlaubt das Erstellen, Abfragen
und Überwachen von systemweiten Variablen. Zudem bietet es einen neuen IPC-Mechanismus
für „Peer-to-Peer“-Kommunikation zwischen Threads. Die systemweiten Variablen werden in
diesem Zusammenhang Properties genannt. Der Mechanismus besteht aus drei Komponenten,
die in Abbildung 2.7 dargestellt sind:
Properties definieren entweder einen einzigen 32-Bit-Datenwert oder eine variable Menge an
Bytes, die durch einen 64-Bit-Integer identifiziert wird.
Publishers sind Threads, die eine Property definieren und aktualisieren.
Subscribers sind Threads, die den Wert der Property abfragen und auf mögliche Veränderungen der Property warten.
Publish & Subscribe liefert einen Laufzeit-Data-Cage, in den jeder Prozess seine Properties
einstellen kann, der von Manipulation oder „Denial of Service“ geschützt ist. Unter bestimmten
Umständen bietet Publish & Subcribe begrenzte Ausführungszeiten für kritische Anwendungen, die Echtzeitgarantien benötigen.
Wenn ein Prozess eine Property definiert, wird sie in einer Kategorie, die der SID des Prozesses entspricht, gespeichert. Kein anderer Prozess kann eine Property in diesem Schlüsselraum definieren und somit auch nicht manipulieren. Als Nebeneffekt entsteht der beschriebene
Laufzeit-Data-Cage. Zum Zeitpunkt der Definition der Property muss der Prozess auch eine
Lese- und Schreib-Policy bereitstellen. Mit diesen Lese- und Schreib-Policys kann der Zugriff
auf die Property mit bestimmten SIDs, VIDs oder mit den entsprechenden Capabilities beschränkt werden. Eine Property existiert solange, bis das Mobiltelefon ausgeschaltet wird oder
bis der Prozess, der die Property definiert hat, sie löscht.
29
2. Grundlagen
Abbildung 2.7.: Publish & Subscribe Übersicht [2]
2.4.6. DLL
Eine DLL (Dynamic Link Library) enthält Code und Daten, die von mehr als einem Prozess
zur gleichen Zeit benutzt werden können. Die DLL wird erst in den Speicher geladen, wenn sie
auch tatsächlich gebraucht wird. Dadurch kann die Speicherausnutzung optimiert werden.
Statische DLL
Statische DLL sind traditionelle Bibliotheken, die zahlreiche Klassen und Funktionen enthalten. Die Funktionalität zu aufrufenden Prozessen wird durch eine Reihe von Exportfunktionen
zur Verfügung gestellt. Jedoch besitzt eine statische DLL eine Einschränkung, sie kann keine beschreibbaren statischen Daten enthalten. Eine statische DLL wird automatisch in den
Speicher geladen, wenn ein Programm, das die DLL benutzt, gestartet wird. Sie wird auch
automatisch wieder entladen, wenn kein anderer Prozess diese DLL mehr benötigt. Wenn eine neue Version einer bereits geladenen DLL installiert wird, so wird die alte DLL solange
benutzt, bis die DLL aus dem Speicher entladen wird.
Polymorphe DLL
Eine polymorphe DLL implementiert ein abstraktes Interface, das oft separat definiert wird,
beispielsweise durch ein „Framework“. Polymorphe DLL haben eine einzige Einsprungsfunktion, die als „gate“ oder „factory“ bezeichnet wird. Diese Einsprungsfunktion instanziiert die
konkrete Klasse, die wiederum das Interface implementiert. Die Interface-Funktionen sind
virtuell. Sie werden nicht exportiert, sondern von der virtuellen Funktionstabelle durch einen
Zeiger zum Basisklassen-Interface aufgerufen. Polymorphe DLL werden häufig verwendet,
um eine Reihe verschiedener Implementierungen eines einheitlichen Interfaces bereitzustellen.
Dieser DLL-Typ wird oft auch als „Plug-in“ bezeichnet.
30
Im ersten Kapitel habe ich die Problemstellung dieser Arbeit beschrieben. Dieses Kapitel zeigt
nun, wie ein solches System spezifiziert werden muss. Das Ziel dieser Arbeit ist, wie in Kapitel
1.2 beschrieben, die Implementierung eines Testsystems, das mit möglichst wenig Redundanz
alle Komponenten der PSA untersucht. Dieser Satz beinhaltet schon implizit die folgenden
Abschnitte. Was soll das Testsystem umfassen? Wie kann das mit wenig Redundanz erreicht
und können überhaupt alle Komponenten der PSA getestet werden? Bei der Frage nach dem
Testsystem müssen zunächst die Anforderungen an das Testsystem definiert und die zur Verfügung stehenden Parameter für das Testsystem erläutert werden. Anhand der zur Verfügung
stehenden Parameter kann die Frage nach der Redundanz der Testfälle beantwortet werden.
Die Frage nach der Vollständigkeit aller Komponenten der PSA kann mit der Gegenüberstellung der theoretisch testbaren Komponenten und der Komponenten, die das Testsystem
definiert, beantwortet werden.
3.1. Verifikation der Konfiguration
Die Grundlagen haben gezeigt, dass die PSA aus wesentlich mehr Komponenten besteht, als
nur der Implementierung auf dem Mobiltelefon. Angefangen bei den Grundlagen der PSA,
gibt es bereits dort Unterschiede in den Versionsstufen von Symbian OS Version 9. Das bedeutet, schon in der frühen Entwicklungsphase muss dieser Parameter in Betracht gezogen
werden. Das Testsystem muss die Fähigkeiten besitzen, mit den unterschiedlichen Symbian Versionen umgehen zu können und zu jeder Version entsprechende Testfälle generieren.
Weitere Aufgaben stellen für das Testsystem die Plattformen dar. Wie in den Grundlagen
beschrieben, existiert neben der Mobiltelefon-Plattform noch der Symbian OS Emulator. Für
jede Symbian Version 9 steht ein Emulator zur Verfügung. Der Emulator kann deshalb als
„Referenzimplementierung“ für die jeweilige Symbian OS Version 9 gesehen werden, da die
Implementierung in dieser Form noch durch keinen Mobiltelefonhersteller konfiguriert wurde.
Das Testsystem muss die verschiedenen Plattformen als Parameter verarbeiten können. Einen
anderen Parameter, neben den eigentlichen PSA-Tests, stellt das Zertifizierungsprogramm
von Symbian Signed dar. Hierbei stehen dem Entwickler zahlreiche Möglichkeiten zur Verfügung, um das fertige Programm zu signieren. Damit das Testsystem mit den unterschiedlichen
Zertifikaten umgehen kann, muss es die Möglichkeit besitzen, diese Parameter in das System
einzubeziehen. Schon anhand dieser ersten drei Punkte wird die Notwendigkeit einer zentralen
Konfiguration des Testsystems deutlich. Aus diesem Grund, auch für eine detaillierte Definition der einzelnen Testfälle, eignet sich eine Konfigurationsdatei für das Testsystem. Die
Datei soll dabei einfach zu erstellen sein und so flexibel gehalten werden, dass sich auch leicht
weitere Testfälle definieren lassen können.
31
3.1.1. Testsystemaufbau
Die Idee für ein solches Testsystem besteht nun darin, die einzelnen Aufgabenbereiche von
einander zu trennen und das Testsystem durch eine Konfigurationsdatei spezifizieren zu können. Weiter soll das Testsystem, basierend auf der Definition in der Konfigurationsdatei, die
einzelnen Testfälle automatisch generieren. Die Testfälle sollen dabei so zusammengebaut werden, dass sie mit wenig Redundanz erstellt werden könnten. Um das zu bewerkstelligen, ist
das System in drei Module geteilt, einen „Intelligent Code-Builder“, einen „Package-Creator“
und einen „Emu-Builder“. Diese drei Bausteine bilden das Testsystem und sind in Abbildung
3.1 grafisch dargestellt. Die Aufgabe des Intelligent Code-Builder besteht in erster Linie in
der Erstellung des Quellcodes für die Testfälle. Die Testfälle sollen dabei automatisch und
abhängig von der Spezifizierung in der Konfigurationsdatei generiert werden. Der daraus resultierende Quellcode ist gleichzeitig die Eingabe für den „Package-Creator“ beziehungsweise
für den „Emu-Builder“. Wobei hier abhängig von der gewählten Plattform, wahlweise der
„Package-Creator“ oder der „Emu-Builder“ zum Einsatz kommt. Sollen Testfälle für das Mobiltelefon und nicht für den Emulator erstellt werden, wird der Package-Creator verwendet.
Dieser ist für die Kompilierung der Testfälle für das gewählte SDK zuständig. Um jedoch
die Testfälle auf dem Mobiltelefon ausführen zu können, muss der Package-Creator zunächst
eine „Paketdatei“ erstellen. Mit Hilfe der Paketdatei ist es dem Package-Creator möglich, das
Installationspaket aus der Definition der Paketdatei zu erstellen. Im letzten Schritt kann der
Package-Creator dann schließlich das fertige Installationspaket signieren und so für die Installation bereitstellen. Wird hingegen der Emulator als Ziel-Testplattform gewählt, kommt der
Emu-Builder zum Einsatz. Die Aufgabe der Emu-Builders ist wesentlich einfacher als die des
Package-Creators, denn er muss nur den vom Intelligent Code-Builder generierten Quellcode
für die richtige Version kompilieren. Damit der Testfall auch ausgeführt werden kann, muss
der Emu-Builder die kompilierten Dateien in die entsprechenden Verzeichnisse des Emulators
kopieren.
Abbildung 3.1.: Testsystem
32
3.1.2. Testbereiche
Nachdem die grobe Architektur des Testsystems eingeführt wurde, müssen nun die einzelnen Testbereiche identifiziert und die daraus resultierenden Parameter gefunden werden. Das
Testsystem sollte auf die Frage, ob die Eigenschaften und Funktionen der PSA korrekt funktionieren, eine Antwort liefern können. In diesem Zusammenhang bezeichnet ein Testbereich
eine Komponente beziehungsweise ein Bestandteil von Symbian OS oder der PSA. Ein Parameter bezeichnet hier eine Eigenschaft oder auch ein Merkmal des spezifischen Testbereichs.
Im Einzelnen werden die folgenden Testbereiche unterschieden.
Certificate
Einen zentralen Punkt in der PSA-Architektur, wie auch schon in Abschnitt 2.4.1 dargestellt,
stellt der Symbian OS Software Installer dar. Der SWInstaller, wie der Symbian Software
Installer noch genannt wird, ist für die Installation neuer und Aktualisierung vorhandener
Anwendungen zuständig sowie die Verifizierung der Installationspakete und deren Inhalt. Aus
dieser wichtigen Rolle ergeben sich die ersten Testbereiche. Die Fragestellungen sind dabei,
was kann alles installiert und während der Installation ausgeführt werden. Die Frage nach dem
was installiert werden kann hängt stark von der Signierung und den benutzten Capabilities
ab. Anhand der benötigten Zertifikate zur Signierung und der benutzten Capabilities der
Anwendungen kann der erste Testbereich Zertifikate identifiziert werden. Darin kann überprüft
werden, wie das Installationspaket signiert sein muss, um die entsprechenden Capabilities
benutzen zu können. Dabei kann auch überprüft werden, ob sich die verschiedenen CapabilityGruppen (User Capabilities, System Capabilities, Device Manufacturer Capabilities) mit den
ihnen zugewiesenen Zertifikaten installieren lassen, womit sich die Funktionsweise zwischen
Capabilities und benötigten Zertifikaten verifizieren lässt.
SWInstaller
Die Frage, was alles während der Installation ausgeführt werden kann, muss in einem anderen Testbereich beantwortet werden. Für diesen Zweck habe ich den SWInstaller-Testbereich
erstellt. Der SWInstaller bietet die Möglichkeit, Dateien während der Installation mit ihren
spezifischen Anwendungen durch einen „MIME-Type“ zu verknüpfen oder ausführbare Dateien direkt zu starten. Diese Funktionen sind aber wiederum von der Vertrauenswürdigkeit der
Installationspakete abhängig, also dem Zertifikat, mit dem die Anwendung signiert wurde.
Die Parameter hier sind somit MIME-Type, Datei und Zertifikat. Damit der SWInstaller die
Dateien des Installationspaketes an die entsprechenden Stellen kopieren kann, ist der SWInstaller Teil der „Unit of Trust“ (Abschnitt 2.2.2) und besitzt die dafür benötigen Capabilities.
Diese Eigenschaft kann sich das Testsystem zu Nutze machen und versuchen, ausführbare
Dateien oder sonstige Dateien in geschützte Verzeichnisse zu kopieren. Beispielsweise könnte
dadurch eine bösartige Anwendung zusammen mit einer anderen nicht unbedingt bösartigen
Software installiert werden.
33
IDs
Symbian OS unterstützt eine Vielzahl an IDs (Abschnitt 2.4.2), die auch der SWInstaller
während der Installation überprüfen muss. IDs sind mit unterschiedlichen Funktionen und
Merkmalen verknüpft. Die einzelnen UIDs sind in verschiedene UID-Bereiche (siehe Tabelle
2.6) unterteilt. Abhängig vom verwendeten UID-Bereich wird ein vertrauenswürdiges Zertifikat benötigt. Um die korrekte Funktionsweise der Anwendungen im Zusammenhang mit den
verschiedenen IDs zu gewährleisten, kann hier ein weiterer Testbereich IDs identifiziert werden. Die einzelnen Parameter in diesem Testbereich sind die unterschiedlichen IDs, die unter
Symbian OS Version 9 zur Verfügung gestellt werden. Dabei verwendet der Testbereich UID2,
UID3, SID, VID und pUID als Parameter. Mit Hilfe dieser Parameter kann das Testsystem
die Funktionsweise der einzelnen UIDs verifizieren.
File Eclipsing
Ein Symbian OS Version 9 Mobiltelefon besitzt aufgrund der Hardware in den Standardeinstellungen, mindestens zwei Laufwerke, den schreibgeschützten ROM-Speicher und einen
beschreibbaren internen Flash-Speicher. Aufgrund dieser Tatsache kann es vorkommen, dass
eine neue Anwendung den gleichen Namen besitzt wie eine bereits installierte Anwendung im
ROM-Speicher. Diese Situation kann zu einem Konflikt während der Installation führen. Hier
hat Symbian einen Schutzmechanismus, wie in 2.4.2 beschrieben, eingeführt. Jedoch gibt es
bei Eclipsing-Situationen auch Ausnahmen, sodass diese Situationen näher untersucht werden sollten. Das Testsystem bietet einen Testbereich File-Eclipsing, um diese umschriebenen
Eclipsing-Situationen während der Installation und auch zur Laufzeit zu untersuchen. Dafür
definiert der Eclipsing-Testbereich Parameter, die es erlauben, solche Situationen herzustellen
und die dafür geltenden Regeln zu verifizieren.
File Overwriting
Neben Eclipsing-Situationen können auch Situationen auftreten in den Anwendungen versuchen, vorhandene Dateien zu überschreiben. Dies kann absichtlich durch eine Update geschehen oder unbeabsichtigt durch die Verwendung ähnlicher Dateinamen. Symbian OS verbietet
grundsätzlich das Überschreiben vorhandener Dateien, lässt aber auch Ausnahmen (Abschnitt
2.4.2) zu, beispielsweise wenn es sich um ein Update handelt. Um die Ausnahmen und die
grundsätzlichen Regeln für das Überschreiben vorhandener Dateien während der Installation
und zur Laufzeit zu verifizieren, muss das Testsystem diese Situation überprüfen können. Der
File-Overwriting-Testbereich ist genau für diesen Zweck geschaffen und bietet alle nötigen
Parameter, solche Situationen herzustellen und sie hinreichend zu testen. Die Parameter, die
diesem Testbereich zugewiesen werden konnten, bestehen aus dem Laufwerk, auf dem die Datei überschrieben werden soll, der Verzeichnisstruktur, die angibt, in welchem Verzeichnis sich
die Datei befindet und die Datei selbst, die überschrieben werden soll. Hierbei ist zu beachten,
dass die Vertrauenswürdigkeit des Paketes und die damit verbundenen Capabilities ebenfalls
zu den Parametern in diesem Testbereich gezählt werden müssen.
34
Data Caging
Nachdem alle Testbereiche, die im primären Zusammenhang mit dem SWInstaller stehen,
identifiziert werden konnten, können nun die Sicherheitsmerkmale der PSA bei erfolgreicher
Installation einer Anwendung untersucht werden. Einen zentralen Eckpfeiler innerhalb der
Software-Implementierung der PSA stellt das Data Caging (Abschnitt 2.2.4) dar. Beim Data
Caging sind bestimmte Verzeichnisse nur mit entsprechenden Capabilities zugänglich. Damit
der Zugang mit den jeweiligen Capabilities zu den entsprechenden Verzeichnissen getestet
und verifiziert werden kann, bietet das Testsystem den Data-Caging-Testbereich an. Dabei
muss der Testbereich neben einem Parameter für das geschützte Verzeichnis auch einen Parameter für die Zugriffsart bereitstellen, denn beim Data Caging wird zwischen lesendem und
schreibendem Zugriff auf Dateien innerhalb geschützter Verzeichnisse unterschieden. Damit
der Symbian-Kernel den Testfällen Zugang zu den geschützten Verzeichnissen gewähren kann,
muss der Data-Caging-Testbereich die entsprechenden Capabilities zur Verfügung stellen. Die
Capabilities werden über einen weiteren Parameter definiert.
Capabilities
Ein weiterer Eckpfeiler der Software-Implementierung der PSA, ist das Konzept der Capabilities (in Abschnitt 2.2.3 näher beschrieben). Capabilities sind Privilegien, die ein Prozess
besitzen muss, um Zugang zu geschützten Methoden und Funktionen zu bekommen. Capabilities sind sehr vielseitig und können auf unterschiedliche Weisen benutzt werden. Zunächst
sollte das Testsystem die einzelnen Capabilities auf ihr Verhalten testen können. Das bedeutet,
das Testsystem muss jede einzelne Capability verifizieren können, ob mit der entsprechenden
Capability die zugehörige Funktion ausgeführt werden kann. Hieraus ergibt sich für den Testbereich Capability der erste Parameter, die Capability selbst. Das Testsystem soll aber nicht
nur die einzelnen Capabilities verifizieren können, sondern muss auch die Capability-Regeln
überprüfen können. Die erste Regel besagt, dass sich die Capability während der Lebensdauer
eines Prozesses nicht ändert. Die zweite Regel bezieht sich auf das Verhalten der Capabilities
in Verbindung mit einer DLL (Gliederungspunkt 2.4.6) und demnach darf ein Prozess nur eine
DLL laden, wenn die DLL mindestens die Capabilities besitzt wie der Prozess auch. Neben
den Capability-Regeln sollte das Testsystem in der Lage sein, zwischen einem Prozess, der
aus einer EXE entstanden ist und einer DLL, die dynamisch zur Laufzeit geladen wird, zu
unterscheiden. Hierfür muss das Testsystem sicherstellen, dass der entsprechende Prozess die
richtige DLL lädt. Aus diesem Zusammenhang ergibt sich für den Capability-Testbereich ein
weiterer Parameter, der die Art der Testanwendung spezifiziert und festlegt, ob es sich dabei
um einen Prozess, der aus einer EXE entstanden ist, oder ob es sich um eine DLL handelt.
Capabilities können aber auch zusammen mit dem Client/Server-Konzept verwendet werden.
Hierfür sollte das Testsystem Parameter bereitstellen, die es ermöglichen sollten, Capabilities
sowohl für Server als auch für Clients spezifizieren zu können. Dadurch sollte das Zusammenspiel zwischen Client und Server unter Verwendung definierter Capabilities verifiziert werden.
Der Parameter, der die Art der Testanwendung definiert, muss angepasst werden, um das
Client/Server-Konzept ebenfalls zu unterstützen.
35
Shared-Data
Durch die Symbian Version 9 Architektur können Prozesse nicht auf Adressbereiche anderer
Prozesse zugreifen. Die Hardware in Form der MMU würde das nicht zulassen. In manchen
Situationen ist es jedoch von Vorteil, dass Prozesse dennoch Daten untereinander austauschen können. Neben den Client/Server-Konzept bietet Symbian weitere Konzepte, die den
sicheren Austausch von Daten gewährleisten. Das Testsystem sollte die Möglichkeit besitzen,
eine ausgewählte Menge dieser Konzepte zum sicheren Datenaustausch prüfen zu können.
Hier implementiert das Testsystem die drei Konzepte Publish & Subscribe, File Handle und
Data Chunk. Beim Publish & Subscribe können systemweite Variablen definiert werden, auf
die ein Prozess nur zugreifen darf, wenn er die dafür benötigten Zugriffsrechte besitzt. Dabei
sollte ein Prozess die Zugriffsrechte der Variablen in Form von Capabilities definieren. Abhängig von den Bedürfnissen der Prozesse sollte dieser unterschiedliche Capabilities jeweils
zum Lesen oder Schreiben der Variablen definieren können. Besitzt ein Prozess die benötigten
Capabilities, kann er lesend beziehungsweise schreibend auf die Variablen zugreifen. Beim File
Handle öffnet ein Prozess eine Datei in einem speziellen, gemeinsamen Modus, der es anderen
Prozessen erlaubt, lesend auf die Datei zuzugreifen. Beim Data Chunk können Speicherregionen von mehreren Prozessen genutzt werden, wenn der Data Chunk als global definiert
wird. Diese drei Konzepte können in der Praxis auch miteinander kombiniert werden. Das
Testsystem soll aber nur die Grundfunktionalität der einzelnen Konzepte zeigen, sodass auf
die sicheren Kombinationsmöglichkeiten geschlossen werden kann. Um die Funktionsweise der
verschiedenen Konzepte zu verifizieren, wurde der Shared-Data-Testbereich erstellt. Der Testbereich muss dabei Parameter für die unterschiedlichen Konzeptarten und die Definition der
Capabilities für Lese- und Schreibrechte zur Verfügung stellen. Ein weiterer Parameter sollte
den Prozesstyp definieren können. Mit Prozesstyp wird der Unterschied zwischen einem Prozess, der beispielsweise eine Datei für andere Prozesse im Lesemodus bereitstellt und einem
Prozess, der diese Datei nur benutzt, beschrieben.
Integrity
In Symbian OS Version 9 werden Anwendungen, die auf dem internen Flash-Laufwerk gespeichert werden, durch das Data Caging geschützt. Die EXE-Dateien sind in \sys\bin durch
Device Manufacturer Capabilities geschützt, sodass weder lesend noch schreibend auf die
Dateien ohne entsprechende Zugangsrechte zugegriffen werden kann. Das Gleiche gilt für Dateien in \private\<ownSID>, diese sind für andere Prozess nur durch Device Manufacturer
Capabilities zugänglich. Die Ressourcen-Dateien der Anwendungen sind im \resource vor
schreibendem Zugriff geschützt. Die Integrität der Daten ist somit auf dem internen FlashSpeicher gegeben. Was ist jedoch mit Anwendungen, die auf einer Speicherkarte installiert
wurden? Hier speichert Symbian einen Hash der EXE-Datei auf dem internen Flash-Speicher
in \sys\hash und kann somit die Integrität der EXE-Datei gewährleisten. Das Testsystem
müsste also Parameter bereitstellen, die es ermöglichen, die Integrität der Daten sowohl auf
dem internen Laufwerk, das durch das Data Caging geschützt ist, als auch auf der Speicherkarte, die außerhalb des Mobiltelefons nicht durch das Data Caging geschützt ist, zu
verifizieren.
36
API
Eine weitere Anforderung an das Testsystem, das zur Verifikation der Funktionsweise benutzt
werden kann, stellt das „Black-Box-Testen“ [12] dar. Das Testsystem sollte eine grundlegende
Funktionalität besitzen, Methoden auf ihren erwarteten Rückgabewert zu testen. Im APITestbereich werden dafür Parameter angeboten, mit deren Hilfe sich Eingabe- und erwartete
Rückgabewerte für die zu testende Methode definieren lassen.
Im vorherigen Abschnitt habe ich die Parameter der einzelnen Testbereiche erläutert und wie
die gefundenen Parameter genutzt werden können, um die korrekte Funktionsweise der PSA
zu verifizieren. Dieser Abschnitt beschäftigt sich mit den Konfigurationsmöglichkeiten, die den
Mobiltelefonherstellern und auch teilweise dem Benutzer überlassen werden, aber auch wie
diese Konfigurationsmöglichkeiten Einfluss auf das Testsystem nehmen.
3.2.1. SWIPolicy
Bevor eine Anwendung installiert werden kann, muss der SWInstaller zunächst die Einstellungen mit den eigenen Richtlinien der SWIPolicy im ROM-Speicher prüfen, um festzustellen,
wie die Installation fortgesetzt werden kann. Die SWIPolicy wird vor der Auslieferung von den
Mobiltelefonherstellern konfiguriert und enthält zahlreiche Einstell- und Konfigurationsmöglichkeiten. Die relevanten Konfigurationsmöglichkeiten der SWIPolicy werden im Folgenden
kurz mit ihrer Bedeutung für das Testsystem erläutert.
• AllowUnsigned=[true|false]
Hier kann der Mobiltelefonhersteller festlegen, wie mit nicht signierten Installationspaketen verfahren wird. Bei true werden nicht signierte Pakete als Installationskandidaten
betrachtet, wohingegen bei false der SWInstaller die Installation verweigert. Hier ist
aber auch zu bemerken, falls das „root“-Zertifikat als MANDATORY im „SWI Certification
Store“ markiert ist, wird selbst bei AllowUnsigned=true die Installation fehlschlagen,
wenn das Installationspaket nicht mit einem nachweisbaren Anwendungszertifikat signiert wurde.
• MandateCodeSigningExtension=[true|false]
Abhängig von dieser Einstellung muss das Zertifikat, mit dem die Anwendung signiert
wurde, die „X.509 code signing“-Erweiterung [13] besitzen.
• MandatePolicies=[true|false]
Diese Einstellung kann benutzt werden, damit alle nicht „root“-Zertifikate in der Signierungskette zumindest eine OID enthalten, die in der OID-Liste angegeben wurde.
Ansonsten kann die Anwendung nicht installiert werden, wenn der entsprechende private
Schlüssel, mit dem die Anwendung signiert wurde, die OID nicht enthält. Das Zertifikat
muss mit der „X.509 extended key usage“-Erweiterung, die die spezifizierte OID enthält,
signiert sein.
37
• Oid=Wert
Oid-Liste, die bei MandatePolicies=true definiert sein muss.
• OcspEnabled=[true|false]
Hier kann der Hersteller festlegen, ob OSCP während der Installation durchgeführt
werden soll.
• OcspMandatory=[true|false]
Ist die OSCP-Prüfung eingeschaltet, muss das Ergebnis der Prüfung bei OcspMandatory=
true erfolgreich ausfallen, damit die Installation fortgeführt werden kann.
• AllowGrantUserCapabilities=[true|false]
Hier kann der Hersteller festlegen, ob der Benutzer User-Capabilities gewähren kann.
• UserCapabilities=UserCapability-Liste
Liste der Capabilities, die der Benutzer während der Installation gewähren kann, wenn
AllowGrantUserCapabilities=true.
• AllowOrphanedOverwrite=[true|false]
Mit dieser Einstellung kann der Mobiltelefonhersteller festlegen, ob der Benutzer gefragt
werden soll, „verwaiste“ Dateien in öffentlichen Verzeichnissen während der Installation
überschreiben zu dürfen. Eine Datei wird als verwaist bezeichnet, wenn sie zu keinem
installierten Paket gehört oder sonst nicht durch den SWInstaller registriert wurde.
• AllowProtectedOrphanOverwrite=[true|false]
Ist diese Einstellung auf true und AllowOrphanedOverwrite ebenfalls auf true gesetzt,
wird der SWInstaller erlauben, verwaiste Dateien in privaten Verzeichnissen (\private
\xxxxxxxx\import, \resource oder \sys\bin) zu überschrieben oder diese in eine
Eclipsing-Situation zu bringen.
• RunWaitTimeoutSeconds=Wert
In einem Installationspaket kann festgelegt werden, dass eine Anwendung während der
Installation ausgeführt wird. RunWaitTimeoutSeconds gibt dabei die Periode an, wie
lange gewartet werden soll, bis die Anwendung vom SWInstaller geschlossen wird, bevor
die Installation fortgeführt wird. Bei einem Wert von -1, wartet der SWInstaller bis die
Anwendung geschlossen wird. Das bedeutet, wenn die Anwendung nicht beendet wird,
würde der SWInstaller „hängen“ bleiben.
• AllowRunOnInstallUninstall=[true|false]
Der Hersteller kann hier festlegen, ob nicht vertrauenswürdige Anwendungen FILERUN(FR)
oder FILEMIME(FM) Anweisungen ausführen dürfen.
• ReplacePath
Erlaubt dem Hersteller, den Installationspfad während der Installation auf einen neuen
Pfad abzubilden.
3.2.2. SWInstaller-Einstellungen
Neben der SWIPolicy, die von den Mobiltelefonherstellern konfiguriert wird, besitzt der Benutzer auch Einstellmöglichkeiten, das Verhalten des SWInstallers zu beeinflussen. Die Einstellungen sind begrenzt und bieten dem Benutzer lediglich drei Möglichkeiten. Dabei kann
38
3.3. Erfassung der Vollständigkeit
angegeben werden, ob jede Software oder nur signierte Software installiert werden kann. Weiter
kann die Online-Zertifikatsprüfung (OCSP) ein- beziehungsweise ausgeschaltet oder erst nach
Bestätigung zugelassen werden. In der letzten Einstellung kann eine Standard-Web-Adresse
für die Online-Zertifikatsprüfung angegeben werden. Bei diesen Benutzereinstellungen ist jedoch fraglich, welche Einstellungen bei einem Konflikt zwischen den Benutzereinstellungen
und der SWIPolicy bevorzugt werden.
3.2.3. Bedeutung für das Testsystem
Die beiden Konfigurationsmöglichkeiten sowohl für Mobiltelefonhersteller mittels SWIPolicy
oder Benutzer über die SWInstaller-Einstellungen können nur indirekt auf das Testsystem
einwirken. Das Testsystem nimmt diese Konfigurationsmöglichkeiten als gegeben an. Vor jedem Testlauf können die Konfigurationsmöglichkeiten protokolliert und sinnvoll verändert
werden. Bei den SWInstaller-Einstellungen ist dies auch problemlos möglich. Das Verändern
der SWIPolicy stellt theoretisch eine größere Hürde dar aufgrund der Tatsache, dass sich die
SWIPolicy im schreibgeschützten ROM-Speicher befindet. Praktisch gibt es durchaus Möglichkeiten, die SWIPolicy zu Testzwecken zu verändern. Hierfür werden zwei Methoden im
Kapitel 7 vorgestellt. Mit diesen „passiven“ Parametern kann der Frage aus Abschnitt 3.2.2
nach der Priorisierung der beiden Einstellmöglichkeiten hinreichend nachgegangen werden.
3.3. Erfassung der Vollständigkeit
Dieser Abschnitt soll die Vollständigkeit des Testsystems zeigen, wie die einzelnen Testbereiche
die Funktionen und Möglichkeiten der PSA abdecken.
3.3.1. Testbereich
Die gesamte PSA-Architektur kann in drei Punkte unterteilt werden, die Hardware-Unterstützung, die Software-Implementierung und das Zertifizierungsprogramm von Symbian Signed.
Zusammen mit der MMU bildet die Hardware die Basis der PSA und ist somit Teil der Unit of
Trust. Die Software-Implementierung der PSA umfasst dabei den größten zu untersuchenden
Bereich. Hier müssen weiterhin die drei Hauptbestandteile der PSA-Implementierung betrachtet werden. Im Einzelnen den Kernel zusammen mit dem „File-Server“ und dem SWInstaller,
dem Data Caging sowie den Capabilities. Der Kernel als vertrauenswürdige Komponente der
Unit of Trust ist für die Integrität des Systems und die Speicherverwaltung verantwortlich.
Kein Prozess darf ohne die entsprechenden Privilegien in einen Adressraum eines anderen
Prozesses schreiben. Im Gegenzug ist der SWInstaller als weitere Komponente der Unit of
Trust für die korrekte Installation zusätzlicher Anwendungen sowie die Aktualisierungen von
vorhandenen Anwendungen zuständig. Das Data Caging als zweiter Hauptbestandteil beinhaltet neben dem Zugang zu geschützen Verzeichnissen mit entsprechenden Privilegien auch
die damit verbundenen Möglichkeiten, Dateien zu überschreiben oder durch andere Dateien
Eclipsing-Situationen hervorzurufen. Der dritte Hauptbestandteil der PSA-Implementierung
ermöglicht Prozessen, auf geschützte Ressourcen zuzugreifen. Capabilities können in Verbindung mit vertrauenswürdigen beziehungsweise mit nicht vertrauenswürdigen DLL überprüft
werden. Das Zertifizierungsprogramm von Symbian Signed umfasst neben der Vergabe von
39
Zertifikaten verschiedene Möglichkeiten, Anwendungen zu signieren. Die dabei angebotenen
Verfahren Open Signed, Express Signed und Certified Signed sind in den Grundlagen Abschnitt 2.2.5 kurz beschrieben. In den verschiedenen Signierungsverfahren sind entsprechende
Testkriterien definiert, die eine Anwendung bestehen muss, bevor sie mit dem jeweiligen Zertifikat signiert werden kann. Aber auch die Verwaltung und Vergabe der entsprechenden UIDs
ist Aufgabe von Symbian Signed.
All diese Komponenten mit ihren jeweiligen Merkmalen und Funktionen definieren das vollständige PSA-System. Abbildung 3.2 verdeutlicht diesen Zusammenhang. Jeder Kreis in der
Abbildung ist als Menge der damit verbundenen Funktionen und Regeln der jeweiligen Komponente definiert. Das Testsystem ist dabei als Teilmenge des vollständigen PSA-Systems
dargestellt.
Abbildung 3.2.: Vollständiges PSA-System
3.3.2. Testbarkeit gegen wirklich getestet
In Abbildung 3.2 wird deutlich, dass das Testsystem nicht das vollständige PSA-System umfassen kann, sondern nur eine Teilmenge bildet. Dabei sind einige Komponenten des PSASystems vollkommen im Testsystem enthalten und andere bilden hingegen nur eine Teilmenge
der Komponenten. Schon bei der Komponente Symbian Signed ist erkennbar, dass nur ein Teil
dieser Komponente im Testsystem enthalten ist. Das ist dadurch zu erklären, dass Symbian
Signed verschiedene Zertifizierungsprogramme anbietet, das Testsystem aber nur die „freien“
Zertifizierungsprogramme benutzt. Das bedeutet, es kann nur Open Signed und ein auf mich
ausgestelltes Developer-Zertifikate benutzt werden. Das Developer-Zertifikat habe ich noch
vor der Einführung von Open Signed erlangen können. Die Komponente, die das Data Caging
darstellt, umfasst nicht nur den Data-Caging-Testbereich, sondern beinhaltet auch Testfälle
40
3.4. Mehrdeutigkeiten der Spezifikation
zum File Eclipsing und zum File Overwriting. Dadurch kann der Data-Caging-Testbereich
alle Möglichkeiten, die benötigt werden, zur Verfügung stellen, sodass diese Komponente des
PSA-Systems untersucht werden kann. Auch die teilweise durch Device Manufacturer Capabilities geschützten Verzeichnisse können mit einem Trick aus Kapitel 7 untersucht werden.
Die PSA stellt insgesamt 20 Capabilities bereit und definiert die damit verbundenen Regeln.
Im Testsystem ist der Capability-Testbereich definiert worden, indem die Capability-Regeln,
die Verwendung der einzelnen Capabilities und die Capabilities im Zusammenhang mit DLLDateien getestet werden können. Der Kernel als Komponente der Unit of Trust kann nur
teilweise durch die Testbereiche abgedeckt werden. Neben der indirekten Untersuchung des
„File-Servers“ durch den Data-Caging-Testbereich, stellt das Testsystem einen Testbereich
für die Untersuchung der Integrität entsprechender Dateien zur Verfügung. Im Shared-DataTestbereich können die vom Kernel zur Verfügung gestellten Konzepte, die den Datenaustausch zwischen Prozessen ermöglichen, untersucht werden. Der SWInstaller als weitere Komponente der Unit of Trust, kann hingegen vollkommen vom Testsystem untersucht werden.
Durch die in Kapitel 7 zur Verfügung gestellten Mittel, kann sowohl die SWIPolicy als auch
mit einem vertrauenswürdigen Zertifikat die entsprechende Funktionalität getestet werden.
Die Hardware-Unterstützung der MMU kann nur indirekt über die Software-Implementierung
untersucht werden. In der Implementierung der Symbian APIs sind nur 40 Prozent der APIs
durch Capabilities geschützt. Das Testsystem implementiert nicht zu jeder geschützten API
einen Testfall, sodass in der Grundkonfiguration des Testsystems nur ein ausgewählter Teil der
geschützten APIs mit ihren jeweiligen Capabilities untersucht werden kann. Jedoch kann das
Testsystem, wenn die entsprechende Konfigurationsdatei erstellt werden kann, die gesamten
APIs, die durch Capabilities geschützt sind, überprüft werden.
Schließlich kann das PSA-Testsystem aus den oben geschriebenen Komponenten nur als Teilmenge des vollständigen PSA-Systems definiert werden.
3.4. Mehrdeutigkeiten der Spezifikation
Bevor die Frage nach Mehrdeutigkeiten in der Spezifikation der PSA beantwortet werden
kann, muss zunächst definiert werden, was als Spezifikation der PSA betrachtet werden kann.
Symbian bietet zahlreiche Dokumentationen, die einen schnellen Einstieg in die Entwicklung
von Symbian OS Version 9 Anwendungen ermöglichen. Es gibt viele Artikel, „White Paper“
und Kapitel in verschiedenen Entwicklungsbüchern für Symbian OS, die einen guten Überblick
über die PSA bieten. Jedoch keine dieser Quellen kann eine detaillierte Spezifikation der PSA
liefern. „Symbian OS Platform Security“ [1] gibt eine gute Beschreibung der PSA und wie
Anwendungen für diese Plattform entwickelt werden können. Dieses Buch soll hier als Referenz
für die Spezifikation der PSA dienen.
Ein Problem bei der Beurteilung der Mehrdeutigkeit sind die unterschiedlichen „Software
Development Kits (SDK)“. Neben den öffentlich zugänglichen SDKs existieren weitere Symbian OS SDKs [14]. Diese SDKs sind für Mobiltelefonhersteller gedacht und nicht öffentlich
zugänglich. Mit den verschiedenen SDKs unterscheiden sich auch die Dokumentationen. Beispielsweise wird in „Symbian OS Changes for Platform Security“ [15] auf Methoden verwiesen,
die in den öffentlichen SDKs nicht dokumentiert und auch nicht vorhanden sind.
41
In der Beschreibung der SWIPolicy [16, 17] werden die Parameter vorgestellt, die die Mobiltelefonhersteller nutzen können, um das Installationsverhalten zusätzlicher Software zu konfigurieren. Die einzelnen Parameter sind teilweise mit Beispielen erklärt, lassen aber dennoch
Spielraum für Interpretationen. Ein Beispiel ist die Beschreibung über die Markierung des
root-Zertifikats als MANDATORY. Es wird nicht definiert, was MANDATORY in diesem Zusammenhang bedeutet. Es kann jedoch sein, dass diese Information in der Dokumentation der nicht
öffentlichen SDKs beschrieben ist. Ein weiteres Beispiel ist die Aussage, dass falls das rootZertifikat als MANDATORY markiert ist, Anwendungen nur installiert werden können, wenn sie
mit einem „nachweisbaren“ Anwendungszertifikat signiert wurden. Hier ist unklar, was mit
„nachweisbar“ gemeint ist. Es kann sich dabei um ein Developer-Zertifikat oder ein Zertifikat,
das von Symbian Signed ausgestellt wurde, handeln. Ob dabei auch selbst signierte Zertifikate oder Zertifikate von anderen Zertifizierungsstellen benutzt werden können, ist ebenfalls
fraglich. Diese beiden Beispiele zeigen, dass diese Spezifikation der SWIPolicy nur dokumentierenden Charakter hat.
Weitere Mehrdeutigkeiten ergeben sich in der API-Dokumentation für die einzelnen Funktionen, die durch Capabilities geschützt sind. In der API-Dokumentation des öffentlichen SDKs
existiert in den Versionen 9.1 und 9.2 ein Dokument „Funktionen nach Capabilities gelistet“
[18, 19], das die einzelnen Funktionen nach ihren Capabilities auflistet. In diesem Dokument sind Funktionen mit anderen Capabilities verzeichnet als sie in der API-Dokumentation
definiert sind. Ein Beispiel ist dabei die Funktion Open aus der Klasse RRawDisk. In dem
Dokument „Funktionen nach Capabilities gelistet“ wird die DiskAdmin Capability für diese
Funktion gefordert. In der API-Dokumentation ist diese Funktion jedoch mit der Tcb Capability angegeben.
Die Beispiele zeigen, dass die Dokumentation und teilweise die Spezifikation viel Raum für
Interpretationen lässt. Größtenteils führen die Mehrdeutigkeiten jedoch zu keinen größeren
Fehlern. In den meisten Fällen bedeuten sie mehr Aufwand bei der Definition der Testfälle.
Hier muss überlegt werden, was die entsprechende Definition ausdrücken möchte, sodass aus
der Ungewissheit über die Definition mehr Testfälle resultieren. Im schlimmsten Fall kann ein
Capability-Test fehlschlagen, obwohl gemäß der API-Definition die entsprechende Capability
gewählt wurde, aber tatsächlich der Zugriff auf die jeweilige Ressource aufgrund mangelnder
Capability verweigert wird.
42
4. Testsystem
Im vorherigen Kapitel wurde die Architektur des PSA-Testsystems eingeführt sowie die Parameter, die das Testsystem zur Verifikation der PSA bereitstellt. Dieses Kapitel beschreibt die
Implementierung des Testsystems und die einzelnen Testbereiche. Der letzte Abschnitt zeigt
schließlich, wie die Testfälle definiert werden müssen, um die beschriebene Konfiguration zu
verifizieren.
4.1. Beschreibung der Implementierung
Dieser Abschnitt erläutert die Implementierung des PSA-Testsystems. Dafür werden zunächst
zwei DLL vorgestellt, mit deren Hilfe die Testfälle ihre Ergebnisse protokollieren können.
Anschließend werden die einzelnen Komponenten des PSA-Testsystem genauer beschrieben.
4.1.1. File-Logger
Eine erste Anforderung, die an das PSA-Testsystem gestellt wurde, ist die Möglichkeit, den
Ablauf der Testfälle zu protokollieren. Damit die Testfälle am Ende ausgewertet werden können, sollte eine aussagekräftige Log-Datei mit den einzelnen Schritten, die die Anwendung
ausgeführt hat beziehungsweise mit den Fehlern, die aufgetreten sind, entstehen. Für diesen
Zweck habe ich unter Zuhilfenahme eines Beispiels im Nokia Forum [20] eine Anwendung zum
flexiblen Protokollieren geschrieben. Der File-Logger ist als DLL realisiert, damit nicht jeder
Testfall seinen eigenen File-Logger implementieren muss, kann so die Forderung nach einem
Testsystem mit möglichst wenig Redundanz gewahrt werden. Für die einzelnen Testbereiche
stellt der File-Logger verschiedene Funktionen bereit, die die Testfälle nutzen können, um
die relevanten Informationen über den aktuellen Testfall in einer Textdatei zu protokollieren.
Der File-Logger unterstützt nicht nur die Funktion einfachen Text zu protokollieren, sondern
auch Protokolleinträge mit mehreren Parametern zu erstellen. Dabei kann der File-Logger
einen Eintrag erst bei einem Fehler protokollieren oder der Protokolleintrag wird vor und
nach einem Funktionsaufruf erstellt. Während der Durchführung der Testfälle ist im Zusammenhang mit dem File-Logger aufgefallen, dass der File-Logger nicht mit Testfällen, die die
Tcb Capability benutzen, verwendet werden konnte. In der Grundimplementierung benutzt
der File-Logger weitere Bibliotheken, die jedoch nur mit den All -Tcb Capabilities ausgestattet sind. Das bedeutet die Bibliotheken besitzen alle Capabilities, außer der Tcb Capability.
Aufgrund der Capability-Regeln kann der Standard File-Logger nicht mit Testfällen, die die
Tcb Capability benutzen, verwendet werden. Deshalb wurde zusätzlich der OwnFile-Logger
entwickelt, der keine weiteren Bibliotheken benutzt und aus diesem Grund selbst mit der Tcb
Capability verwendet werden kann. Der OwnFile-Logger stellt dabei fast die gleiche Funktionalität wie der File-Logger zur Verfügung.
43
4. Testsystem
4.1.2. Testsystem
Das Testsystem besteht, wie in Kapitel 3 beschrieben, aus vier Komponenten. Einer Konfigurationsdatei für die einzelnen Testfälle, einen Code-Builder für die Generierung des Quellcodes
sowie einen Package-Creator, der das Installationspaket erstellt und auf der anderen Seite
einen Emu-Builder, der die Testfälle für den Emulator ausführbar macht.
Die Konfigurationsdatei ist der zentrale Punkt des gesamten PSA-Testsystems. Mit ihr kann
eine individuelle „Testsuite“ zusammengestellt werden. Es kann zunächst gewählt werden, ob
die resultierenden Testfälle für das Mobiltelefon oder für den Emulator erstellt werden sollen.
Dabei muss aber beachtet werden, dass eine geeignete Symbian OS SDK Version gewählt
wird. Das Testsystem unterscheidet zwischen den Symbian OS SDK Versionen 9.1, 9.2 und
9.3. Weiterhin besteht die Möglichkeit, entweder einen bereits spezifizierten Testfall zu wählen
oder es kann ein Testfall völlig eigenständig gestaltet werden. Die fest vordefinierten Testfälle
sind jeweils einem Testbereich zugeordnet, der sich aus den Eigenschaften und Merkmalen
der PSA ableitet. Als Beispiel für einen Testbereich sei hier das Data Caging genannt. Das
Data Caging definiert sich durch die Eigenschaft, dass Dateien in geschützten Verzeichnissen nur mit entsprechenden Capabilities gelesen beziehungsweise geschrieben werden dürfen.
Der Testfall für das Data Caging benötigt somit nach den Anforderungen in 3.1 Parameter für Capabilities, Pfadangaben und Zugriffsarten. Das Testsystem löst die Definition der
Merkmale für die einzelnen Testfälle durch die Angabe von Schlüsselwörtern. Demnach ist ein
Schlüsselwort der angeleitete Parameter der Anforderung für den Testbereich. Der Quelltext
4.1 zeigt die vollständige Spezifikation eines Data-Caging-Testfalls. Im Beispiel für das Data
Caging ergeben sich die Schlüsselwörter Capability, Drive, Path und Access sowie ein weiteres Schlüsselwort Signed für die Art der Signierung des Installationspaketes. Um nun einen
Testbereich zu definieren, muss dieser erst nach dem Schlüsselwort TestFields deklariert
werden. Mehrere Testbereiche werden ohne Leerzeichen durch ein Komma getrennt. Sind nun
die Testbereiche deklariert, müssen die Testfälle nur noch durch die jeweiligen Schlüsselwörter
der Testbereiche definiert werden.
Quelltext 4.1: Beispiel für einen Data-Caging-Testfall
Platform : real
SDK Version : 9 . 1
Test Fields : Data - Caging
Data - Caging {
Capability : ReadDeviceData ReadUserData
Access : read
Drive : C
Path : \\ private
Signed : self
--}
Jeder vordefinierte Testbereich ist durch seine eigenen Schlüsselwörter definiert. Für eine detaillierte Beschreibung zur Definition der Konfigurationsdatei siehe A.1. Es können aber auch
44
4.1. Beschreibung der Implementierung
individuelle Testbereiche definiert werden, indem in TestFields die Testbereiche durch Angabe ihrer Namen deklariert werden. Anschließend müssen die Testbereiche nur noch durch die
gewünschten Schlüsselwörter definiert werden, wobei dann alle Schlüsselwörter des gesamten
Systems verwendet werden können. Darüber hinaus müssen aber auch einige Regeln beachtet
werden. Ein Beispiel ist, es darf nur dann ein Update (SA, PU, SP) definiert werden, wenn zuvor schon eine SA-Anwendung mit der Versionsnummer 1,0,0 definiert wurde. Weitere Regeln
und Hinweise zur Konfigurationsdatei sind im Anhang A.2 aufgeführt.
Nachdem die einzelnen Testfälle spezifiziert und die Konfigurationsdatei erstellt wurde, übernimmt der Code-Builder die Konfigurationsdatei, um den Quellcode zu generieren. Die Abbildung 3.1 im Kapitel 3 verdeutlicht den Aufbau des PSA-Testsystems. Der Code-Builder ist
dafür verantwortlich, die unterschiedlichen Anforderungen der Testfälle zu erfüllen sowie deren
Spezifikation zu gewährleisten. Die Idee hinter dem Code-Builder ist leicht nachvollziehbar.
Vorgeschriebene Quellcode-Fragmente in Symbian C++ werden in geeigneter Art und Weise
sowie mit möglichst wenig Redundanz so ineinander gefügt, dass ein syntaktisch korrektes
und sinnvolles Projekt entsteht.
Der Code-Builder wurde mit Hilfe von Perl aufgrund der mächtigen Art, mit regulären Ausdrücken umzugehen, geschrieben. Um alle Anforderungen der Testbereiche zu erfüllen, mussten zunächst separate Projekte zu jedem Testtyp in Symbian C++ geschrieben werden. Mit
Hilfe des Code-Builders musste zu jedem Testbereich der Quellcode nur für einen Testfall
geschrieben werden, wodurch sich die Fehleranfälligkeit auf nur eine zentrale Stelle eines Testbereichs reduzierte. Die herkömmliche Methode hätte für jeden Testfall neuen Quellcode zur
Folge, der größtenteils dem Ausgangsquellcode identisch wäre. Da sich die Testfälle eines Testbereichs relativ ähneln, wäre man geneigt „Copy & Paste“ zu verwenden. Hätten sich jedoch
im Ausgangsquellcode Fehler eingeschlichen, könnte es passierten, dass die Fehler in den kopierten Quellcodes unentdeckt blieben, was im schlimmsten Fall schwerwiegende Folgen hätte.
Genau mit diesem Verhalten ist beim Code-Builder nicht zu rechnen. Denn, ist nun der BasisQuellcode für den einzelnen Testbereich korrekt implementiert und ohne Programmierfehler,
so kann davon ausgegangen werden, dass der resultierende, richtig zusammengefügte Code
wieder korrekt und ohne zusätzliche Programmierfehler ist.
Der Package-Creator erstellt aus den Quelldateien, die der Code-Builder generiert hat, ein
Installationspaket, das auf Symbian OS v9 Geräten installiert werden kann. Jedoch tritt der
Package-Creator nur in Aktion, wenn das Schlüsselwort Platform auf real gesetzt ist. Damit
das Installationspaket erstellt werden kann, muss der Package-Creator zunächst die richtige
SDK Version auswählen. Die SDK Version wird durch das Schlüsselwort SDK Version definiert. Wie oben erwähnt, kann dabei zwischen „S60 3rd Edition SDK Maintenance Release“,
das die Version 9.1 darstellt, „S60 3rd Edition SDK mit Feature Pack 1“, das die Version 9.2 widerspiegelt und „S60 3rd Edition SDK mit Feature Pack 2“, das Version 9.3 definiert, gewählt
werden. Mit dieser Information kann der Package-Creator schließlich die Kompilierung mit
der richtigen Version des SDKs beginnen. Entstehen keine Fehler beim Kompilieren, so kann
der Package-Creator das Installationspaket erstellen. Hierfür benötigt der Package-Creator
noch einige Informationen, die in der Konfigurationsdatei für das PSA-Testsystem spezifiziert wurden. Für die meisten Testfälle wird ein Zertifikat benötigt, mit dem die SIS-Datei
signiert wird. Entsprechend dem Schlüsselwort Signed wird das richtige Zertifikat gewählt
und das Installationspaket damit signiert. Das PSA-Testsystem benutzt dabei ein selbst erstelltes Zertifikat, ein Developer-Zertifikat, das für das Nokia E61 ausgestellt und auf die IMEI
beschränkt ist, und ein Zertifikat, das ich „root“-Zertifikat nenne. Das „root“-Zertifikat ist in
45
4. Testsystem
Kapitel 7 näher beschrieben. Weiter benötigen viele Tests auch die Definition von Capabilities,
die mit Capability spezifiziert werden können. Im Testbereich für die einzelnen IDs können
diverse IDs (SID, UID3, VID, pUID) getestet werden, sodass der Package-Creator auch diese
Information berücksichtigen muss.
Der Emu-Builder ist das Gegenstück zum Package-Creator. Er erstellt die nötigen Dateien
zur Ausführung im Emulator, benötigt aber die identischen Informationen wie der PackageCreator mit Ausnahme von emu im Platform Schlüsselwort, das dem Testsystem Emulator
Testfälle signalisiert. Die Aufgabe des Emu-Builders gestaltet sich aber im Vergleich zum
Package-Creator einfacher. Der Emu-Builder muss keine Installationsdatei erstellen, sondern
lediglich die Testfälle für die Emulator-Plattform kompilieren und die entstehenden Dateien
an die richtige Stelle kopieren.
4.2. Beschreibung der Testfälle
In diesem Abschnitt werden die einzelnen Testbereiche des PSA-Testsystems beschrieben. Anschließend wird in jedem Testbereich die Beschreibung anhand eines Beispiels verdeutlicht.
4.2.1. Data Caging
Ein wesentlicher Baustein der PSA ist das Data Caging. Ist im Data Caging ein Fehler oder
eine Lücke, ist das ganze System betroffen. Der Data-Caging-Testbereich stellt hierfür die
Schlüsselwörter Capability, Signed und die für diesen Test besonders wichtigen Schlüsselwörter Drive, Path und Access. Mit Hilfe von Capabilities sowie der Angabe von mehreren
Laufwerken, Pfaden und der Zugriffsart ist es möglich festzustellen, ob die geschützten Verzeichnisse nur mit den definierten Capabilities und dem definierten Zugang zugänglich sind.
Dabei erstellt der Code-Builder ein simples GUI-Framework für den Testfall. Weiter erzeugt
der Code-Builder für jede Kombination aus angegebenem Pfad und Laufwerk einen kleinen
Testfall. Wurde beispielsweise \\private im Path angegeben, so erweitert der Code-Builder
die Pfadangabe mit der SID der Anwendung. Soll hingegen ein privates Verzeichnis eines
anderen Prozesses getestet werden, so muss der Pfad die entsprechende SID enthalten, die
in der Konfigurationsdatei angegeben wurde. Bei \\private\\EHome wird der Test direkt im
\private-Verzeichnis durchgeführt. Der einzelne Test versucht, abhängig von der Spezifikation
des Tests, eine Datei bei schreibendem Zugriff auf das angegebene Laufwerk mit entsprechendem Pfad zu erstellen und einen kurzen Text in diese Datei zu schreiben. Bei lesendem Zugriff
versucht der einzelne Testfall in dem angegebenen Verzeichnis den Inhalt einer Datei zu lesen.
Abhängig von der Capability, dem Pfad und der Zugriffsart auf das entsprechende Verzeichnis
wird der Test erfolgreich ausfallen oder nicht. In beiden Fällen wird eine Log-Datei angefertigt, die den Verlauf des Tests protokolliert. Diese daraus resultierenden Testfälle werden in
das GUI-Framework integriert und mit den angegebenen Capabilities dem Package-Creator
oder dem Emu-Builder übergeben. Ein Beispiel für die Definition eines Data-Caging-Testfalls
wurde schon bei der Beschreibung des Testsystems im Quelltext 4.1 gegeben.
46
4.2.2. File Eclipsing
Die File-Eclipsing-Tests sollen die Eclipsing-Situationen untersuchen, die unter Umständen bei
Installationen neuer Anwendungen oder bei Updates/Patches bestehender Software entstehen
können. In diesem Testbereich stehen zahlreiche Schlüsselwörter zur genauen Spezifikation der
Tests, um die entsprechenden Situationen zu untersuchen, zur Verfügung. Dabei stehen die
schon bekannten Schlüsselwörter Capability, Signed, Drive und Path zur Verfügung. Hier
aber unterscheidet sich die Funktionsweise der Schlüsselwörter Drive und Path zum Data
Caging. Mit einem weiteren Schlüsselwort File kann genau definiert werden, welche Datei an
welcher Stelle durch die angegebene Datei „überschattet“ werden soll. Während beim Data
Caging alle Kombinationen aus Path und Drive ausgeführt werden, wird beim File Eclipsing
der komplette Dateipfad in der angegebenen Reihenfolge aus Drive, Path und File gebildet.
Soll die Eclipsing-Situation bereits während der Installation der Testanwendung erzwungen
werden, muss zunächst das Schlüsselwort AtInstall auf true gesetzt werden. Weiter muss
sichergestellt werden, dass die angegebene Datei bereits im Basis-Projekt während der Erstellung der Testfälle existiert. Wird hingegen AtInstall auf false gesetzt, versucht das
Testsystem, die definierte Datei an der angegebenen Stelle zu erzeugen, um so zur Laufzeit
eine Eclipsing-Situation herzustellen.
Ein weiteres Schlüsselwort Code ermöglicht, zusätzlichen Quellcode den einzelnen Testfällen
hinzufügen zu können. Der zusätzliche Quellcode muss syntaktisch korrekt in Symbian C++
geschrieben werden. Denn nur dadurch kann der Code Builder gewährleisten, dass die Testfälle ohne Fehler generiert werden. Um die einzelnen File-Eclipsing-Testfälle noch flexibler zu
gestalten, gibt es zwei weitere Schlüsselwörter Type und Version. Mit Hilfe von Type wird der
Typ des Installationspaketes bestimmt. Hierbei können fast alle Installationstypen, die Symbian OS bereitstellt, verwendet werden. Im Detail sind das Standard Application (SA), Partial
Upgrade (PU), SIS Patch (SP) und Preinstalled Application (PA). Der SA-Typ stellt einen
normalen Installationstyp dar und ist nur relevant, wenn eine neue Version eingefügt wird.
Das bedeutet, wenn eine installierte Anwendung komplett in einer neuen Version installiert
werden soll, wird dieser Typ verwendet. Dabei werden die alten Dateien nicht aktualisiert,
sondern alle werden durch neue Dateien in der aktuellen Version ersetzt. Beim Partial Upgrade beziehungsweise dem PU-Typ werden nur vereinzelte Dateien ersetzt. Um ein Partial
Upgrade einer Anwendung installieren zu können, muss zuvor diese Anwendung als SA-Typ in
der Version 1,0,0 installiert worden sein. In diesem Testsystem wird bei einem PU nur eine neue
EXE-Datei der Anwendung geliefert. Alle anderen Dateien der Anwendung bleiben unverändert. Ein SIS-Patch kann nur neue Dateien liefern. So liefert ein Installationspaket, dessen
Type als SP definiert wurde, nur die Dateien, die in den Feldern Drive, Path und File angegeben wurden. Für den letzten Installationstyp PA, den das Testsystem unterstützt, müssen
bestimmte Voraussetzungen geschaffen werden. Bei diesem Installationstyp werden die einzelnen Dateien nicht im Installationspaket mitgeliefert, sondern müssen bereits in den richtigen
Verzeichnissen auf der Speicherkarte vorhanden sein. Die Installationsdatei registriert nur die
Anwendung im Betriebssystem. Auch dieser Testbereich erstellt eine vollständige Log-Datei.
Im Quelltext 4.2 ist ein Beispiel für die Konfiguration eines File-Eclipsing-Testfalls gegeben. In
diesem Beispiel wird während der Installation versucht, die TestSWINone_1.txt auf Laufwerk
E zu kopieren und dadurch eine mögliche Eclipsing-Situation zu schaffen.
Quelltext 4.2: Beispiel File Eclipsing
File - Eclipsing {
47
4. Testsystem
Capability : none
Drive : E
File : TestSWINone_1 . txt
Path : \\ Test \\ Eclipsing
Type : SA
At Install : true
Version : 1 ,0 ,0
Signed : self
Code [
]
--}
4.2.3. File Overwriting
Die File-Overwriting-Tests sind den File-Eclipsing-Tests sehr ähnlich. Beide verwenden die
gleichen Schlüsselwörter und teilweise auch die gleichen Methoden in der Implementierung.
Der wesentliche Unterschied gegenüber dem File Eclipsing ist, dass beim File Overwriting
nicht versucht wird, die Dateien durch andere Dateien zu „überschatten“, sondern dieser Test
versucht, die Dateien direkt zu überschreiben oder zu ersetzen. Das Überschreiben der Dateien ist wie beim File Eclipsing vom AtInstall Schlüsselwort abhängig. Ist AtInstall gesetzt,
versucht die Testanwendung während der Installation die angegeben Dateien zu überschreiben. Wird hingegen AtInstall als false definiert, so erzeugt der Code-Builder einen FileOverwriting-Test zur Laufzeit. Dieser zur Laufzeit ausgeführte Test versucht, die definierte
Datei im angegebenen Verzeichnis, das durch das Schlüsselwort Path definiert wird, zu überschreiben. Auch in diesem Testbereich können unterschiedliche Installationstypen spezifiziert
werden, die es ermöglichen, das File Overwriting mit verschiedenen Installationstypen zu untersuchen. Wie der File-Eclipsing-Test erstellt auch der File-Overwriting-Test eine vollständige
Log-Datei. Quelltext 4.3 zeigt ein mögliches Beispiel für einen File-Overwriting-Test. In dieser Definition wird die TestRuntimeNone_1.txt Datei während der Installation versucht, auf
dem Laufwerk C zu überschreiben.
Quelltext 4.3: Beispiel File Overwriting
File - Overwriting {
Capability : none
Drive : C
File : TestRuntimeNone_1 . txt
Path : \\ Test \\ Overwriting
Type : SA
At Install : true
Version : 1 ,0 ,0
Signed : self
Code [
]
--}
48
4.2.4. SWInstaller
In den Grundlagen wurden die große Bedeutung der SWIPolicy und die Notwendigkeit der
richtigen Konfiguration ihrer Parameter erläutert. In diesem Testbereich sollen nun diese
Parameter getestet werden. Wie in den Grundlagen beschrieben, lässt sich die SWIPolicy
nicht ohne weiteres verändern. Aufgrund der Tatsache, dass die SWIPolicy sich nicht im
beschreibbaren Speicher des Mobiltelefons befindet, muss hier zu einem Trick aus Kapitel 7
gegriffen werden. Eine weitere Option ist der Symbian OS Emulator. Im Symbian Emulator
ist die SWIPolicy frei zugänglich und könnte ohne weitere Beschränkungen bearbeitet werden.
Jedoch macht das wenig Sinn, denn die Anwendungen werden im Emulator nicht installiert,
sondern der „Compiler“ für die Emulator-Plattform übernimmt diese Aufgabe und kopiert die
Dateien in die richtigen Verzeichnisse.
Die in diesem Zusammenhang besonders wichtigen Parameter der SWIPolicy sind Allow
Unsigned, OcspEnabled, OcspMandatory, AllowGrantUserCapabilities, UserCapabilities
und AllowRunOnInstallUnstall. Diese Parameter sind für die Installation maßgeblich und
müssen deshalb auch näher betrachtet werden. Weitere Konfigurationsmöglichkeiten, die beim
Installieren neuer Anwendungen eine Rolle spielen, sind die Einstellungen, die der Benutzer
auf dem Mobiltelefon tätigen kann. Hier kann er festlegen, ob alle oder nur signierte Software
installiert werden kann. Weitere Punkte sind die Einstellung für die Online-Zertifikatsprüfung
(OCSP) sowie die Angabe einer Standard-Web-Adresse.
Da die SWInstaller Tests keine Funktionalität zur Laufzeit benötigen, wird hier nur eine sehr
simple Konsolen-Anwendung vom Code-Builder erzeugt. Die Schlüsselwörter, die der Test
verwendet, sind neben Capability und Signed, ein MIME-Typ und seine zugehörige Datei
File. Mit dem MIME-Typ kann jeder unterstützte MIME-Typ beim Installieren ausgeführt und
mit der richtigen Anwendung verknüpft werden. Wie oben auch teilweise erläutert, wird bei
diesem Test die Emulator-Plattform nicht unterstützt. Das nachfolgende Beispiel 4.4 zeigt
die Definition zweier SWInstaller-Testfälle. Im ersten Testfall wird versucht, mit Hilfe des
„FILERUN“-MIME-Typs die definierte Anwendung während der Installation zu starten. Der
zweite Testfall zeigt den Versuch, die angegebene Datei in das entsprechende Verzeichnis zu
kopieren.
Quelltext 4.4: Beispiel SWInstaller
SWInstaller {
Capability : LocalServices NetworkServices ReadUserData WriteUserData
UserEnvironment
Signed : root
MIME : FR , RI
Path : \\ sys \\ bin
File : Console_SWI . exe
--Capability : LocalServices NetworkServices ReadUserData WriteUserData
UserEnvironment
Drive : C
Path : \\ resource
File : Console_Copy . exe
Signed : self
49
4. Testsystem
--}
4.2.5. Certificate
Die Certificate-Tests sind den SWInstaller-Tests vom Aufbau sehr ähnlich, zielen jedoch auf
die Untersuchung der einzelnen Zertifikate und deren Installationsmöglichkeiten. Auch für diesen Testbereich bietet die SWIPolicy wichtige zu untersuchende Punkte, sodass MandateCode
SigningExtension, MandatePolicies und Oid näher betrachtet werden müssen. Für diesen
Testbereich generiert der Code-Builder auch nur eine einfache Konsolen-Anwendung, die zur
Laufzeit keine Funktionalität bietet. Da dieser Testbereich nur für die Untersuchung der Zertifikate zuständig ist, besitzt dieser Test nur die Schlüsselwörter Capability und Signed. Durch
die Verwendung unterschiedlicher Zertifikate untersucht dieser Test die Installationsmöglichkeiten der Basis-Anwendung mit zahlreichen Capabilities. Parallel dazu wird die SWIPolicy
mit dem gleichen Trick wie auch schon bei den SWInstaller-Tests konfiguriert, um so die
Einstellmöglichkeiten der Zertifikate zu untersuchen. Die Definitionen der verwendeten SWIPolicies sind in A.3 aufgeführt. Das folgende Beispiel 4.5 zeigt einen Testfall, indem versucht
wird, mit einem selbst erstellten Zertifikat und den definierten Capabilities den Testfall zu
installieren.
Quelltext 4.5: Beispiel Certificate
Certificate {
Capability : Location PowerMgmt ProtServ ReadDeviceData SurroundingsDD
SwEvent TrustedUI WriteDeviceData
Signed : self
--}
4.2.6. Capabilities
Capabilities stellen zusammen mit dem Data Caging das zentrale Konzept hinter der PSA
dar. Deshalb sollte dieses Sicherheitsmerkmal keine Fehler oder sonstigen Lücken enthalten.
Um einen großen Bereich der Capabilities abzudecken, bietet das Schlüsselwort CapTests die
Möglichkeit, für jede Capability einen Test zu definieren, der auch wirklich diese Capabilities
benötigt. Dadurch kann feststellt werden, ob die in der Dokumentation geforderten Capabilities für die entsprechenden Methoden ausreichen oder unzureichend sind. Weiterhin soll
dieser Testbereich zeigen, ob alle Capabilities notwendig sind oder nur teilweise im Verbund
mit anderen Capabilities benötigt werden. Um Capabilities für die einzelnen Tests zu definieren, wird auch in diesem Testbereich das Schlüsselwort Capability bereitgestellt. Ein weiteres
Schlüsselwort ist Kind. Hier kann angegeben werden, welche Anwendungsart der Code-Builder
erzeugen soll. Zur Auswahl stehen eine normale GUI-Anwendung, eine Dynamic Link Library
sowie eine zweiteilige Client/Server-Anwendung. Die GUI-Anwendung wird mit exe erstellt
und dient hauptsächlich der Untersuchung der Capabilities in Verbindung mit CapTests. Wird
Kind mit dll definiert, erzeugt der Code-Builder eine DLL. Diese DLL wird gegen eine anschließend spezifizierte exe gelinkt. Es kann aber eine weitere dll definiert werden, sodass
50
diese gegen die vorhergehende DLL gelinkt wird. Jedoch muss diese Kette in einer exe enden, damit die erzeugten DLLs im resultierenden Test benutzt werden können. Durch diesen
Testfall kann die korrekte Funktionsweise der Capability-Regeln gezeigt oder widerlegt werden. Eine ebenfalls bedeutende Rolle wird im Symbian OS dem Client/Server-Konzept zuteil.
Dieses recht intensiv genutzte Konzept muss deshalb näher untersucht werden, um die Wechselwirkung der Capabilities zwischen Client und Server zu untersuchen. Das Client/ServerFramework besteht in der Testsystem-Implementierung aus einer GUI-Anwendung als Client
und einer Server-Anwendung, die vom Client im Hintergrund gestartet wird. Hier können Client und Server separat mit Hilfe des Code-Builders durch die Definition von Kind als client
beziehungsweise als server generiert werden. Wird Kind hingegen auf cs gesetzt, so erstellt
der Code-Builder automatisch beide Anwendungen. Der nachfolgende Quelltext 4.6 zeigt zwei
Beispiele zur Definition der Capabilities-Testfälle. Dabei wird im ersten Beispiel auf der linken Seite des Quelltexts eine DLL definiert, die im anschließenden Testfall benutzt wird. Das
zweite Beispiel auf der rechten Seite zeigt die Definition eines Client/Server-Testfalls.
Quelltext 4.6: Beispiel Capabilities
Capabilities {
Capability : None
Signed : root
CapTests : none
Kind : dll
--Capability : None
Signed : self
CapTests : none
Kind : exe
--}
Capabilities {
Capability : WriteUserData AllFiles
Signed : root
Kind : client
--Capability : None
Signed : self
Kind : server
--}
4.2.7. Integrity
Dieser Test soll die Integrität der bereits installierten Daten sowie die Integrität der Installationspakete untersuchen. Die ausführbaren Dateien, die sich auf dem Flash-Speicher des
Mobiltelefons befinden, sind durch das Data-Caging geschützt. Anwendungen, die auf einem
herausnehmbaren Speichermedium installiert werden, sind jedoch nur durch einen Hash geschützt. Das Data Caging greift nur, wenn die Speicherkarte im Mobiltelefon eingelegt ist.
Wird hingegen die Speicherkarte aus dem Mobiltelefon herausgenommen, kann auf alle geschützten Verzeichnisse zugegriffen werden, wodurch die Dateien durch das Data Caging nicht
mehr geschützt sind. Ein weiterer zu untersuchender Punkt sind vorinstallierte Anwendungen
auf Speicherkarten. Um diese einzelnen Punkte zu prüfen, besitzt der Integrity-Testbereich
wie auch andere Testbereiche die Schlüsselwörter Capability, Signed, Drive, Path und File.
Durch die Angabe beliebiger Dateien kann so versucht werden, bereits installierte Anwendungen zu verändern oder neue Hash-Dateien zu installieren.
Nachdem die Testfälle in ihrer gewählten Form generiert wurden, müssen sie nur noch für die
Tests auf dem Mobiltelefon vorbereitet werden. Das kann beispielsweise die Modifikation des
Installationspaketes beinhalten oder die Veränderung der ausführbaren Dateien samt ihrer
51
4. Testsystem
Hashes. Die Vorbereitungen zu den einzelnen Tests werden im Kapitel 5.1.1 beschrieben. Das
Beispiel 4.7 zeigt eine mögliche Definition eines Integrity-Testfalls.
Quelltext 4.7: Beispiel Integrity
Integrity {
Capability : LocalServices NetworkServices ReadUserData WriteUserData
UserEnvironment
Signed : self
File : IntegrityTestText . txt
Path : \\ private
Drive : C
--}
4.2.8. Shared-Data
Damit Prozesse in Symbian OS Daten untereinander austauschen können, benötigen sie einen
sicheren Mechanismus, der das gewährleistet. Symbian bietet hier zahlreiche Mechanismen
und Konzepte, wie Daten unterschiedlicher Größe und verschiedener Typen untereinander getauscht werden können. Der Shared-Data-Testbereich deckt hier nur einen Teil dieser Mechanismen ab. Das Client/Server-Konzept wurde schon unter dem Gesichtspunkt der Capabilities
untersucht, sodass hier weitere Mechanismen betrachtet werden können. Der Shared-DataTestbereich untersucht die Konzepte Publish & Subscribe, File Handle und Data Chunk.
Auch hier finden die Schlüsselwörter Capability, Signed und Kind ihre Verwendung. Während Capability und Signed standardmäßig gebraucht werden, bietet Kind die Shared-DataKonzepte Publish & Subscribe mit dem Schlüsselwort ps, File Handle mit fs und Data Chunk
mit chunk. Innerhalb dieses Testbereichs werden abhängig von ProcessType zwei einfache
Konsolenanwendungen erzeugt. Wird der ProcessType mit main definiert, so generiert der
Code-Builder eine Hauptanwendung, die zur Laufzeit die Anwendung mit dem ProcessType
simple startet. Die Hauptanwendung definiert abhängig vom Kind einen Datentyp, auf den
der ProcessType simple versucht, zuzugreifen. Beim Publish & Subscribe-Konzept werden
außerdem noch weitere Angaben für den main Prozesstyp verlangt. Hier müssen noch zusätzlich eine WritePolicy und eine ReadPolicy angegeben werden, die zur Definition der Property
benötigt werden. Zu jedem Shared-Data-Testfall wird zusätzlich eine Log-Datei geschrieben.
Im Quelltext 4.8 ist ein Beispiel für einen Publish & Subscribe-Testfall gegeben.
Quelltext 4.8: Beispiel Shared-Data
Shared - Data {
Capability : WriteUserData
Signed : self
Kind : ps
ProcessType : main
ReadPolicy : ECapabilit yReadUserDa ta
WritePolicy : E Capa bili tyW rite User Data
--Capability : ReadUserData
52
Signed : self
Kind : ps
ProcessType : simple
--}
4.2.9. IDs
In diesem Testbereich sollen alle IDs untersucht werden, die Symbian OS in Version 9 unterstützt. Hier soll das Zusammenspiel aller IDs im Zusammenhang mit dem SWInstaller und
den Auswirkungen zur Laufzeit überprüft werden. Zu diesem Zweck stellt der IDs-Testbereich
alle verfügbaren IDs als Schlüsselwörter zur Verfügung. Im Einzelnen können so die Schlüsselwörter UID2, UI3, SID, VID und pUID definiert werden. Mit Hilfe dieser Schlüsselwörter lassen
sich alle möglichen Kombinationen und UID-Bereiche gemäß der Dokumentation untersuchen.
Die IDs werden in hexadezimaler Schreibweise ohne „0x“ angegeben. Für diesen Testbereich
wird, wie es auch teilweise andere Testfälle verwenden, eine GUI-Anwendung zur Verifikation
der Funktionsweise erstellt. Damit die Testfälle vollständig erstellt werden können, müssen
noch die Capabilities mit Capability und ein Zertifikat mittels Signed angegeben werden.
Das untenstehende Beispiel 4.9 zeigt die Definition eines IDs-Testfalls, indem IDs aus dem
Symbian Version 9 Testbereich untersucht werden.
Quelltext 4.9: Beispiel IDs
IDs {
Capability : ReadUserData WriteUserData
Signed : root
UID2 : 100039 CE
UID3 : E2CA1D56
SID : E2CA1D56
VID : 7 A567890
pUID : E2CA1D56
--}
4.2.10. User-Defined
Die bis jetzt beschriebenen Testfelder sind alle nur für den jeweiligen Testbereich definiert.
Es gibt kaum Möglichkeiten, andere Schlüsselwörter als die vorgegebenen zu verwenden. Die
Schlüsselwörter sind mit dem jeweiligen Testbereich fest verankert und lassen sich auch nicht
verändern. Dieses Problem löst der User-Defined-Testbereich. Hier besteht nun die Gelegenheit, ein Testfeld nach Wünschen oder Vorstellungen des Benutzers generieren zu lassen. Der
Testbereich kann dabei einen beliebigen Namen tragen, jedoch mit der Einschränkung schon
definierter Namen anderer Testfelder. In einem selbst definierten Testfall können alle Schlüsselwörter aus dem gesamten Testsystem verwendet werden. Teilweise in Kombinationen jeglicher
Art. Zu Beginn eines Testfalls sind die notwendigen Parameter, die durch die Schlüsselwörter
beeinflusst werden können, mit Standardwerten initialisiert. Diese Parameter können aber
53
4. Testsystem
durch die entsprechenden Schlüsselwörter wieder redefiniert werden. Beispielsweise ist die
UID2 mit 100039CE initialisiert, das für eine GUI-Anwendung steht. Die weiteren IDs UID3,
SID und pUID sind am Anfang mit der gleichen zufälligen ID, die innerhalb des geschützten
Bereichs liegt, definiert. Durch diese Vordefinitionen wird es ermöglicht, sehr einfache aber
spezielle Testfälle zu erzeugen. Die Beschränkungen der jeweiligen anderen Testbereiche in
ihren Schlüsselwörtern gelten hier natürlich auch. Als Beispiel sei das Schlüsselwort File genannt, das ohne MINE oder ohne Path und Drive keine Bedeutung hat. Der untenstehende
Quelltext 4.10 zeigt beispielsweise die Definition einer vorinstallierten Anwendung, die nur
einen globalen Chunk erstellt.
Quelltext 4.10: Beispiel User-Defined
ExampleNameTest {
Capability : LocalServices NetworkServices ReadUserData
Type : PA
Code [
RChunk chk ;
_LIT ( KChunkName , " My Global Chunk ");
TInt rc = chk . CreateGlobal ( KChunkName , 0 x100 , 0 x100 );
]
--}
4.2.11. API
Der abschließende Testbereich beschäftigt sich mit dem „Black Box Testing“ [12]. Auch diese
„Testsuite“ sollte über eine Möglichkeit verfügen, Methoden auf ihre korrekte Funktionalität
bezogen auf ihrer Eingabe- und Rückgabewerte beziehungsweise erwartete Rückgabewerte zu
testen. Es ist ein sehr einfaches Testfeld, verlangt aber vom Benutzer etwas Verständnis für
Symbian C++. Der API-Testbereich besteht aus den Schlüsselwörtern Capability, Class,
Method, ExpectedOutputValue, Parameter und PrepareCode. Class gibt die Klasse an, in der
sich die zu testende Methode befindet. Mit Method wird der Name der zu testenden Methode
angegeben und mit Parameter die entsprechenden Parameter, die die Methode erwartet, definiert. Hierfür prüft der API-Testbereich auf Gleichheit zwischen dem erwarteten Rückgabewert ExpectedOutputValue, der Funktion und dem tatsächlich resultierenden Rückgabewert.
Sind der erwartete Rückgabewert und der tatsächlich resultierende Rückgabewert identisch,
ist der Test erfolgreich bestanden, ansonsten schlägt der Test fehl. In beiden Fällen werden die
Methodenaufrufe protokolliert und in eine Log-Datei geschrieben. Müssen für die angegebene
Methode noch bestimmte Variablen initialisiert oder sonstige Vorbereitungen getroffen werden, kann mit PrepareCode der entsprechende Quellcode geschrieben werden. Der Quellcode
muss auch hier in Symbian C++ geschrieben werden und zudem syntaktisch korrekt sein. Der
Quelltext 4.11 zeigt einen API-Testfall für die Create-Methode aus der RFile-Klasse. Dabei
wird überprüft, ob mit unzureichenden Capabilities der Versuch, eine Datei in \sys\bin zu
erstellen, verweigert wird.
Quelltext 4.11: Beispiel API
API {
Capability : ReadUserData
54
Class : RFile
Method : Create
ExpectedOutputValue : -46
Parameter : session2 , _L (" C :\\ sys \\ bin \\ TestAPI . txt ") , EFileRead
PrepareCode [
RFs session2 ;
session2 . Connect ();
]
--}
Dieser Abschnitt beschreibt die sinnvolle Definition der einzelnen Testfälle. Hier werden die
Ideen für die einzelnen Testfälle beschrieben, wie sie definiert werden müssen, sodass die
beschriebenen Parameter in 3.1 verifiziert werden können.
4.3.1. Data Caging
Die Definition dieses Testbereichs soll den Zugriff auf die geschützten Verzeichnisse zeigen.
Die Testfälle werden so definiert, dass auf alle verfügbaren Laufwerke lesend und schreibend
versucht wird zuzugreifen. Bei Mobiltelefonen mit einer zusätzlichen Speicherkarte oder einem
weiteren Flash-Speicher werden die Laufwerke C, E und Z untersucht. Laufwerk C ist dabei
der interne Flash-Speicher und Laufwerk Z bildet den nicht beschreibbaren ROM-Speicher
ab. Beide Laufwerke sind auf allen Symbian Version 9 Geräten vorhanden. Laufwerk E ist
hingegen nur auf Mobiltelefonen mit einer zusätzlichen Speicherkarte oder einem weiteren,
internen Flash-Speicher verfügbar. Auf diesen Laufwerken sind die geschützten Verzeichnisse
\sys, \resource, \private\<ownSID> und \private von besonderem Interesse. Im ersten
Teil der Tests soll deshalb lesend auf die Verzeichnisse zugegriffen werden. Dazu werden in
der Vorbereitung der Testfälle (Abschnitt 5.1.1) Text-Dateien in diese Verzeichnisse abgelegt,
um anschließend auf diese Dateien mit den entsprechenden Capabilities zugreifen zu können.
Im zweiten Teil der Tests wird schreibend auf diese Verzeichnisse zugegriffen. Dabei wird
versucht, eine Datei in diesen Verzeichnissen zu erstellen. Damit die korrekte Funktionsweise
des Data Caging verifiziert werden kann, müssen die Capabilities AllFiles und Tcb benutzt
werden. Um zu zeigen, dass nur mit diesen Capabilities auf die geschützten Verzeichnisse
zugegriffen werden kann, gibt es ergänzende Tests, die ohne die entsprechenden Capabilities
versuchen, auf die geschützten Verzeichnisse zuzugreifen.
Diese Tests müssen so definiert werden, dass die Eclipsing-Regeln während der Installation
und zur Laufzeit verifiziert werden. Bei der Definition der Testfälle haben sich drei Bereiche
ergeben.
55
4. Testsystem
Im ersten Bereich wird versucht, das Installationspaket in eine Eclipsing-Situation zu führen.
Dafür werden zunächst Installationspakete als selfund root-signiert definiert, die für die
Installation auf dem internen Speicher vorgesehen werden. Die Installationspakete werden als
SA-Typ in der Version 1,0,0 installiert. Um die Eclipsing-Situation herzustellen, müssen weitere Installationspakete definiert werden, die jedoch für die Installation auf der Speicherkarte
vorgesehen werden. Diese Installationspakete werden dabei jeweils als self-, dev- und rootsigniert definiert, um die Vertrauenswürdigkeit, die die einzelnen Installationspakete durch
die Signierung erhalten, gemäß den File-Eclipsing-Regeln zu untersuchen.
Im nächsten Bereich soll versucht werden, einzelne Dateien während der Installation in eine
Eclipsing-Situation zu bringen. Dazu werden erneut die Installationspakete als selfund
root-signiert definiert. Zusätzlich wird das Installationspaket so definiert, dass zunächst drei
Text-Dateien in \\Test\\Eclipsing auf Laufwerk C abgelegt werden. Diese Pakete werden
auf dem internen Laufwerk installiert. Anschließend werden drei Installationspakete definiert,
die jeweils self-, dev- und root-signiert werden und eine Text-Datei in \\Test\\Eclipsing
auf Laufwerk E kopieren sollen. Dadurch wird bei der Installation eine Eclipsing-Situation
hergestellt, die abhängig der Signierung des Installationspaketes vom SWInstaller zugelassen
oder verweigert wird. Diese Eclipsing-Situationen können aber auch mit EXE- und DLLDateien untersucht werden. Dazu werden die Installationspakete so definiert, dass die EXEbeziehungsweise DLL-Dateien statt in \\Test\\Eclipsing einfach in \\sys\\bin abgelegt
werden.
Der letzte Bereich soll so definiert werden, dass Dateien zur Laufzeit in eine Eclipsing-Situation
gebracht werden. Dazu werden erneut Installationspakete definiert, die jedoch zur Laufzeit
drei Text-Dateien in \\Test\\Eclipsing auf dem Laufwerk C erzeugen. Anschließend werden die Installationspakete selfund root-signiert. Die weiteren Installationspakete, die die
Eclipsing-Situation zur Laufzeit erzeugen sollen, werden jeweils als self-, dev- und rootsigniert definiert. Diese Installationspakete werden zudem so definiert, dass sie jeweils versuchen, eine Text-Datei in \\Test\\Eclipsing auf Laufwerk E zu erzeugen.
Bei der Definition der Testfälle sind die Capabilities nebensächlich und deshalb müssen auch
keine Capabilities für diese Testfälle definiert werden.
Die File-Overwriting-Tests müssen so spezifiziert werden, dass die Update-Möglichkeiten und
die File-Overwriting-Regeln während der Installation genauso wie zur Laufzeit verifiziert werden. Dabei kann die Definition in vier Bereiche gegliedert werden.
Der erste Bereich dient der Verifikation der Update-Möglichkeiten. Zunächst wird eine „Basis“
für die Updates geschaffen. Dazu werden jeweils drei Testfälle, die als SA-Installationstyp in der
Version 1,0,0 definiert werden, auf dem internen Speicher installiert. Die Installationspakete
werden dabei selfund root-signiert. Damit nun die Updates verifiziert werden können,
werden drei Testfälle mit dem Installationstyp PU in der Version 2,0,0 und drei Testfälle mit
dem Installationstyp SP in der Version 2,0,0 definiert. Die Update-Testfälle werden selfund root-signiert. Die SP-Testfälle liefern in diesem Test neue Text-Dateien und legen sie
in \\private ab. Als zusätzlichen Test soll eine Konflikt-Situation provoziert werden, die
durch eine Datei eines SP-Installationstyps mit einer bereits vorhandenen Datei hervorgerufen
werden soll.
56
Im nächsten Bereich soll das File Overwriting für ein ganzes Paket versucht werden. Hierfür
werden zunächst jeweils drei selfund root-signierte Testfälle als SA-Installationstyp in der
Version 1,0,0 definiert. Die überschreibenden Testfälle werden self-, dev und root-signiert
und als SA-Installationstyp in der Version 2,0,0 definiert.
Im dritten Bereich wird versucht, einzelne Dateien während der Installation zu überschreiben. Dafür wird zunächst ein Testfall definiert, der zu überschreibende Text-Dateien in \\Test
\\Overwriting auf Laufwerk C kopieren soll und dabei self-signiert wird. Anschließend werden drei Testfälle definiert, die self-, dev und root-signiert werden und mit diesen verschiedenen Signierungen versuchen, beim Installieren die entsprechende Text-Datei in \\Test
\\Overwriting zu überschreiben. Zwei weitere jeweils ähnlich aufgebaute Testfälle versuchen, statt Text-Dateien, EXE- und DLL-Dateien in \\sys\\bin zu überschreiben. Wie in
den anderen Testfällen auch, muss zuvor ein Testfall definiert werden, der die entsprechenden
EXE- und DLL-Dateien nach \\sys\\bin kopiert. Die jeweiligen Testfälle versuchen auch,
mit den unterschiedlichen Zertifikaten self, dev und root, die EXE- und DLL-Dateien zu
überschreiben.
Der letzte Bereich soll so definiert werden, dass Dateien zur Laufzeit überschrieben werden
können. Für diesen Test werden erneut Testfälle definiert, die zunächst Text-Dateien zur
Laufzeit in \\Test\\Overwriting auf Laufwerk C erstellen. Die Installationspakete für diese
Testfälle werden dabei selfund root-signiert. Die weiteren Testfälle müssen so definiert
werden, dass die jeweiligen Testfälle self-, dev- und root-signiert sind und die entsprechenden
Text-Dateien in \\Text\\Overwriting versucht werden zu überschreiben.
4.3.4. SWInstaller
Die Definition dieser Tests soll die Funktionsweise der SWInstallers verifizieren und anhand
verschiedener SWIPolicies die Konfigurationsmöglichkeiten aufzeigen. Hierfür wird die Definition der Tests in drei Bereiche geteilt.
Der erste Bereich soll die verschiedenen Installationsoptionen, die in der Paketdatei festgelegt
werden können, untersuchen. In diesem Test wird stellvertretend für den „FILEMIME“ und
„FILETEXT“, der „FILERUN“-Installationstyp einer Datei überprüft. Beim „FILETEXT“Installationstyp wird nur der Inhalt der entsprechenden Textdatei bei der Installation oder
Deinstallation der Anwendung angezeigt. Beim „FILEMIME“-Installationstyp wird abhängig
vom spezifizierten „MIME-Typ“ die damit assoziierte Anwendung mit der angegebenen Datei
gestartet. Für diesen Test werden vier Testfälle definiert, die alle mit User Capabilities ausgestattet werden und dabei none-, self-, dev- und root-signiert werden. Für den „FILERUN“Installationstyp wird MIME mit FR,RI definiert und die entsprechende EXE-Datei, die nur
bei der Installation ausgeführt wird, nach \\sys\\bin kopiert. Dabei muss auch der Parameter der SWIPolicy AllowRunOnInstallUninstall mit verschiedenen Einstellungen untersucht
werden.
Im nächsten Bereich wird die Fähigkeit des SWInstallers getestet, verschiedene Dateien in
geschützte Verzeichnisse zu kopieren. Dafür werden die Tests so definiert, dass zunächst für
jedes Zertifikat none, self, dev und root jeweils acht Testfälle erstellt werden, die alle User
Capabilities besitzen. Weiter muss die Definition für jeden einzelnen Testfall eine Textdatei beziehungsweise EXE-Datei enthalten, die während der Installation in die Verzeichnisse
\\sys\\bin, \\resource, \\private\\EHome und \\private kopiert wird.
57
4. Testsystem
Der letzte Bereich der SWInstaller Tests soll hauptsächlich die Parameter AllowUnsigned,
AllowGrantUserCapabilities und UserCapabilities der SWIPolicy verifizieren. Dazu werden erneut für jedes Zertifikat none, self, dev und root jeweils vier Testfälle definiert. Der
erste Testfall wird mit allen User Capabilities ausgestattet, der nächste Testfall wird zusätzlich zu den User Capabilities mit der PowerMgmt Capability aus den Developer Capabilities
spezifiziert. Der dritte Testfall wird zusätzlich zu den Capabilities, die im zweiten Testfall spezifiziert wurden, mit einer Symbian Signed Capability DiskAdmin definiert. Der letzte Testfall
in diesem Bereich wird mit allen zuvor genannten Capabilities definiert und zusätzlich mit
der Tcb Capability ausgestattet.
4.3.5. Certificate
Dieser Test dient hauptsächlich der Verifikation der Zertifikate unter dem Gesichtspunkt der
Capabilities. Für diesen Test werden für jedes Zertifikat none, self, dev und root jeweils
vier Testfälle definiert und auch mit dem jeweiligen Zertifikat signiert. Dabei wird der erste
Testfall nur mit User Capabilities ausgestattet, der zweite Testfall mit Developer Capabilities, die die Capabilities Location, PowerMgmt, ProtServ, ReadDeviceData, SurroundingsDD,
SWEvent, TrustedUI und WriteDeviceData enthalten. Der dritte Testfall wird mit Symbian Signed Capabilities definiert. Die Symbian Signed Capabilities umfassen MultimediaDD,
NetworkControl, CommDD und DiskAdmin. Die System Capabilities wurden hier nur unterteilt, weil ein Developer-Zertifikat höchstens Developer Capabilities gewähren kann. Der letzte
Testfall wird schließlich mit Device Manufacturer Capabilities spezifiziert.
4.3.6. Capabilities
Damit die Capability-Regeln und die korrekte Funktionsweise der einzelnen Capabilities verifiziert werden kann, wird hier die Definition dieser Tests beschrieben. In einem weiteren Test, der
in diesem Zusammenhang definiert wird, soll die korrekte Funktionsweise der Client/ServerArchitektur gezeigt werden.
Für die Verifikation der Capability-Regeln werden zunächst jeweils zwei Testfälle und anschließend jeweils vier Testfälle definiert. Der erste Testfall wird dabei als dll definiert und gegen
den zweiten Testfall, der als exe spezifiziert wird, „gelinkt“. Bei den vier Testfällen werden
drei dll und eine exe definiert, die gemäß Abbildung 4.1 ineinander „gelinkt“ werden. Dafür
werden unterschiedliche Capabilities sowohl für die EXE als auch für die DLL gewählt und
mit verschiedenen Zertifikaten self-, dev- und root-signiert.
Abbildung 4.1.: Definition der Capability-Regeln
Bei den einzelnen Capability-Tests wird Kind als exe definiert und CapTests mit jeweils
einem ausgewählten Capability-Test spezifiziert. Um die Notwendigkeit der entsprechenden
Capability zu zeigen, werden die Testfälle einmal mit der entsprechenden Capability und
einmal ohne die Capability definiert.
58
Bei der Definition der Client/Server-Tests werden zunächst sowohl Client als auch Server mit
den identischen Capabilities definiert und zu einem einzigen Installationspaket zusammengefasst. Die weiteren Client/Server-Tests werden separat mit client und server definiert.
Hierfür werden die Tests mit unterschiedlichen Capabilities und Zertifikaten ausgestattet,
damit die Wechselwirkungen mit den Capabilities untersucht werden können.
4.3.7. Integrity
Die Definition der Integrity-Testfälle kann in vier Bereiche unterteilt werden. Im ersten Bereich wird die Integrität der Installationspakete untersucht. Dazu werden vier Testfälle mit
User Capabilities und verschiedenen Signierungen definiert. Anschließend müssen die erstellten
Installationspakete noch entsprechend vorbereitet werden. Die Vorbereitung der Installationspakete ist in 5.1.1 beschrieben.
Der zweite Bereich definiert die Testfälle, die die Integrität der EXE-Dateien auf unterschiedlichen Laufwerken untersuchen sollen. Hierfür werden zunächst acht Testfälle definiert, die
selbst signiert sind und User Capabilities besitzen. Vier der Testfälle werden auf dem internen Speicher installiert. Die restlichen vier Installationspakete werden anschließend auf der
Speicherkarte der Testgeräte installiert. Bevor die Testfälle jedoch ausgeführt werden können,
müssen sie dafür wieder vorbereitet werden.
Der dritte Bereich untersucht die Integrität der Ressourcen, die mit dem Installationspaket
bereitgestellt werden. Hierfür werden erneut vier Testfälle mit User Capabilities und einem
selbst signierten Zertifikat definiert. Zwei dieser Testfälle werden auf dem internen Speicher
installiert und die beiden restlichen Installationspakete auf der Speicherkarte.
Der letzte Bereich der Integrity-Testfälle untersucht die Integrität vorinstallierter Anwendungen. Für diese Testfälle wird der User-Defined-Testbereich benutzt, da der IntegrityTestbereich keinen PA-Installationstyp unterstützt. Für diesen Zweck werden acht Testfälle
definiert, alle mit dem PA-Installationstyp, User Capabilities und einem selbst signierten Zertifikat. Vier dieser Testfälle werden ordnungsgemäß nach Einlegen der Speicherkarte installiert
und anschließend erst für den eigentlichen Test vorbereitet. Die verbleibenden vier Testfälle
werden zunächst auf die Speicherkarte kopiert, jedoch erst nachdem die einzelnen Vorbereitungen durchgeführt worden sind, werden die Testfälle installiert.
4.3.8. Shared-Data
Bei der Definition der Shared-Data-Testfälle müssen diese gemäß der Spezifikation in Abschnitt 3.1.2 in drei Bereiche definiert werden, Publish & Subscribe, File Handle und Data
Chunk. Bei dieser Art der Testfälle muss ähnlich der Client/Server-Testfälle zunächst mit
main eine Hauptanwendung definiert werden, die anschließend eine Hilfsanwendung startet.
Die Hilfsanwendung versucht, abhängig von der Zugriffsart auf die Daten der Hauptanwendung zuzugreifen und kann mit simple definiert werden.
Beim Publish & Subscribe wird zunächst die Funktionsweise überprüft. Dafür wird die Hauptanwendung mit einer ReadPolicy und einer WritePolicy definiert, die den Zugriff auf die Property durch Capabilities beschränken kann. Zunächst werden die Policies so definiert, dass nur
59
4. Testsystem
mit den entsprechenden Capabilities die Property von den Anwendungen beschrieben beziehungsweise gelesen werden kann. Anschließend werden die Policies mit Capabilities definiert,
die die Anwendungen main beziehungsweise simple nicht besitzen.
Beim File-Handle-Bereich müssen die Testfälle zunächst so definiert werden, dass die Funktionsweise gewährleistet werden kann. Dazu werden beide Anwendungen main und simple
mit den identischen Capabilities ausgestattet, um anschließend die Anwendungen noch mit
unterschiedlichen Capabilities zu definieren.
Im Data-Chunk-Bereich werden, wie im File-Handle-Bereich, die beiden Anwendungen zunächst mit den gleichen Capabilities spezifiziert, um auch hier die korrekte Funktionsweise
zu zeigen. Anschließend müssen noch main und simple mit unterschiedlichen Capabilities
definiert werden.
Alle definierten Testfälle werden mit einem selbst erstellten Zertifikat signiert, da in diesem
Testbereich nur User Capabilities verwendet werden.
4.3.9. IDs
Bei der Definition des IDs-Testbereichs werden sinnvolle UID-Kombinationen aus geschützten
und ungeschützten UID-Bereichen verwendet. Tabelle 2.6 in Abschnitt 2.4.2 zeigt dabei die
Aufteilung der UID-Bereiche. Im Einzelnen werden die UID3, SID, pUID und VID in diesem
Testbereich definiert. Jeder Testfall wird mit User Capabilities definiert und jeweils mit allen
zur Verfügung stehenden Zertifikaten (Abschnitt 4.1.2) signiert. Die Testfälle mit den UIDs
aus dem Symbian-Testbereich werden als Erstes mit der gleichen UID3, der gleichen SID und
der gleichen pUID definiert. Wenn die VID in den Testfällen nicht explizit definiert ist, wird
sie auf 0 gesetzt. Bei den zweiten Tests ist die UID3 gleich der SID, jedoch ungleich der
pUID. Im nächsten Test sind UID3, SID und pUID voneinander verschieden. Der letzte Test
mit UIDs aus dem Symbian-Testbereich definiert die drei IDs UID3, SID und pUID mit der
gleichen UID, jedoch zusätzlich mit einer VID. Anschließend werden die Testfälle mit UIDs
aus dem geschützten UID-Bereich definiert. Diese Testfälle sind genauso aufgebaut wie die
Tests innerhalb des ungeschützten Bereichs, jedoch werden bei diesen Tests die UIDs aus dem
geschützten Bereich gewählt.
4.3.10. API
Die Definition der API-Testfälle ist hier nur exemplarisch für drei Testfälle gegeben. Der Testbereich soll nur zeigen, dass grundlegendes „Black Box Testing“ vom PSA-Testsystem auch
unterstützt wird. Bei den drei Testfällen werden Methoden aus der RFile-Klasse benutzt.
Dabei wird zunächst bei der Methode Open versucht, eine nicht vorhandene Text-Datei zu
öffnen. Beim Versuch, die Datei dennoch zu öffnen, soll der Fehlercode -1 auftreten als Hinweis darauf, dass die Datei nicht gefunden werden konnte. Dazu wird im ersten Testfall Class
mit RFile, Methode mit Open und ExpectedOutputValue mit -1 definiert. In einem weiteren Testfall soll mit der Methode Create versucht werden, eine Datei in einem geschützten
Verzeichnis ohne die entsprechenden Rechte zu erstellen. Dabei sollte der Fehlercode -46 auftreten als Hinweis für unzureichende Schreibrechte für dieses Verzeichnis. Für die Definition
60
des Testfalls muss nur Method und ExpectedOutputValue auf die entsprechenden Werte gegenüber dem ersten Testfall geändert werden. Beim letzten API-Test soll die Methode Create
beim Erstellen einer Datei in einem nicht geschützen Verzeichnis den Fehlercode 0 liefern,
sodass für die Definition die Parameter aus dem zweiten Testfall übernommen werden können
und nur ExpectedOutputValue auf 0 geändert werden muss.
61
Dieses Kapitel beschreibt zunächst den Versuchsaufbau und die Durchführung der Tests.
Anschließend werden die Ergebnisse der zuvor definierten Testfälle präsentiert. Anhand der
Ergebnisse wird im letzten Abschnitt die Frage geklärt, ob die spezifizierte Funktionsweise
der PSA gegeben ist.
5.1. Versuchsaufbau
Dieser Abschnitt beschreibt die Testumgebung und den deren Aufbau. Zunächst werden kurz
die nötigen Vorbereitungen für die einzelnen Testbereich erläutert, beispielsweise welche Tools
installiert werden müssen oder benutzt werden. Anschließend wird die verwendete Hard- und
Software beschrieben.
5.1.1. Vorbereitung
Bevor die einzelnen Tests durchgeführt werden können, müssen bestimmte Vorbereitungen
sowohl im Emulator als auch auf dem Mobiltelefon getroffen werden. Jedes Mobiltelefon muss
zunächst geprüft werden, ob es eine Möglichkeit zur Speicherkartenerweiterung besitzt. Bei
gegebener Speicherkartenunterstützung muss sichergestellt werden, dass alle Testgeräte während der Tests mit einer Speicherkarte bestückt sind. Die Speicherkarte wird besonders bei den
Eclipsing- und Integrity-Testfällen benötigt. Im Emulator muss hingegen nur ein entsprechendes virtuelles Laufwerk erstellt werden, das jedoch nicht mit einer Speicherkarte auf einem
Mobiltelefon verglichen werden kann. Wird eine neue Speicherkarte in ein Symbian Version 9
Mobiltelefon eingelegt, so wird diese automatisch formatiert und die wichtigsten Verzeichnisse
werden erstellt. Neben Verzeichnissen für Bilder und anderen Dateien werden auch die PSA
relevanten Verzeichnisse erstellt. Im Vergleich dazu werden im Emulator diese PSA relevanten
Verzeichnisse nicht erstellt.
Um die Protokollierung während den Tests zu ermöglichen, muss vorbereitend die File-LoggerDLL sowie die Ownfile-Logger-DLL (Abschnitt 4.1.1) auf allen Testgeräten installiert und für
die Emulator-Plattformen kompiliert werden. Weiter muss für beide Plattformen ein Verzeichnis für Log-Dateien erstellt werden, falls dieses Verzeichnis noch nicht existiert. Eine
sehr nützliche Anwendung, was sich besonders bei der Installation zahlreicher Installationspakete herausgestellt hat, ist der AutoInstaller [21]. Wie bereits der Name der Anwendung
verrät, können mit dem AutoInstaller mehrere Installationspakete hintereinander automatisch und ohne Nachfragen an den Benutzer zu stellen, installiert werden. Zusätzlich wird
auf den Testgeräten noch ein Datei-Manager [22] installiert, der gegenüber dem bereits vorhandenen Symbian-Datei-Manager komfortabler zu bedienen ist und mehr Funktionen bietet.
63
Darüber hinaus muss der „ROMPatcher“, der in Kapitel 7 näher beschrieben ist, mit den zugehörigen „Patchen“ installiert werden. Mit dem „ROMPatcher“ können beispielsweise andere
SWIPolicies verwendet werden. Abschließend muss noch die Verifikationsgrundlage für das
„root“-Zertifikat (Abschnitt 7.1.3) installiert werden.
Nachdem all diese testunabhängigen Vorbereitungen getroffen wurden, können die testspezifischen Vorbereitungen für beide Plattformen begonnen werden. Für die Data-Caging-Tests
muss für beide Plattformen eine Textdatei in die Verzeichnisse \\sys, \\resource, \\private
und \\private\\EHome auf den Laufwerken C, E und Z kopiert werden. Diese Textdatei wird
für den lesenden Zugriff auf die genannten Verzeichnisse benötigt. Für die File-EclipsingTestfälle muss auf den Laufwerken C und E das Verzeichnis \\Test\\Eclipsing erstellt werden. Weiter muss sichergestellt werden, dass für diese Testfälle eine Test-EXE-Datei und eine
Test-DLL-Datei verfügbar ist, die beim Erstellen der Installationspakete mit eingebunden werden. Im Emulator muss das \\Test\\Eclipsing Verzeichnis ebenfalls erstellt werden. Beim
File-Overwriting muss hingegen das Verzeichnis \\Test\\Overwriting auf beiden Plattformen erstellt werden. Aber auch bei diesen Testfällen müssen die entsprechenden Test-EXEund Test-DLL-Dateien vorhanden sein. Bei den Integrity-Tests werden vorbereitend ausgewählte SIS-Dateien auf Hex-Ebene so manipuliert, dass die Integrität des Installationspaketes
nicht mehr gegeben ist. Dafür wird beispielsweise in der Installationsdatei am Anfang ihrer
Hex-Darstellung ein Byte verändert. Bei einer anderen Installationsdatei werden an das Ende der Datei Null-Bytes angehängt. Die restlichen Installationsdateien werden an anderen
Stellen im Hex-Code byteweise verändert. Für weitere Integrity-Tests werden von bereits installierten Anwendungen die Capabilities der EXE-Dateien verändert. Dadurch müssen aber
auch die jeweiligen Hash-Werte der EXE-Dateien neu berechnet und ersetzt werden. Für die
SWInstaller- und Zertifikatstests müssen die SWInstaller-Einstellungen vor jedem Test aufgezeichnet werden. Zusätzlich müssen einzelne Zertifikat-Testfälle mit Hilfe des Open-SignedZertifizierungsprogramms signiert werden.
5.1.2. Hardware
Für die einzelnen Tests standen insgesamt vier Mobiltelefone zu Testzwecken zur Verfügung.
Die Details zu den jeweiligen Testgeräten sind in Tabelle 5.1 zusammengefasst. Bei den vier
Testgeräten handelt es sich ausschließlich um Nokia Mobiltelefone und zwei dieser Testgeräte
sind zusätzlich mit einem T-Mobile-“Software-Branding“ ausgestattet. Das N81 besitzt keine Speicherkartenerweiterung, aber dafür einen internen 8 GB Flash-Speicher. Dieser interne
Flash-Speicher kann jedoch wie eine Speicherkarte verwendet werden. Im Dateisystem wird
der 8 GB Flash-Speicher auf das identische Laufwerk wie die Speicherkarte abgebildet und
kann ebenfalls als Wechseldatenträger benutzt werden. Die Kommunikation zwischen PC und
den Testgeräten wurde über die entsprechenden kompatiblen Datenkabel realisiert. Die ver-
Hersteller
Nokia
Nokia
Nokia
Nokia
64
Modell
E61
E90
N81 8GB
N95
Tabelle 5.1.: Testgeräte
Firmware-Version Branding
3.0633.09.04
Kein
07.40.1.2
T-Mobile
10.0.053
T-Mobile
21.0.016
Kein
Speicherkarte
2 GB SanDisk
512 MB Nokia
8 GB Flash
8 GB SanDisk
schiedenen Versionen der Symbian-Emulatoren wurden auf einem Core2Duo Rechner mit 2
GB RAM und Windows XP Professional mit SP2 ausgeführt.
5.1.3. Software
Wie in 5.1.2 beschrieben, wird während der Tests Windows XP Professional mit SP2 benutzt.
Die Verbindung zwischen PC und Testgerät wird mittels „Nokia PC Suite“ in der Version
6.85.14.1 hergestellt. Die ebenfalls benötigten „Nokia Connectivity Cable Driver“ sind in der
Version 6.82.4.0. Zur Manipulation der SIS-Dateien und der Symbian EXE-Dateien wurden
die HEX-Tools HxD-Hexeditor [23] und WinHex [24] verwendet.
Bei den Testgeräten handelt es sich um ein Symbian S60 v9.1 Gerät und drei Symbian S60
v9.2 Geräte. All diese Testgeräte wurden von Nokia hergestellt. Trotz der geringen Anzahl der
Testgeräte kann dennoch von einer repräsentativen Menge ausgegangen werden. In Abbildung
5.1 wird deutlich, dass Nokia mit Abstand die meisten Symbian S60/UIQ v9 Mobiltelefone im
Aufgebot hat, sodass der Test mit nur Nokia Modellen das Ergebnis nicht verfälscht oder ein
Hersteller bevorzugt wird. Bei den Symbian Versionen kann leider nicht die aktuelle Marktsituation wiedergegeben werden, da drei der vier Testgeräte mit Symbian OS v9.2 ausgestattet
sind. Es kann jedoch als Trend für die weitere Zunahme der Symbian Version 9 Mobiltelefone
mit der Version 9.2 beziehungsweise Version 9.3 gesehen werden.
Die beiden Grafiken stellen die aktuell verfügbaren und teilweise noch nicht veröffentlichten
Symbian Version 9 Mobiltelefone dar. Für die Grafik wurden nur Symbian Version 9 Mobiltelefone der S60- und UIQ-Variante berücksichtigt. Mit [25] und weiteren Informationen der
jeweiligen Hersteller konnten 59 Symbian Version 9 Mobiltelefone ermittelt werden. Dabei
konnten Nokia 42 Modelle zugeteilt werden. Die Verteilung der drei Symbian Versionen 9.1,
9.2 und Version 9.3 ist in der linken Hälfte der Grafik 5.1 abgebildet. Auf der rechten Seite
der Abbildung ist die Verteilung der 59 Symbian Version 9 Mobiltelefone auf die Hersteller
dargestellt.
5.3. Durchführung
Dieser Abschnitt soll kurz die Durchführung der Testfälle beschreiben und die dabei auftretenden Unterschiede bei der Durchführung beleuchten.
5.3.1. Emulator
Wie schon teilweise in 4.2 beschrieben, können nicht alle Testfälle im Emulator ausgeführt
werden. Diejenigen Testfälle, die während der Installation ausgeführt werden sollen, zum Beispiel Zertifikat-Tests oder SWInstaller-Tests, können im Emulator nicht überprüft werden,
da der Emulator die Installation von zusätzlichen SIS-Dateien nicht unterstützt. Somit können auch die einzelnen Update-Möglichkeiten, die während den File-Overwriting-Testfällen
65
Abbildung 5.1.: Verteilung von Symbian v9
überprüft werden sollen, nicht im Emulator verifiziert werden. Ein weiteres Hindernis im
Emulator ist die mangelnde Unterstützung der virtuellen Laufwerke in Verbindung mit der
PSA, wodurch Eclipsing-Testfälle und Data-Caging-Testfälle in geschützten Verzeichnissen
nicht möglich sind. Auch vereinzelte Integrity-Testfälle können im Emulator nicht ausgeführt
werden, denn die benötigten Hash-Werte der EXE-Dateien für diesen Test werden während
der Installation vom SWInstaller erstellt.
Die eigentliche Durchführung der Testfälle im Emulator erwies sich im Vergleich zu der Durchführung auf den Testgeräten als weniger mühselig. Das Installieren der einzelnen Testfälle fiel
weg, denn das Kopieren der Dateien wird bereits durch den Emu-Builder beim Kompilieren
der Testfälle erledigt. Somit musste nur der Emulator gestartet und die einzelnen Testfälle
ausgeführt werden.
5.3.2. Testgeräte
Bei den meisten Testfällen gestaltete sich die Durchführung der Tests sehr ähnlich. Teilweise
konnten die Testfälle auf die Speicherkarte kopiert und anschließend mit dem AutoInstaller automatisch installiert werden. Diese Vorgehensweise konnten jedoch bei den Testfällen
nur dann angewandt werden, wenn die Testfälle auf Laufwerk C installiert werden konnten
und keine Fehler während der Installation erwartet wurden. Die restlichen Testfälle, die auf
Laufwerk E installiert werden mussten, wurden einzeln installiert. Anschließend mussten die
Testfälle nur noch ausgeführt und die Log-Dateien archiviert werden.
In einigen Testbereichen mussten die Testfälle einzeln installiert werden, damit mögliche Reaktionen des SWInstallers manuell protokolliert werden konnten. Auf diese Weise musste ein Teil
der File-Eclipsing- und File-Overwriting-Testfälle installiert werden. Die Testbereiche SWInstaller, Certificate und IDs mussten komplett manuell installiert und alle Installationsversuche
protokolliert werden. Bei den SWInstaller- und Certificate-Testfällen musste zusätzlich gemäß
der Definition bei bestimmten Testfällen die SWIPolicy verändert werden. Dazu wurde einfach
66
5.3. Durchführung
vor dem Testfall mit Hilfe des ROMPatchers der entsprechende SWIPolicy-Patch aktiviert.
Der Patch sorgt dafür, dass der SWInstaller die selbst definierte SWIPolicy bei der Installation heranzieht. Bevor jedoch auch diese Testfälle ausgeführt werden konnten, mussten vor
jedem Test die SWInstaller Einstellungen des Mobiltelefons notiert werden.
Bei den Integrity-Testfällen gestaltete sich die Durchführung der Tests etwas aufwendiger,
denn die vier Bereiche, in die diese Testfälle unterteilt wurden, unterscheiden sich alle in
ihrer Durchführung und werden deshalb etwas ausführlicher beschrieben. Für diese Tests,
in denen die Integrität der Installationsdateien untersucht wird, wurde die Modifikation der
Installationsdateien schon in 5.1.1 beschrieben. Anschließend muss nur noch versucht werden,
die modifizierten Installationsdateien auf den einzelnen Testgeräten zu installieren und das
Installationsverhalten der modifizierten Installationsdateien muss protokolliert werden.
Die Testfälle, die die Integrität der installierten EXE-Dateien auf dem internen Laufwerk
und der Speicherkarte untersuchen, sind in der Durchführung etwas aufwendiger. Zunächst
müssen die Installationspakete auf Laufwerk C beziehungsweise Laufwerk E installiert werden.
Anschließend müssen die EXE-Dateien in den \sys\bin Verzeichnissen verändert werden. Auf
der Speicherkarte ist das ohne weitere Probleme möglich, wenn diese als Wechseldatenträger
an den PC angeschlossen wird. Um auf die EXE-Dateien zugreifen zu können, muss zu einem
Trick gegriffen werden. In Abschnitt 7 werden alle dafür benötigten Methoden kurz vorgestellt.
Ist nun der Zugang zu den EXE-Dateien gegeben, kann diese zunächst für einen Testfall auf
Hex-Ebene verändert werden. Für einen weiteren Testfall muss zusätzlich noch der Hash-Wert
der EXE-Datei neu berechnet werden. Die Hash-Werte der EXE-Dateien werden auf Laufwerk
C im \sys\hash Verzeichnis gespeichert und mit Hilfe des SHA-1 Algorithmus [26] berechnet.
Für einen weiteren Testfall werden die Capabilities der EXE-Datei erweitert. Zunächst wird
nur die EXE verändert, ohne den Hash-Wert der Datei zu aktualisieren. Anschließend wird im
nächsten Testfall neben der Capability auch noch der Hash-Wert der zugehörigen EXE-Datei
verändert. Für beide Laufwerke ist die Vorgehensweise die gleiche. Die zu verändernde Datei
wird auf einen PC kopiert, dort verändert und wieder auf das Mobiltelefon kopiert. Nachdem
die einzelnen Testanwendungen auf beiden Laufwerken verändert wurden, mussten diese nur
aufgeführt und die Verhaltensweise der Anwendung protokolliert werden.
Bei den Testfällen, in denen die Integrität der Ressource-Dateien untersucht wird, ist die Vorgehensweise ähnlich der Integrität der EXE-Dateien. Zunächst werden die Testanwendungen
auf beiden Laufwerken installiert und anschließend die Ressource-Dateien der entsprechenden
Anwendung verändert. Die Ressourcen, die dabei verändert werden, sind einmal die „RSCDatei“ der Anwendung und eine mitgelieferte Text-Datei, die im private Verzeichnis der
Anwendung abgelegt wird. Innerhalb der „RSC-Datei“ wird der darin enthaltene „AuthorString“ durch eine anderen „String“ ersetzt. Der Inhalt der Text-Datei wird dabei durch einen
anderen Text ersetzt. Nachdem die Veränderungen an den Dateien vollzogen wurden, können
die Tests ausgeführt und auf ihre korrekte Funktionsweise getestet werden.
Für die Untersuchung der Integrität der PA-Anwendungen müssen zunächst alle PA-TestDateien auf die Speicherkarte kopiert werden. Die Hälfte dieser Testfälle wird anschließend
mit den „Stub“-Installationsdateien installiert. Die Stub-Datei dient dabei der Verifikation der
Signatur, ob die zugehörigen PA-Dateien die definierten Capabilities bereitstellen und ob die
richtigen IDs gemäß der Signierung verwendet werden. Nachdem nun ein Teil der Dateien
installiert und die restlichen Dateien nur auf die Speicherkarte kopiert wurden, kann nun mit
67
allen Dateien wie schon bei der Integrität der EXE-Dateien verfahren werden. Das bedeutet zunächst auf der Hex-Ebene die EXE-Dateien verändern, mit und ohne Anpassung der
Hash-Werte der EXE-Datei und anschließend die Capabilities der EXE-Dateien verändern.
Das wiederum auch einmal ohne die Hash-Werte der EXE-Datei anzupassen und einmal mit
Anpassung der Hash-Werte. Nach diesen Veränderungen wird versucht, die andere Hälfte
der PA-Dateien mit Hilfe der Stub-Dateien zu installieren und dabei auftretende Fehler werden protokolliert. Es kann nun versucht werden, die restlichen installierten PA-Anwendungen
auszuführen. Hier kann überprüft werden, ob die Veränderungen der einzelnen Dateien dem
„Symbian-Loader“ aufgefallen sind.
5.3.3. Schwierigkeiten
Das größte Problem stellte die Anzahl der Testfälle dar. Die Dauer der Installation der einzelnen Testfälle variierte stark zwischen den einzelnen Testgeräten wie Tabelle 5.2 verdeutlicht.
Dabei wurde die Dauer der Installation beziehungsweise Deinstallation der einzelnen Testfälle exemplarisch bei vier Testfällen manuell gemessen. Die Installationsdauer mit Hilfe des
AutoInstallers wurde jeweils in zwei Durchläufen gemessen, sodass zunächst ein Testfall und
anschließend zehn Testfälle automatisch installiert wurden. Die dabei ermittelten Zeiten sind
als Mittelwerte zusammen mit ihrer Standardabweichung in der Tabelle dargestellt. Vor allem erwies sich das Nokia N95 als besonders langsam bei der Installation beziehungsweise
Deinstallation einzelner Testfälle. Die Deinstallation der Testfälle war jedoch wichtig, damit
die anderen Testfälle wieder eine geeignete Basis für die Installation und Ausführung ihrer
Testfälle besitzen. Eine geeignete Basis für die einzelnen Testfälle soll dabei einen Zustand
beschreiben, indem das zu installierende Paket nicht von der korrekten Installation und Ausführung gehindert wird. Diesen Zustand könnten bereits vorhandene Textdateien oder auch
EXE-Dateien, die von einen anderen Testfall genutzt wurden, beeinträchtigen.
Tabelle 5.2.: Installations- und Deinstallationsdauer
Installation
Deinstallation
Modell
Manuell
Automatisch(1/10)
Manuell
E61
8,1 ± 1,1 s
3,9 ± 0,4 s / 32,9 ± 14,5 s
5,5 ± 0,5 s
E90
12,2 ± 0,7 s
7,8 ± 0,5 s / 88,8 ± 17,4 s
12,4 ± 0,1 s
N81 8GB
8,4 ± 0,6 s
4,7 ± 0,5 s / 47,0 ± 11,5 s
8,3 ± 0,3 s
N95
29,9 ± 0,8 s 24,3 ± 0,8 s / 267,5 ± 22,5 s
33,9 ± 0,6 s
5.4. Evaluationskriterien
Dieser Abschnitt soll die Kriterien beschreiben, die bei der Auswertung der Testfälle herangezogen werden.
Verifikation Eine Aufgabe der Testfälle ist die Verifikation der Funktionsweise der einzelnen
Testbereiche, die in der Spezifikation identifiziert wurde. Dieses Kriterium soll die Verifikation abbilden, ob die tatsächliche Funktionsweise, die durch die Testfälle gegeben
wird, auch der spezifizierten Funktionsweise der PSA durch Symbian entspricht.
68
5.5. Vorstellung der Ergebnisse
Regeln Neben der Verifikation der Funktionsweise der PSA soll es noch ein separates Kriterium zur Überprüfung der Regeln für jeden Bereich geben. Dieses Kriterium soll dabei
helfen zu überprüfen, ob die einzelnen Regeln, die Symbian für die PSA definiert, eingehalten werden oder ob diese in einer anderen Weise verletzt werden.
SWInstaller Dieses Kriterium soll als Indikator für die Mächtigkeit des SWInstallers stehen.
Dabei kann das Kriterium bei der Verifikation des Funktionsumfangs des SWInstallers
herangezogen werden.
SWInstaller-Einstellungen In Kapitel 3.2.2 wurden die internen SWInstaller-Einstellungen
beschrieben. Dieses Kriterium soll dazu dienen, die verschiedenen Einstellungen miteinander vergleichen zu können. Dabei kann das Kriterium helfen, die Priorisierung
zwischen den SWInstaller-Einstellungen und der SWIPolicy zu klären.
SWIPolicy Die SWIPolicy bietet den Mobiltelefonherstellern oder auch vereinzelten Providern, die das Mobiltelefon in einer teilweise angepassten Version herausbringen, die
Möglichkeit, zahlreiche Einstellungen zu treffen. Die SWIPolicy ist die Entscheidungsgrundlage für den SWInstaller und somit auch ein wichtiges Kriterium für die Auswertung der Testfälle. Das SWIPolicy-Kriterium sollte auch für die Auswirkungen auf den
Installationsprozess mit unterschiedlichen SWIPolicies herangezogen werden. Anhand
des Kriteriums soll geklärt werden, ob die Spezifikation der SWIPolicy eingehalten wird
und wie sich die Mehrdeutigkeiten auf die Installation auswirken. Dabei soll untersucht
werden, wie sich die Policies mit unterschiedlichen Symbian Versionen, verschiedenen
Gerätemodellen einzelner Hersteller, Providern und auch der damit verbundenen Firmware auf dem einzelnen Gerät unterscheiden.
Symbian Versionen Dieses Kriterium soll mögliche Unterschiede bei den Testergebnissen zeigen, die durch die verschiedenen Symbian Versionen im Emulator oder auf dem Mobiltelefon hervorgerufen werden können.
Plattform Das Plattform-Kriterium soll als Unterscheidungsmerkmal für mögliche Unterschiede in den Testergebnissen im Vergleich zwischen dem Emulator und dem Mobiltelefon dienen.
Software-Branding Viele Provider versehen ihre Mobiltelefone vor dem Verkauf mit einem
Software-Branding, das meistens anbieterspezifische Erweiterungen oder auch Änderungen sind. Hier sollte das Kriterium bei möglichen Änderungen in der PSA-Implementierung
und SWIPolicy angewendet werden.
In diesem Abschnitt werden die Ergebnisse für jeden Testbereich einzeln präsentiert. Hierbei
werden die Ergebnisse gemäß den oben beschriebenen jeweils zutreffenden Kriterien vorgestellt.
69
5.5.1. Data Caging
Die Data-Caging-Testfälle wurden gemäß den Anforderungen in zwei Bereichen definiert. Im
ersten Bereich soll lesend auf die geschützten Verzeichnisse zugegriffen werden, während im
zweiten Bereich der Data-Caging-Testfälle der schreibende Zugriff auf die geschützten Verzeichnisse untersucht wird. Wenn in diesem Abschnitt oder in den folgenden Abschnitten
geschützte Verzeichnisse erwähnt werden, sind in diesem Zusammenhang immer die DataCaging-Verzeichnisse \resource, \sys, \private und \private\<ownSID> gemäß Abschnitt
2.2.4 gemeint. Werden hingegen „frei lesbare“ Verzeichnisse erwähnt, so sind die geschützten
Verzeichnisse \resource und \private\<ownSID> gemeint, auf die bei lesendem Zugriff keine
Capabilities benötigt werden.
Die Ergebnisse der Lese-Testfälle im Data-Caging-Bereich zeigen, dass mit der AllFiles Capability auf alle Verzeichnisse lesend zugegriffen werden kann. Einzig wenn in den entsprechenden geschützten Verzeichnissen die Testdateien nicht gefunden werden, wird ein entsprechender Fehler angezeigt. Ein Beispiel ist der Zugriff auf das dem Prozess zugehörige private
Verzeichnis auf Laufwerk E. Da entsprechend der Definition der Testfall auf Laufwerk C installiert wurde, kann der Prozess zwar auf das übergeordnete Verzeichnis zugreifen, aber der
„File-Server“ meldet, dass das Verzeichnis nicht existiert. Ebenfalls kann auf Laufwerk Z lesend zugegriffen werden, jedoch konnte die Testdatei nicht gelesen werden, da selbst mit den
Mitteln, die in Kapitel 7 vorgestellt werden, nicht auf das Z Laufwerk schreibend zugegriffen
werden kann, um eine entsprechende Testdatei zu hinterlegen. Ohne eine Capability oder sogar mit der Tcb Capability, kann nur auf die frei lesbaren Verzeichnisse \resource auf beiden
Laufwerken C,E und das \private\<ownSID> Verzeichnis auf Laufwerk C zugegriffen werden.
Für die restlichen geschützten Verzeichnisse wie \sys oder \private wird der Zugriff mit dem
Fehler Zugriff verweigert bei Ausführung der Operation verweigert. Wird nun ein Prozess mit
den beiden „stärksten“ Capabilities Tcb und AllFiles ausgestattet, ändern sich die Ergebnisse gegenüber dem Testfall mit AllFiles Capabilities nicht, denn für Lese-Zugriff wird nur die
AllFiles Capability benötigt. Hierbei werden die schon in den Grundlagen angesprochenen
Eigenschaften der Capabilities wie Orthogonalität und Eigenständigkeit aufgezeigt. Es kann
schon als erster Hinweis für die Verifizierung der Capabilities betrachtet werden.
Im Emulator fallen die Ergebnisse der Lese-Testfälle im Data-Caging-Bereich ähnlich den Testgeräten aus. Mit der entsprechenden AllFiles Capability kann auf alle Verzeichnisse auch auf
Z und die darin hinterlegten Testdateien lesend zugegriffen werden. Eine Ausnahme machen
da die \private Verzeichnisse der zugehörigen Testanwendungen auf allen Laufwerken C, E,
Z auf die nicht zugegriffen werden kann, da sie nicht vorhanden sind. Ein weiteres Problem
im Emulator ist die nicht vorhandene Verzeichnisstruktur der geschützten Verzeichnisse auf
der virtuellen Speicherkarte. Hierfür können beispielsweise die Verzeichnisstrukturen manuell
erzeugt werden oder eine kleine Anwendung erzeugt die Verzeichnisse. Sind die geschützten
Verzeichnisse nicht vorhanden, generiert der „File-Server“ einen entsprechenden Fehler, dass
das Verzeichnis nicht gefunden werden kann. Im Emulator kann der Testfall ohne die entsprechende Capability oder nur mit der Tcb Capability, wie auch schon bei den Testgeräten, nur
auf die frei lesbaren Verzeichnisse \resource auf allen drei Laufwerken C, E und Z und die
darin hinterlegten Dateien zugreifen. Werden wie schon bei den Testgeräten die „stärksten“
Capabilities Tcb und AllFiles verwendet, ändern sich die Testergebnisse nicht.
Bei den Schreib-Tests der Data-Caging-Testfälle kann mit der AllFiles Capability nur in die
frei zugänglichen Verzeichnisse \private\<ownSID> und in das \private Verzeichnis geschrie-
70
ben werden. Auf das Laufwerk Z wird zwar der Zugriff auf die \private Verzeichnisse gewährt,
also kein Zugriff verweigert bei Ausführung der Operation-Fehler, jedoch beim Versuch eine
Datei auf diesem Laufwerk zu erstellen, tritt ein neuer Fehler auf Zugang verweigert. Wie schon
kurz bei den Lese-Tests beschrieben, kann auf das ROM-Laufwerk nicht schreibend zugegriffen werden. Der Versuch auf die restlichen geschützten Verzeichnisse schreibend zuzugreifen,
misslingt aufgrund mangelnder Capabilities. Wird nun der Test ohne die entsprechenden Capabilities ausgeführt, kann nur in \private\<ownSID> eine neue Datei erstellt werden. Auf
Laufwerk E wird das private Verzeichnis der Testanwendung nicht gefunden. Die restlichen
geschützten Verzeichnisse können mit dieser Capability nicht beschrieben werden, sodass der
„File-Server“ den Zugang mit dem Fehler Zugriff verweigert bei Ausführung der Operation
verweigert. Auf Laufwerk Z wird entweder der Zugriff mit dem eben genannten Fehler oder in
\private\<ownSID> mit dem Fehler Zugang verweigert untersagt. Der Schreib-Test mit der
Tcb Capability zeigt, dass nur auf diejenigen Verzeichnisse zugegriffen werden kann, die auch
die Tcb Capability gewährt. Auf das \private Verzeichnis kann nicht zugegriffen werden. Der
„File-Server“ verweigert den Zugang mit dem Fehler Zugriff verweigert bei Ausführung der
Operation. Trotz Tcb Capability wird der schreibende Zugriff auf das Z Laufwerk mit Fehler
Zugang verweigert verwehrt. Beim Schreib-Test mit den beiden Capabilities Tcb und AllFiles
konnte auf alle geschützten Verzeichnisse schreibend zugegriffen werden. Eine Ausnahme ist
dabei wieder das Z Laufwerk, das mit dem Fehler Zugang verweigert den schreibenden Zugriff
verwehrte.
Die Ergebnisse der Data-Caging-Testfälle im Emulator brachten auch keine bedeutenden
Überraschungen gegenüber den Testgeräten. Mit der AllFiles Capability konnte im Emulator nur auf das \private Verzeichnis auf Laufwerk C schreibend zugegriffen werden. Das
\private\<ownSID> Verzeichnis wird bei den Emulator-Testfällen nicht automatisch erstellt,
der Zugriff auf dieses Verzeichnis wäre jedoch gegeben. Aber auch mit der AllFiles Capability
konnte auf das \private Verzeichnis im Laufwerk Z nicht schreibend zugegriffen werden. Der
Zugriff wurde mit dem Fehler Zugang verweigert verwehrt. Auf die restlichen durch das Data
Caging geschützten Verzeichnisse kann aufgrund unzureichender Capabilities nicht geschrieben werden. Wie schon bei den Testgeräten kann auch im Emulator ohne die entsprechende
Capabilities nur auf die privaten Verzeichnisse der Prozesse schreibend zugegriffen werden.
Da jedoch der SWInstaller während der Installation die zum Prozess gehörigen privaten Verzeichnisse erstellt, wird im Emulator dieses Verzeichnis nicht gefunden. Auf die verbleibenden
Verzeichnisse wird der schreibende Zugang aufgrund von mangelnden Capabilities verweigert.
Mit der Tcb Capability wird grundsätzlich nur der Zugang zu den geschützten Verzeichnissen
mit der AllFiles Capability verweigert. Auf die restlichen Verzeichnisse, mit Ausnahme des
Z Laufwerk, kann wie in der Spezifikation der PSA beschrieben, schreibend auf die einzelnen
Verzeichnisse zugegriffen werden. Mit den beiden Capabilities Tcb und AllFiles ist nun der
schreibende Zugriff auf alle geschützten Verzeichnisse im Emulator gegeben. Eine Ausnahme
macht da wie auch schon auf den Testgeräten das Laufwerk Z. Hier verweigert der „File-Server“
den schreibenden Zugang trotz Tcb Capability.
Die Testfälle, bei denen die Signierung der Installationspakete und die damit verbundene Vertrauenswürdigkeit der Installationspakete untersucht wurden, beeinflusste das Data Caging
in keiner Weise. Wie schon bei den jeweiligen Lese- und Schreib-Tests ohne die entsprechenden Capabilities können die Testanwendungen nur auf die frei beschreibbaren Verzeichnisse
zugreifen. Für das Data Caging zählen nur die entsprechende Capability und die entsprechende Signierung, mit der die Anwendung installiert werden kann. Den „File-Server“ kümmert
71
die Signierung der Anwendung wenig. Im Emulator konnten diese Testfälle nicht ausgeführt
werden.
Obwohl die Verzeichnisstruktur \sys, \resource, \private auf der virtuellen Speicherkarte nicht vorhanden ist, überprüft der Emulator bei Zugriff auf die Verzeichnisse zunächst
das Vorhandensein der entsprechenden Capabilities. Erst mit den entsprechenden Capabilities kann auf das Verzeichnis zugegriffen werden und falls es noch nicht existiert, wird der
entsprechende Fehler produziert. Ein Beispiel ist der zweite Testfall im Emulator. Ohne die
entsprechende Capability kann auf das geschützte Verzeichnis nicht zugegriffen werden, der
Fehler Zugriff verweigert bei Ausführung der Operation tritt auf. Bei Zugriff auf ein frei lesbares Verzeichnis trifft nur der Fehler Das spezifizierte Verzeichnis kann nicht gefunden werden
auf. Anhand dieses Verhaltens kann die Funktionsweise des Data Caging nachvollzogen und
das Verifikationskriterium erfüllt werden. Wie in der Spezifikation der PSA [1] beschrieben,
ist für das Data Caging nur der Pfad entscheidend. Somit zeigt sich, dass das Data Caging
auf weiteren zusätzlichen Laufwerken funktionieren würde.
Im Vergleich zwischen den einzelnen Testgeräten und mit dem Symbian-Versionen-Kriterium
ergeben sich bei den beiden Symbian Versionen 9.1 und 9.2 bei den Data-Caging-Tests keine
Unterschiede bei den Ergebnissen.
Die Ergebnisse der Emulatoren der verschiedenen Symbian Versionen 9.1, 9.2 und 9.3 unterscheiden sich im Wesentlichen untereinander nicht. Lediglich scheint das virtuelle Laufwerk in der Version 9.1 während der Tests korrumpiert worden zu sein. Ein weiterer kleiner
Unterschied ist, dass auf das \private Verzeichnis des virtuellen Laufwerks in Version 9.3
zugegriffen werden kann. In den beiden anderen Emulatoren ist das nicht möglich. Gemäß
dem Plattform-Kriterium kann im Vergleich zu den Testgeräten nur der Zugriff auf das Z
Laufwerk der Emulatoren hervorgehoben werden. Ein Nachteil der Emulatoren ist die teilweise mangelnde Unterstützung der virtuellen Speicherkarten in Bezug auf die Data-CagingVerzeichnisstruktur, die auch schon im Abschnitt 5.1.1 angesprochen wurde.
Der zweite Testbereich wurde beim File Eclipsing in drei Bereiche gegliedert. Dabei werden
zunächst Ergebnisse der Paket-Testfälle für alle Testgeräte vorgestellt. Anschließend werden
die Testfälle, die während der Installation versuchen, Dateien in eine Eclipsing-Situation zu
bringen, ausgeführt. Im letzten Bereich der File-Eclipsing-Testfälle werden die Ergebnisse der
Tests zur Laufzeit vorgestellt.
Paket-Tests
Im ersten Bereich der File-Eclipsing-Testfälle wird zunächst ein „Basis-Paket“ auf Laufwerk C
installiert. Dieses Installationspaket wird dabei mit verschiedenen Signierungen installiert. Im
ersten Test wird das „Basis-Paket“ selbst signiert. Wird nun versucht, ein neues Installationspaket, das zunächst selbst signierte wurde, mit dem gleichen Namen der bereits installierten
Anwendung auf Laufwerk E zu installieren und damit eine mögliche Eclipsing-Situation zu
erzeugen, so schlägt die Installation mit einem Aktualisierungsfehler auf allen Testgeräten
72
fehl. Wird erneut der Versuch unternommen, das neue Installationspaket zu installieren, diesmal jedoch durch ein Developer-Zertifikat signiert, so schlägt auch diesmal die Installation
mit demselben Fehler fehl. In einen letztem Testfall mit einer selbst signierten Basis wird die
Installation, auch wenn das Installationspaket mit einem „root“-Zertifikat signiert wurde, mit
dem schon erwähnten Fehler abgebrochen. Werden diese Testfälle mit einem „root“ signierten
Installationspaket als Basis für die weiteren Testfälle wiederholt, so wird bei jedem Testfall
die Installation mit dem Aktualisierungsfehler abgebrochen. Diese Testfälle zeigen, dass ein
komplettes Installationspaket unabhängig der Signierung der Anwendungen nicht durch ein
anderes Installationspaket in eine Eclipsing-Situation gebracht werden kann.
Installationstests
Der zweite Bereich prüft, ob einzelne Dateien auf Laufwerk C während der Installation durch
andere Dateien in eine Eclipsing-Situation gebracht werden können. Dafür werden die Tests
mit Text-, EXE- und DLL-Dateien durchgeführt. Zunächst werden diese Dateien in einem
„Basis-Installationspaket“ jeweils selbst und „root“ signiert installiert. Das „Basis-Installationspaket“ kopiert die Dateien in die definierten Verzeichnisse, sodass diese Dateien in den darauf folgenden Testfällen versucht werden, in eine Eclipsing-Situation zu führen. Im ersten
Testfall wird versucht, eine Text-Datei mit verschiedenen Signierungen die zuvor installierte Text-Datei in einen nicht geschütztem Verzeichnis in eine Eclipsing-Situation zu bringen.
Der Versuch, diese Situation herzustellen, schlug mit allen Signierungen fehl. Selbst die Installation eines „root“ signierten Installationspakets wurde mit einem Aktualisierungsfehler
abgebrochen. Das gleiche Bild zeichnet sich ab, wenn versucht wird, eine EXE-Datei in eine
Eclipsing-Situation zu bringen. Das Installationspaket, das versucht, die EXE-Datei auf das E
Laufwerk zu kopieren und dadurch eine Eclipsing-Situation hervorzurufen, kann nicht installiert werden. Mit keiner Signierung ist es möglich, eine EXE-Datei in eine solche Situation zu
bringen. Beim Versuch, die Tests mit DLL-Dateien zu wiederholen, konnten weder die selbst
signierten DLL-Dateien auf Laufwerk C in eine Eclipsing-Situation gebracht werden noch die
„root“ signierten Testfälle. Auch verschiedene Signierungen der Testfälle, die diese Situation
herstellen sollten, wurden immer mit einem Aktualisierungsfehler abgebrochen.
Laufzeit-Tests
Im abschließenden Bereich wird versucht, Eclipsing-Situationen zur Laufzeit zu erzeugen. Dafür werden zunächst, wie auch im zweiten Testbereich, Testanwendungen installiert, die jeweils
selbst und „root“ signiert wurden und während der Installation Text-Dateien in nicht geschützte Verzeichnisse auf Laufwerk C kopieren. Im ersten Testfall konnte mit allen Signierungen der
Installationspakete eine entsprechende Text-Datei auf Laufwerk E erstellt werden, die den gleichen Namen trug wie schon die Datei auf Laufwerk C. Somit konnte eine Eclipsing Situation
erstellt werden. Im zweiten Testfall wird erneut versucht, eine Eclipsing-Situation herzustellen, diesmal wird aber das „Basis-Installationspaket“ mit einem „root“-Zertifikat signiert. Auch
in diesem Fall kann eine Eclipsing-Situation zur Laufzeit hervorgerufen werden. Im Emulator können die Tests zur Laufzeit auch ausgeführt werden. Hierbei können jedoch nicht die
verschiedenen Signierungen der „Basis-Installationspakete“ untersucht werden. Dennoch kann
im Emulator die Text-Datei auf Laufwerk E parallel zur Text-Datei auf Laufwerk C erstellt
werden und würde aufgrund der Eclipsing-Regel eine Eclipsing-Situation hervorrufen.
73
Werden nun die Tests auf allen vier Testgeräten miteinander verglichen, so können zusammen mit dem Symbian-Versionen-Kriterium keinerlei Unterschiede zwischen den Testgeräten
festgestellt werden. Auch die Laufzeit-Tests im Emulator stimmen mit den Ergebnissen der
Testgeräte überein, sodass nach dem Plattform-Kriterium keine Unterschiede bei den LaufzeitTests festgestellt werden konnten.
Der File-Overwriting-Testbereich definiert vier Bereiche. Der erste Bereich beschäftigt sich mit
der Überschreibbarkeit des SA-Installationstyps und dient dabei der Verifikation der Funktionalität. Im nächsten Bereich versuchen die Testfälle verschiedene bereits vorhandene Dateien
während der Installation zu überschreiben. Der dritte Bereich dient der Untersuchung und Verifikation des Update-Verhaltens verschiedener Installationstypen. Abschließend werden zur
Laufzeit Text-Dateien versucht zu überschreiben.
Paket-Tests
Im ersten File-Overwriting-Bereich werden die Testfälle als Paar zweier Installationsdateien
gesehen. Dabei dient das erste Installationspaket als „Basis-Anwendung“, die durch das nächste
zugehörige Installationspaket überschrieben beziehungsweise aktualisiert wird. Der Installationstyp des überschreibenden Installationspaketes ist in diesem Bereich als SA-Installationstyp
in der Version 2,0,0 definiert. Das erste Installationspaar ist selbst signiert und das überschreibende Installationspaket kann nach Bestätigung der Meldung Überschreiben bereits vorhandener Version 1.0.0 durch 2.0.0 ersetzen ohne Fehler installiert werden. Auch die zwei
darauf folgenden Installationspaare, deren überschreibende Installationspakete jeweils mit einem Developer- beziehungsweise mit einem „root“-Zertifikat signiert wurden, können ohne
Probleme nach Bestätigung der Überschreibung der vorhandenen Anwendung installiert werden. Bei den nächsten Installationspaaren ist die „Basis-Anwendung“ jeweils „root“ signiert.
Versucht nun ein selbst signiertes Installationspaket die „Basis-Anwendung“ zu überschreiben,
muss zwar zunächst das Überschreiben der „Basis-Anwendung“ bestätigt werden, aber daraufhin wird die Installation mit einem Aktualisierungsfehler abgebrochen. Das Überschreiben
der „Basis-Anwendung“ durch eine Developer-Zertifikat signierte Anwendung funktioniert auf
dem Nokia E61 nach Bestätigung auch ohne Probleme. Der abschließende Testfall in diesem
Bereich definiert ein „root“ signiertes Installationspaar, das auf allen Testgeräten ohne Fehler
ausgeführt werden kann.
Installationstests
Im nächsten Bereich der File-Overwriting-Testfälle werden Text-, EXE- und DLL-Dateien
während der Installation versucht zu überschreiben. Dafür werden die Text-Dateien zunächst
in einem selbst signierten und anschließend in einem „root“ signierten Installationspaket in ein
nicht geschütztes Verzeichnis kopiert. Die zugehörigen Testfälle versuchen mit allen Signierungen diese Text-Dateien zu überschreiben. Keinem dieser Testfälle ist es möglich, die TextDateien zu überschreiben. Beim Versuch die Text-Datei zu überschreiben, wurden alle Installationen mit einem Aktualisierungsfehler abgebrochen. Nicht einmal „root“ signierte Testfälle
74
konnten diese Text-Dateien überschreiben. Ein ähnliches Verhalten konnten beim Überschreiben der EXE-Dateien beobachtet werden. Kein Testfall konnte die EXE-Datei in \\sys\\bin
während der Installation überschreiben. Alle Testfälle schlugen mit einem Aktualisierungsfehler fehl. Dabei machte es keinen Unterschied, ob die zu überschreibenden EXE-Dateien durch
ein selbst signiertes oder ein „root“ signiertes Installationspaket installiert wurden. Bei den abschließenden Tests mit den DLL-Dateien konnte auch kein anderes Verhalten gegenüber dem
Überschreiben der EXE-Dateien beobachtet werden. Wie bei den EXE-Dateien konnten auch
hier nicht die jeweiligen DLL-Dateien mit verschiedenen Signierungen überschrieben werden.
Jeder Versuch wurde mit einem Aktualisierungsfehler abgebrochen.
Update-Tests
Im dritten File-Overwriting-Bereich werden wie auch schon im ersten Bereich die Testfälle
als Paar zweier Installationsdateien gesehen. Das erste Installationspaar ist selbst signiert
und das überschreibende Installationspaket, das als PU-Installationstyp definiert ist, kann ohne Fehler installiert werden. Im nächsten Testfall ist das überschreibende Installationspaket
ebenfalls als PU-Installationstyp definiert, diesmal jedoch „root“ signiert. Auch dieses Installationspaar wird ohne Probleme installiert. Wird jedoch die Signierung vertauscht und damit
das überschreibende Installationspaket selbst signiert, so wird die Installation aufgrund eines
Aktualisierungsfehlers abgebrochen. Werden die Tests bei dem SP-Installationstyp genauso
definiert wie die vorherigen PU-Testfälle, so schlägt nur beim Versuch, ein „root“ signiertes
Installationspaket durch ein selbst signiertes Installationspaket zu aktualisieren, mit einem
Aktualisierungsfehler fehl. Die restlichen beiden SP-Testfälle werden ohne Fehler installiert.
Beim abschließenden Test in diesem Bereich, wird entgegen der Empfehlung der Spezifikation
der PSA eine bereits vorhandene Datei durch ein SP-Installationspaket aktualisiert. Gemäß
der Spezifikation wird die Installation aufgrund eines Aktualisierungsfehlers abgebrochen.
Laufzeit-Tests
Im letzten Bereich der File-Overwriting-Testfälle wird die Möglichkeit, Dateien zur Laufzeit
zu überschreiben, untersucht. Zu diesem Zweck werden zunächst selbst und „root“ signierte
Testfälle installiert, die nach Ausführung drei Text-Dateien in C:\\Test\\Overwriting erstellen. Diese Dateien sollen anschließend zur Laufzeit von den anderen Testfällen versucht
werden zu überschreiben. Die Text-Dateien, die durch den selbst signierten Testfall erstellt
wurden, konnten ohne Fehler von den übrigen Testanwendungen überschrieben werden. Selbst
die Text-Dateien, die durch den „root“ signierten Testfall erstellt wurden, konnten zur Laufzeit
überschrieben werden. Wurden die Testfälle anschließend noch in den Emulatoren ausgeführt,
zeichnete sich zur Laufzeit das gleiche Bild ab.
Werden die Testfälle nun nach dem Symbian-Versionen-Kriterium bewertet und dabei die einzelnen Testfälle zwischen Symbian Version 9.1 und 9.2 auf den Testgeräten miteinander verglichen, so können keine Unterschiede zwischen den Symbian Versionen in den Testbereichen
festgestellt werden. Das Plattform-Kriterium kann nur bei den Laufzeit-Tests herangezogen
werden und besagt, dass die Ergebnisse sich zwischen den Emulatoren und den Testgeräten
zur Laufzeit nicht unterscheiden.
75
5.5.4. SWInstaller
Die SWInstaller-Testfälle untersuchen die verschiedenen Funktionsmöglichkeiten des Symbian
Version 9 SWInstallers. Die Tests sind dabei in drei Bereiche unterteilt. Im ersten Bereich
werden die User Capabilities mit verschiedenen SWIPolicies, die im Anhang A.3.1 aufgeführt
sind, untersucht. Der nächste Bereich überprüft die Fähigkeit des SWInstallers, bestimmte
Dateien in geschützte Verzeichnisse zu kopieren. Im abschließenden Bereich wird in einem
kurzen Test ein MIME-Typ untersucht. Hierbei wurden auch verschiedene SWIPolicies benutzt,
damit der möglichst vollständige Funktionsumfang des SWInstallers erfasst werden kann.
Auf dem Emulator konnten diese Testfälle nicht durchgeführt werden und deshalb kann das
Plattform-Kriterium in diesem Testbereich auch nicht herangezogen werden.
Capability-Tests
Zu Beginn werden die Testfälle mit der Standard SWIPolicy durchgeführt. Dabei sind vier
Testfälle mit steigenden Capabilities definiert worden, deren Capabilities mit den weiteren
UserCapabilities innerhalb der SWIPolicy überstimmen. Standardmäßig ist der Parameter
UserCapabilities in der SWIPolicy mit den User Capabilities definiert. Der erste nicht signierte Testfall ließ sich nur auf dem Nokia E61 installieren, da auf den restlichen Testgeräten
die Installation von nicht signierten Anwendungen nicht erlaubt war. Die selbst signierten
Testfälle konnten zwar auf allen Testgeräten installiert werden, aber wiederum nur diejenigen, die mit User Capabilities definiert wurden. In den Testfällen, die durch ein DeveloperZertifikat signiert wurden, konnte dieses wieder nur auf dem Nokia E61 installiert werden, da
das Developer-Zertifikat nur für das E61 gültig war. Es konnte jedoch ein weiterer Testfall installiert werden, der mit einer Capability aus den Developer-Capabilities definiert war. Schließlich konnten die Testfälle mit dem „root“-Zertifikat auf allen Testgeräten installiert werden.
Hierbei konnten sowohl Testfälle mit Symbian-Signed-Capabilities als auch mit ManufacturerCapabilities installiert werden. Interessant werden die Ergebnisse erst, wenn eine andere SWIPolicy zum Einsatz kommt. Die erste SWIPolicy wurde so definiert, dass auf allen Testgeräten
nicht signierte Anwendungen installiert werden konnten und zusätzlich wurde innerhalb der
UserCapabilities eine weitere Capability aus den Developer-Capabilities hinzugefügt. Nach
der Modifikation an der SWIPolicy konnten auf allen Testgeräten nicht signierte Testfälle
installiert werden. Zusätzlich konnten nicht signierte und selbst signierte Testfälle mit den
zuvor definierten Capabilities in der SWIPolicy installiert werden. Damit war die Installation
von Testfällen möglich, für die vorher mindestens ein Developer-Zertifikat nötig war. Nach der
Veränderung der zweiten SWIPolicy konnten per Definition keine nicht signierten Testfälle installiert werden, aber dafür wurden die UserCapabilities in der SWIPolicy zusätzlich zur der
Developer-Capability aus der ersten SWIPolicy mit einer Symbian Signed Capability spezifiziert. Das hatte zwar zur Folge, dass die nicht signierten Testfälle nicht mehr installiert werden
konnten, dafür konnten aber die selbst signierten Testfälle mit einer Developer-Capability und
zusätzlich auch mit einer Symbian Signed Capability installiert werden. In der letzten SWIPolicy wird der Versuch unternommen, zusätzlich zu den beiden vorherigen Capabilities auch
noch die Tcb Capability innerhalb der UserCapabilities zu definieren. Eine weitere Änderung in der SWIPolicy ist das Gewähren der Installation von nicht signierten Anwendungen.
Das Ergebnis dieser Veränderung war, dass alle Testfälle, selbst die Testanwendungen mit
der Tcb Capability, ohne eine Signierung oder mit einem selbst erstellten Zertifikat installiert
werden konnten. Diese Testfälle zeigen, dass die UserCapabilities in der SWIPolicy nicht
76
nur auf die User Capabilities beschränkt sind. In einem weiteren Testfall mit dieser SWIPolicy werden noch die Einstellungen für den SWInstaller auf dem Testgerät verändert. Wird
hier eingestellt, dass nur signierte Anwendungen installiert werden dürfen, so konnten anschließend nur noch die Testfälle installiert werden, die mit einem „root“-Zertifikat signiert
wurden.
Kopier-Tests
Bei den SWInstaller-Tests, die die Fähigkeit des SWInstallers, verschiedene Dateien in geschützte Ordner zu kopieren, untersuchen, wurde versucht, Text-Dateien und EXE-Dateien in
die geschützten Verzeichnisse während der Installation zu kopieren. Zunächst wurde versucht,
eine Text-Datei nach \\sys\\bin auf Laufwerk C zu kopieren. Dabei konnte kein Testfall
installiert werden. Selbst bei einem „root“ signierten Installationspaket wurde die Installation mit dem Fehler Installation nicht möglich abgebrochen. Wurde hingegen versucht, eine
EXE-Datei in dieses Verzeichnis zu kopieren, war das ohne Probleme möglich. Denn nur in
\\sys\\bin können EXE-Dateien ausgeführt werden. In das \\resource Verzeichnis konnten
sowohl Text- als auch EXE-Datei kopiert werden und dabei war es nicht entscheidend, mit
welchem Zertifikat der Testfall signiert wurde. Eine Text-Datei kann auch als Ressource-Datei
angesehen werden und da eine EXE-Datei außerhalb von \\sys\\bin nicht ausgeführt werden kann, muss der SWInstaller das Kopieren einer EXE-Dateien in dieses Verzeichnis nicht
verhindern. Bei einem weiteren Testfall wird versucht, beide Dateien direkt in das \\private
Verzeichnis zu kopieren. Eine Datei in das \\private Verzeichnis zu kopieren, kann mit dem
Versuch, eine Datei in ein privates Verzeichnis eines anderen Prozesses zu kopieren, gleichgesetzt werden. Wird nun in Symbian OS Version 9.1 versucht, diesen Testfall zu installieren, so
kann weder mit der Text- noch mit der EXE-Datei der Testfall installiert werden. Bei jedem
Testfall wird unabhängig des Zertifikates mit dem der Testfall signiert wurde, die Installation mit dem Fehler Installation nicht möglich abgebrochen. Bei den restlichen Testgeräten,
auf denen Symbian OS Version 9.2 ausgeführt wird, konnten die Testfälle ebenfalls nicht
installiert werden. Hier wurde die Installation jedoch mit dem Fehler Datei fehlerhaft abgebrochen. Die letzten Tests in diesem Bereich versuchten, die Text- und EXE-Datei in ihr
eigenes privates Verzeichnis zu kopieren. Dass alle Testfälle die Text-Dateien in ihr Verzeichnis
kopieren konnten, war nicht überraschend. Sogar die EXE-Dateien konnten mit jeder Signierung der Testfälle in dieses Verzeichnis kopiert werden. Wie auch schon die EXE-Dateien in
das \\resource Verzeichnis kopiert werden konnten, besteht auch hier keine Gefahr für das
System, wenn eine EXE-Datei in das eigene private Verzeichnis kopiert wird, da die Datei in
diesem Verzeichnis nicht ausgeführt werden kann.
MIME-Test
Im abschließenden Test wurde während der Installation versucht, über einen MIME-Typ eine
EXE-Datei auszuführen. Die zusätzliche EXE-Datei wird dabei im Installationspaket mitgeliefert. In der Standard SWIPolicy wird der Parameter AllowRunOnInstallUninstall auf false
gesetzt. Mit dieser SWIPolicy konnten zwar die nicht signierten und selbst signierten Testfälle installiert werden, aber die mitgelieferte EXE-Datei wurde nicht ausgeführt. Nur wenn die
Testfälle durch ein Developer- oder ein „root“-Zertifikat signiert wurden, konnten die Testfälle
77
installiert werden und die mitgelieferte EXE-Datei wurde auch ausgeführt. Werden diese Testfälle jedoch mit der ersten SWIPolicy, in der der Parameter AllowRunOnInstallUninstall
auf true gesetzt wurde, ausgeführt, so können nicht nur die nicht signierten oder selbst signierten Testfälle installiert werden, sondern die mitgelieferten EXE-Dateien wurden während
der Installation ausgeführt.
5.5.5. Certificate
Die Testfälle des Certificate-Testbereichs untersuchen die verschiedenen Zertifikate, die in
Symbian OS 9 eingesetzt werden. Bei der Untersuchung wurden die Tests unterstützend
mit verschiedenen SWIPolicies, die im Anhang A.3.2 aufgeführt sind, durchgeführt. In diesem Testbereich konnte der Emulator nicht verwendet werden, sodass auch das PlattformKriterium nicht angewendet werden konnte.
Zunächst werden die Ergebnisse mit der Standard SWIPolicy, die sich beim E61 nur durch
den Parameter AllowUnsigned=true von den SWIPolicies der anderen Testgeräte unterscheidet, vorgestellt. Nicht signierte Testfälle konnten nur auf dem E61 installiert werden, da die
SWIPolicy auf den anderen Testgeräten nicht signierte Anwendungen nicht zulässt. Hierbei
konnten auch nur die Testfälle installiert werden, die User Capabilities benutzen. Die restlichen Testfälle konnten mit mehr Capabilities oder nicht signiert nicht installiert werden, sodass
korrekterweise eine Anwendung ohne eine Signierung nur dann installiert werden kann, wenn
sie nur User Capabilities benutzt und die SWIPolicy nicht signierte Anwendungen zulässt. Die
selbst signierten Testfälle ließen sich zwar auf allen Testgeräten installieren, aber da auch hier
der SWInstaller keine vertrauenswürdige Grundlage findet, konnten nur die Testfälle mit User
Capabilities installiert werden. Ein altes Developer-Zertifikat besaß ich nur noch für das E61,
sodass diese Testfälle auch nur auf diesem Gerät untersucht werden konnten. Wie nicht anders
zu erwarten war, konnten nur die Testfälle installiert werden, die mit User Capabilities oder
Developer Capabilities ausgestattet waren. Auf den anderen Testgeräten konnte dieses Verhalten aber auch beobachtet werden, wenn die Testanwendungen über Open Signed signiert
wurden. Über Open Signed können maximal Developer Capabilities gewährt werden. Mit Hilfe des „root“-Zertifikates konnten alle Capabilities, die Symbian OS 9 bereitstellt, verwendet
werden. Selbst die Tcb Capability konnte mit diesem Zertifikat gewährt werden.
Bei der Untersuchung des Installationsverhaltens mit verschiedenen Parametern der SWIPolicy wurden zunächst drei verschiedene SWIPolicies verwendet. Die beiden ersten veränderten Policies sollten die Zertifikatserweiterungen untersuchen. Zu diesem Zweck wurde der
MandatePolicies Parameter der SWIPolicy entgegen dem Standard auf true gesetzt. Die
restlichen Parameter blieben unverändert. Bei diesen Tests konnten nur diejenigen Testfälle
installiert werden, die nur User Capabilities benutzten. Alle anderen Testfälle, die mehr Capabilities verwendeten, auch Anwendungen die mit einem „root“-Zertifikat signiert wurden,
konnten nicht installiert werden. Das interessante hierbei ist, dass die jeweiligen Zertifikate,
mit denen die Testfälle signiert wurden, vom SWInstaller nicht erkannt wurden. Das ist darauf
zurückzuführen, dass der Parameter MandatePolicies die spezifizierten Oids der SWIPolicy
in den jeweiligen Zertifikaten fordert. Findet der SWInstaller keine dieser Oids in dem Zertifikat der Anwendung, kann der SWInstaller die Vertrauenswürdigkeit des Installationspaketes
nicht verifizieren und behandelt es somit wie ein nicht signiertes Installationspaket.
78
Wird nun bei der Zertifikatsuntersuchung zusätzlich zum MandatePolicies noch der Mandate
CodeSigningExtension Parameter in einer weiteren SWIPolicy gesetzt, kann keine Testanwendung installiert werden. Selbst Testfälle mit User Capabilities werden mit dem Fehler Zertifikatsfehler. Bitte wenden sie sich an den Programmlieferanten. an der Installation gehindert.
Das ist dadurch zu erklären, dass die jeweiligen Zertifikate nicht die Zertifikatserweiterung OID
1.3.6.1.5.5.7.3.3 besitzen. Nicht signierte Anwendungen konnten nicht installiert werden,
da es ihnen in der SWIPolicy nicht erlaubt wurde.
Bei der letzten SWIPolicy sollte das OCSP untersucht werden. Dafür wurde der Parameter
OcspMandatory auf true und OcspEnabled ist standardmäßig auf true gesetzt. Zusätzlich
dazu sind die SWInstaller-Einstellungen auf den Testgeräten entscheidend. Ist die OCSPPrüfung in den Einstellungen deaktiviert, können trotz OcspMandatory=true alle Testfälle
installiert werden. Wird hingegen die OCSP-Prüfung eingeschaltet und in den SWInstallerEinstellungen auf Bestätigung nötig, konnten nur die nicht signierten Anwendungen installiert werden. Hierbei ist AllowUnsigned=true. Bei den restlichen signierten Anwendungen
wird eine Zertifikatsprüfung durchgeführt, jedoch endet sie bei jedem signierten Testfall mit
dem Fehler Online-Zertifikatsprüfung nicht möglich. Einstellungen überprüfen. Dieser Fehler ist wahrscheinlich auf das Fehlen der Standard-Web-Adresse innerhalb der SWInstallerEinstellungen zurückzuführen. Zu diesem Zweck sollte jedoch das entsprechende Zertifikat
eine Adresse enthalten, sodass mit ihrer Hilfe die Gültigkeit des Zertifikates überprüft werden
kann.
Die unterschiedlichen Testgeräte beeinflussten die Testergebnisse in keiner Weise, sodass gemäß dem Symbian-Versionen-Kriterium weder zwischen den Testgeräten noch zwischen den
Symbian Versionen Unterschiede aufgetreten sind. Durch die drei verschiedenen SWIPolicies konnten die für diesen Testbereich relevanten Parameter der SWIPolicy gemäß dem
SWIPolicy-Kriterium verifiziert werden. Dadurch konnte auch der Parameter für das OCSP in
den SWInstaller-Einstellungen, wie es das SWInstaller-Einstellungen-Kriterium fordert, überprüft werden. Bei der Durchführung der Testfälle mit den verschiedenen SWIPolicies konnten
bei den standardmäßig vorhandenen SWIPolicies gemäß dem Software-Branding-Kriterium
keine Unterscheide in den SWIPolicies der Testgeräte gefunden werden. Die SWIPolicies der
Testgeräte, die ein Software-Branding aufwiesen, enthielten die identischen Definitionen der
Parameter, die auch Testgeräte ohne solch ein Software-Branding bereitstellten.
5.5.6. Capabilities
Die Testfälle der Capabilities sind in drei Bereiche geteilt. Im ersten Bereich werden die
DLL-Regeln untersucht, im zweiten Bereich die Funktionalität der einzelnen Capabilities und
schließlich wird im dritten Bereich die Client/Server-Architektur untersucht. Die Ergebnisse
werden einzeln für alle drei Bereiche für beide Plattformen präsentiert und am Ende des
Abschnitts miteinander verglichen.
DLL-Regeln-Tests
Im ersten Bereich der Capabilities-Testfälle wurde bei den Tests zunächst jeweils eine EXEDatei mit einer DLL „verlinkt“. Im nächsten Schritt wurde sozusagen eine DLL-Kette aufgebaut, in der eine EXE-Datei eine Funktion aus einer DLL lädt, die wiederum eine Funktion
79
einer weiteren DLL lädt. Auf diese Weise werden drei DLL ineinander „verlinkt“. Die Ergebnisse der einzelnen Tests spiegeln genau das von Symbian spezifizierte Verhalten wider.
Die unterschiedlichen Signierungen spielen dabei keine Rolle. Nur die Capabilities der EXEDateien und der DLL sind entscheidend. Bei den einzelnen Tests konnten die Anwendungen
mit den gleichen oder weniger Capabilities als die DLL, die die Testfälle laden, ausgeführt
werden. Besitzen die Anwendungen mehr Capabilities als die DLL selbst, so konnte die Testanwendung, die die DLL laden sollte, mit dem Fehler Datei konnte aus Sicherheitsgründen
nicht ausgeführt werden nicht gestartet werden. Die Testanwendungen, die die drei ineinander
geschachtelten DLL laden sollten, zeigten auch kein untypisches Verhalten. Die CapabilityRegeln konnten gemäß dem Regeln-Kriterium auch in diesem Fall durch die Testfälle die
korrekte Funktionsweise verifizieren. Abbildung 5.2 verdeutlicht diesen Zusammenhang noch
einmal grafisch, wobei „none“ für keine verwendete Capability und „Cx“ für die verwendeten
Capabilities steht. Im Emulator wurden die identischen Testfälle benutzt, jedoch ohne die Si-
Abbildung 5.2.: Ergebnisse DLL-Regeln
gnierung der Testfälle zu untersuchen. Die Ergebnisse brachten auch hier keine unerwarteten
Resultate. Die Capability-Regeln konnten auch im Emulator ohne Ausnahmen verifiziert werden, sodass das Regeln-Kriterium auch hier erfüllt wird. Die Abbildung 5.2 kann hier ebenfalls
zur Verdeutlichung herangezogen werden.
Die einzelnen Ergebnisse zwischen den vier Testgeräten unterscheiden sich in keinem einzigen
Testfall, sodass das Symbian-Versionen-Kriterium hier zu keinen Unterschieden führt. Auch
die einzelnen Emulator Versionen unterscheiden sich untereinander nicht. Werden nun nach
dem Plattform-Kriterium beide Plattformen miteinander verglichen, so verhalten sich beide
80
Plattformen identisch und das spezifizierte Verhalten gemäß der PSA wird ohne Ausnahmen
eingehalten.
Capability-Tests
Der nächste Bereich untersucht ausgewählte Capabilities, ob zur Ausführung der jeweiligen
Funktion die dokumentierte Capability benötigt wird. Dafür wurden User Capabilities, System Capabilities und Device Manufacturer Capabilities benutzt. Bei den User Capabilities,
die zunächst auf den Testgeräten untersucht wurden, zeigte sich, dass nur zwei der getesteten Capabilities gemäß der Dokumentation ausgeführt werden konnten. Ein Test zeigte, dass
die geforderte Capability einer Funktion in der Dokumentation bei der Ausführung auf dem
Testgerät nicht benötigt wurde. In einem anderen Testfall konnte festgestellt werden, dass
zur Ausführung einer Funktion eine zusätzliche Capability benötigt wurde, die in der Dokumentation jedoch nicht zu finden war. Bei den getesteten System Capabilities konnte dieses
Verhalten nicht beobachtet werden. Hier wurden die geforderten Capabilities auch stets benötigt und ohne die entsprechende Capability konnte die jeweilige Funktion nicht ausgeführt
werden. Bei den Device Manufacturer Capabilities konnte ein ähnliches Bild festgestellt werden. Aber nicht nur anhand der beiden Testfälle in diesem Bereich, sondern auch durch die
Data-Caging-Testfälle, bei denen nur mit den entsprechenden Capabilities auf die geschützten Bereiche zugegriffen werden konnte, konnte die korrekte Funktionsweise der Manufacturer
Capabilities gezeigt werden. Gemäß dem Symbian-Versionen-Kriterium konnten keine Unterschiede zwischen den Symbian Versionen der Testgeräte gefunden werden. In den Emulatoren
konnte die gleiche Verhaltensweise beobachtet werden, sodass das Plattform-Kriterium bei
diesen Testfällen keine Unterschiede gegenüber den Testgeräten aufgekommen sind. Jedoch
konnten erst im Emulator die fehlenden User Capabilities bei den jeweiligen Testfällen erkannt
werden.
Client/Server-Tests
Im abschließenden Bereich werden die Client/Server-Testfälle als Paar zweier Prozesse definiert. Dabei können laut Definition beide Prozesse gleichzeitig oder separat spezifiziert werden.
Die Testfälle implementieren einen einfachen Uhrzeit-Server, dessen Clients auf Anfrage die
aktuelle Zeit vom Server erhalten. In dem ersten Test werden Client und Server jeweils mit
keinen Capabilities ausgestattet. Beide Prozesse können ausgeführt werden und der Client
kann ohne Probleme auf den Server zugreifen. Das gleiche Bild zeichnet sich ab, wenn beide
Prozesse mit den identischen Capabilities ausgestattet werden. Im nächsten Testfall wird der
Server mit drei Capabilities, darunter zwei User Capabilities und der AllFiles Capability,
ausgestattet. Wird hingegen der Client mit keiner Capability ausgestattet, so kann er dennoch
auf den Server zugreifen und die korrekte Zeit erhalten. Im Gegenzug wird der letzte Testfall
genau umgekehrt zum vorherigen Testfall definiert, sodass der Client die drei Capabilities
besitzt und der Server diesmal keine Capabilities. Auch in diesem Fall kann der Client die
korrekte Zeit vom Server erhalten.
Der Vergleich zwischen Emulator und den Testgeräten durch das Plattform-Kriterium bringt
keinen Unterschied zwischen den Plattformen hervor. Auch nach dem Symbian-VersionenKriterium verhalten sich die verschiedenen Testgeräte untereinander völlig identisch, sodass
in der Ausführung der Testfälle keine Unterschiede festgestellt werden.
81
5.5.7. Integrity
Die Integrity-Testfälle können in vier Bereiche unterteilt werden. Im ersten Bereich wird die
Integrität der Installationsdateien untersucht, wohingegen in nächsten Bereich nur die Integrität der installierten EXE-Datei von Bedeutung ist. Die beiden restlichen Bereiche untersuchen
noch die Integrität der installierten Ressource-Dateien und die Integrität vorinstallierter Anwendungen (PU).
Installationspakete
Die Ergebnisse des ersten Testbereichs zeigen, dass nur die SIS-Dateien installiert werden
konnten, an die Null-Bytes an das Ende der Datei gehängt wurden. Die restlichen Testfälle konnten aufgrund der Veränderung nicht installiert werden. Der SWInstaller verweigerte
die Installation mit den Fehlern Installation ’Name der Anwendung’ nicht unterstützt oder
Installation nicht möglich. Im Emulator konnten diese Testfälle nicht ausgeführt werden, da
der Emulator das Installieren von Anwendungen nicht unterstützt und somit kann auch das
Plattform-Kriterium nicht angewendet werden. Beim Symbian-Versionen-Kriterium hingegen
verhalten sich die Installationspakete auf allen Testgeräten gleich.
EXE-Dateien
Der nächste Bereich stellt die Ergebnisse der Testfälle vor, in denen die Integrität der EXEDateien auf beiden Laufwerken C und E untersucht wird. Bei den Testfällen auf Laufwerk C
konnten auf dem Nokia E61 nur die Testfälle ohne Fehler ausgeführt werden, deren Capabilities nachträglich verändert wurden. Die Testfälle, in denen gezielt Hex-Werte der EXE-Dateien
verändert wurden, konnten aufgrund der Veränderung auf dem E61 nicht gestartet werden. Im
Gegensatz dazu konnten alle Testfälle auf den restlichen Testgeräten ohne Fehler ausgeführt
werden. Der Unterschied ist dadurch zu erklären, dass für die Veränderung immer die gleiche Byte-Position herangezogen wurde und aufgrund der verschiedenen Symbian Versionen
der Testgeräte sich die Anordnung innerhalb der Datei verändert hat. Bei den Testfällen auf
Laufwerk E konnten die Testfälle grundsätzlich nur ausgeführt werden, wenn nach der Veränderung der EXE-Datei auch die Hash-Werte der jeweiligen EXE-Dateien angepasst wurden.
Wurden hingegen die Hash-Werte nicht angepasst, so verweigerten die Anwendungen den
Start mit dem Fehler Datei kann aus Sicherheitsgründen nicht ausgeführt werden. Von den
beiden verbliebenen Testfällen konnte nur der Test, in dem die Capabilities der EXE-Datei
verändert wurden, auf allen Testgeräten ohne Fehler ausgeführt werden. Der Testfall, bei dem
die Hex-Werte verändert wurden, konnte, wie auch schon auf dem Laufwerk C, nur auf der
Symbian Version 9.2 ohne Fehler ausgeführt werden. Wenn hier die Ergebnisse der Testfälle
nun nach dem Symbian-Versionen-Kriterium miteinander verglichen werden, fallen nur die
versionsbedingten Unterschiede auf der Hex-Ebene auf. Die anderen Testfälle verhalten sich
aber identisch und zeigen keine Unterschiede. Im Emulator konnten nur die Integrity-Testfälle
auf dem Laufwerk C durchgeführt werden und dabei auch nur die Testfälle, in denen die EXEDateien auf Hex-Ebene verändert werden. Die Capabilities konnten dabei nicht verändert
werden, da sich das Dateiformat der EXE-Datei im Emulator von der EXE-Datei auf dem
Mobiltelefon unterscheidet und die dafür vorgesehene Anwendung nur die EXE-Dateien der
Mobiltelefone verändern kann. Von den beiden Testfällen auf dem Emulator konnte nur der
82
erste ohne Fehler ausgeführt werden. Beim Start des zweiten Testfalls wurde die Ausführung mit einem Systemfehler abgebrochen. Die Emulator-Testfälle können nicht direkt gemäß
dem Plattform-Kriterium mit Ergebnissen auf den Testgeräten verglichen werden, da sich die
Dateiformate der beiden Plattformen unterscheiden.
Ressource-Dateien
Im dritten Bereich konnten alle Testfälle trotz der jeweiligen Modifikation an der RessourceDatei oder an der mitgelieferten Text-Datei ohne Probleme auf allen Testgeräten ausgeführt
werden. Dabei war es nicht entscheidend, auf welchem Laufwerk diese Tests durchgeführt wurden. Beispielsweise wurde der veränderte Autorname in der Ressource-Datei bei Ausführung
des Tests dargestellt. Beim Heranziehen des Symbian-Versionen-Kriteriums zeigt sich, dass es
keine Unterschiede in den Ergebnissen zwischen den Testgeräten gibt. Aber auch im Emulator
konnten zwei der drei Testfälle ohne Probleme ausgeführt werden. Bei dem letzten Testfall
im Emulator wurde innerhalb der Ressource-Datei ein Zeichenstring um ein Byte vergrößert.
Die Folge dieser Veränderung war, dass die Anwendung zwar gestartet werden konnte, bei
der Auswahl des entsprechenden Menüpunktes die Anwendung jedoch mit einem Fehler geschlossen wurde. Beim Vergleich gemäß dem Plattform-Kriterium können keine Unterschiede
zwischen den vergleichbaren Testfällen gefunden werden.
Vorinstallierte Anwendungen
Der abschließende Bereich untersucht die Integrität von EXE-Dateien vorinstallierter Anwendungen. Da diese Funktion im Emulator nicht unterstützt wird, sind diese Testfälle nur auf den
Testgeräten ausgeführt worden. Das Plattform-Kriterium kann deshalb bei diesem Test nicht
herangezogen werden. Der Aufbau der Testfälle ist mit den normalen Testfällen zur Integrität
der EXE-Dateien vergleichbar. Bei den Testfällen, die mit Hilfe der Stub-Dateien installiert
und anschließend verändert wurden, konnten zunächst nur die Testfälle ausgeführt werden,
dessen Hash-Werte angepasst wurden. Die Testfälle mit den veränderten Capabilities konnten
dabei ohne Fehler gestartet werden. Auch auf den Symbian Version 9.2 Testgeräten konnten die auf Hex-Ebene veränderten Testfälle ohne Fehler ausgeführt werden. Lediglich beim
E61 konnte dieser Testfall nicht durchgeführt werden, denn beim Versuch die Anwendung zu
starten, stürzte das Testgerät ab. Die restlichen Testfälle wurden zunächst auf die Testgeräte
kopiert und danach verändert. Beim Versuch, diese Testfälle mit Hilfe der Stub-Dateien zu installieren, schlugen alle Installationen entweder mit dem Fehler Datei fehlerhaft oder Erforderlicher Programmzugriff nicht gewährt fehl. Bei Anwendung des Symbian-Versionen-Kriteriums
zeigt sich, dass auf dem Testgerät mit Symbian OS Version 9.1 ein anderes Verhalten zu beobachten ist. Dieser Unterschied ist dadurch zu erklären, dass das Format der EXE-Dateien
zwischen den Symbian Versionen verschieden sind. Eine Änderung auf Hex-Ebene kann in der
einen Version zu keinem Fehler führen, wohingegen bei der anderen Version diese Veränderung
zum einem Fehler führt.
83
5.5.8. Shared-Data
Die Shared-Data-Testfälle sind nach der Definition in drei Bereiche unterteilt, sodass die
Ergebnisse jedes Testbereichs einzeln präsentiert werden können.
Publish & Subscribe
Im ersten Testbereich werden die Publish & Subscribe-Ergebnisse aufgezeigt. Zu jedem Testfall werden jeweils zwei Prozesse ausgeführt. Dabei definiert ein Prozess eine Property und
versucht, diese gemäß der WritePolicy mit einem Wert zu beschreiben, während ein anderer
Prozess wiederum versucht, gemäß der definierten ReadPolicy den Wert der Property zu lesen. Im ersten Testfall sind beide Policies mit ECapabilityAlwaysPass definiert, sodass der
eine Prozess ohne Fehler auf allen Testgeräten die Property definieren und erstellen kann. Der
Prozess, der auf diese Property zugreift, kann diese auch lesen. Im nächsten Testfall kann der
erstellende Prozess zwar die Property definieren, jedoch nicht auf diese zugreifen, da ihm der
Zugriff verweigert wurde. Auch der lesende Prozess kann auf die Property nicht zugreifen.
Dieses Verhalten ist jedoch dadurch zu erklären, dass die Read- und die WritePolicy absichtlich mit ECapabilityAlwaysFail definiert wurden und sich somit völlig korrekt verhalten.
Werden im dritten Testfall beide Prozesse mit den zugehörigen Capabilities zu den jeweiligen
Read- oder WritePolicies ausgeführt, so kann der Prozess wie schon im ersten Testfall die
Property definieren, sie mit einem Wert initialisieren und der zugreifende Prozess kann auf
die Property lesend zugreifen. Im vierten Testfall wird die Property mit verschiedenen Capabilities in der Read- beziehungsweise WritePolicy definiert. Der eine Prozess kann zwar die
Property definieren, sie jedoch nicht beschreiben, da der Prozess nicht die benötigten Capabilities besitzt, dies zu tun. Der darauf folgende Testfall ist ähnlich konzipiert, nur besitzt
hier der lesende Prozess nicht die nötigen Capabilities auf die Property zuzugreifen. So kann
der erstellende Prozess der Property diese mit einem Wert beschreiben, versucht jedoch der
andere Prozess auf diese Property zuzugreifen, wird aufgrund der mangelnden Capability der
Zugang verweigert. Der letzte Testfall greift noch einmal die ECapabilityAlwaysFail Policy auf. Definiert der erstellende Prozess die Read- und WritePolicy der Property nun mit
ECapabilityAlwaysFail, so kann der Prozess trotz zweier User Capabilities, nicht die Property beschreiben. Das Ausführen dieser Testfälle im Emulator führt zu den gleichen Ergebnissen,
die auch schon oben beschrieben wurden.
File Handle
Der nächste Testbereich untersucht den Zugriff auf ein File Handle, das ein Prozess erstellt und
ein anderer Prozess über das File Handle auf die dahinter liegende Datei zugreift. Im ersten
Testfall in diesem Bereich kann der zugreifende Prozess auf das File Handle greifen, denn
beide Prozesse wurden ohne Capabilities definiert. Im nächsten Testfall kann der zugreifende
Prozess auch wieder auf das File Handle zugreifen und die dahinter liegende Datei verändern.
Beim dritten Testfall wurde der erstellende Prozess ohne Capabilities definiert, wo hingegen
der zugreifende Prozess auf das File Handle zwei User Capabilities besitzt. Bei der Ausführung
dieses Testfalls kann der zugreifende Prozess auf das File Handle zugreifen. Im abschließenden
Testfall ist die Verteilung der Capabilities umgekehrt, sodass der Prozess, der das File Handle
erstellt, mit zwei User Capabilities ausgeführt wird und der zugreifende Prozess ohne eine
84
Capability ausgeführt wird. Aber auch in diesem Fall kann der zugreifende Prozess auf das
File Handle zugreifen. Werden diese Testfälle im Emulator ausgeführt, so unterscheidet sich
das Verhalten gegenüber den Testgeräten nicht und die Ergebnisse sind identisch.
Data Chunk
Der abschließende Testfall im Shared-Data-Testbereich präsentiert die Ergebnisse der DataChunk-Testfälle. Die Tests sind ähnlich aufgebaut wie die File-Handle-Tests, sodass zunächst
beide Prozesse ohne eine Capability untersucht werden. In diesem Testfall kann der Prozess
auf den erstellten Data Chunk des anderen Prozesses zugreifen und ihn auch beschreiben.
Werden beide Prozesse mit den identischen Capabilities ausgeführt, so kann der einfache Prozess auf den Data Chunk zugreifen. Wird aber der erstellende Prozess mit keinen Capabilities
ausgeführt und der zugreifende Prozess hingegen mit zwei User Capabilities, so kann der einfache auf den Data Chunk zugreifen. Im letzten Testfall in diesem Bereich ist der zugreifende
Prozess mit keinen Capabilities ausgestattet und der erstellende Prozess besitzt zwei User Capabilities. Auch in diesem Fall kann der einfache Prozess auf den Data Chunk zugreifen und
ihn verändern. Im Emulator kann bei allen vier Testfällen das identische Verhalten zwischen
den beiden Prozessen beobachtet werden.
Die hier vorgestellten Ergebnisse der jeweiligen Testfälle unterscheiden sich weder zwischen
den einzelnen Testgeräten und somit auch nicht nach dem Symbian-Versionen-Kriterium, noch
innerhalb der einzelnen Emulatoren in den verschiedenen Versionen. Der Vergleich zwischen
den Testgeräten und den Emulatoren gemäß dem Plattform-Kriterium zeigt ebenfalls keine
Unterschiede zwischen diesen beiden Plattformen.
Der Zugriff auf das jeweilige Objekt ist bei den beiden Methoden File Handle und Data Chunk
in der Grundfunktionalität von den Capabilities unabhängig. Diese beiden Methoden können
aber auch in Verbindung mit Publish & Subscribe benutzt werden, welches die Abhängigkeit
von den definierten Capabilities des Prozesses einführt. In einer weiteren Form kann der
Data Chunk nicht über den Namen des Chunks gefunden werden, sondern über ein anonymes
Handle.
5.5.9. IDs
Der IDs-Testbereich soll das „Zusammenspiel“ zwischen den verschiedenen UIDs anhand eines
möglichst breiten UID-Bereichs und von verschiedenen Zertifikaten zeigen. Bei diesen Tests
wurden die UID3, SID, pUID und die VID benutzt.
Zunächst wurden IDs aus dem neuen Testbereich, der ab Symbian OS Version 9 eingeführt
wurde, verwendet. Im ersten Testfall wurde die gleiche UID sowohl für die UID3, die SID als
auch für die pUID verwendet. Bei dieser Kombination gab es weder bei der Installation noch
bei der Ausführung der Testfälle Probleme. Im nächsten Testfall unterscheidet sich lediglich
die pUID von den beiden anderen UIDs. Aber auch hier kann die Testanwendung mit allen
Signierungen installiert und ausgeführt werden. Werden in einem weiteren Testfall nun alle
drei UIDs voneinander verschieden gewählt, so kann die Testanwendung mit keinem Zertifikat installiert und damit auch nicht ausgeführt werden. Wird nun in diesem UID-Testbereich
noch zusätzlich eine VID definiert und die anderen drei UIDs jedoch wieder identisch, so
85
kann der Testfall nur noch mit einem Developer- oder einem „root“-Zertifikat installiert und
auch ausgeführt werden. Bei nicht signierten oder nur selbst signierten Testanwendungen wird
die Installation mit dem Fehler Geschütztes Programm eines unbeglaubigten Anbieters nicht
installierbar abgebrochen. Die nächsten Testfälle benutzen UIDs aus den geschütztem UIDBereich, der ebenfalls ab Symbian OS Version 9 bereitgestellt wird. Der erste Test verwendet
in diesem UID-Bereich erneut die identische UID als UID3, SID und pUID. Dabei konnten
wieder nur die Testanwendungen installiert und ausgeführt werden, die mit einem Developeroder einem „root“-Zertifikat signiert wurden. Die beiden restlichen Testanwendungen konnten
erneut mit dem Fehler Geschütztes Programm eines unbeglaubigten Anbieters nicht installierbar nicht installiert werden. Wird im folgenden Testfall die pUID wieder verschieden von der
UID3 und der SID gewählt, so verhalten sich die Testanwendungen wie der gleiche Testfall,
der jedoch UIDs aus dem Testbereich verwendet. Hier können aber, wie schon im obigen
Testfall beschrieben, nur Testfälle installiert werden, die durch ein Developer- oder „root“Zertifikat signiert sind. Der nächste Testfall untersucht weiterhin UIDs aus dem geschützten
Bereich. Dieses Mal werden die UIDs jedoch wie schon oben voneinander verschieden gewählt.
Typisch für den geschützten UID-Bereich hätten nur Testfälle installiert werden können, die
durch ein Developer- beziehungsweise „root“- Zertifikat signiert sind, doch bei der Kombination verschiedener UIDs wird die Installation mit dem Fehler Installation nicht möglich bei der
Hälfte abgebrochen. In den beiden anderen Testfällen wird die Installation bereits zu Beginn
des Installationsprozesses mit dem oben beschriebenen Fehler verweigert. Der abschließende
Testfall benutzt gleiche UIDs, zusätzlich aber eine VID. Wie beim entsprechenden Testfall
innerhalb des UID-Testbereichs können auch hier nur Testanwendungen installiert werden,
deren Zertifikat durch eine Zertifizierungsstelle ausgestellt wurde.
Ein Unterschied zwischen den einzelnen Testgeräten konnte anhand des Symbian-VersionenKriteriums nicht erkannt werden. Lediglich auf einem Nokia E61 konnten die Testfälle mit
Hilfe eines Developer-Zertifikates untersucht und installiert werden.
Bei den Tests im Emulator, konnten alle Testfälle ohne Fehler ausgeführt werden. Dabei gab es
zwischen den einzelnen Symbian Emulator Versionen keine Unterschiede. Die fehlerfreie Ausführung der Testfälle ist dadurch zu erklären, dass beispielsweise eine SID aus dem geschützten
Bereich an ein vertrauenswürdiges Zertifikat geknüpft ist. Nur wenn der SWInstaller das Installationspaket als vertrauenswürdig einstuft, kann die Anwendung mit der SID aus dem
geschützten Bereich installiert werden. Ähnlich verhält es sich mit der VID. Da jedoch dieser
Mechanismus im Emulator fehlt, können die Testanwendungen mit verschiedenen UIDs aus
unterschiedlichen UID-Bereichen ausgeführt werden. Die Emulator-Plattform kann in diesem
Fall nicht bei der Verifikation der UIDs und damit auch nicht für das Verifikationskriterium
herangezogen werden.
Den Emulator und die Testgeräte hier in diesem Testbereich nach dem Plattform-Kriterium
zu vergleichen ist besonders schwierig. Die ganzen Sicherheitsmechanismen können während
der Installation im Emulator nicht greifen, da der SWInstaller im Emulator nicht vorhanden
ist. Jedoch zeigt der Emulator, dass auch verschiedene UIDs wie die UID3, SID und die pUID
in Symbian OS 9 lauffähig wären. Schon in der Spezifikation der PSA ist beschrieben, dass
die SID und UID3 gleich gewählt werden sollen, jedoch nicht müssen. Der SWInstaller wurde
aber darauf konditioniert, einen möglichen Konflikt, der aus dieser Situation heraus entstehen
könnte, zu verhindern. Der Emulator zeigt aber auch, dass ein Konflikt bei verschiedener UID3
und SID nicht gleich auftreten muss. Nur wenn eine Anwendung explizit die UID3 und die
SID für den gleichen Zweck benutzt, kann es zu einem Konflikt kommen.
86
5.5.10. API
Die API-Testfälle sind der Vollständigkeit halber in das Testsystem integriert worden. Dabei
konnten die drei Beispiele zur Definition der Testfälle gemäß der API-Dokumentation korrekt
ausgeführt werden und zeigten keinerlei Abweichungen. Sowohl auf den Testgeräten als auch
im Emulator wurden alle drei Tests, wie in der API-Dokumentation spezifiziert, bestanden.
Demnach ist das Verifikationskriterium der drei API-Testfälle erfüllt. Unterschiede gemäß dem
Symbian-Versionen-Kriterium zwischen den einzelnen Testgeräten gab es keine und auch im
Vergleich zum Emulator unterscheiden sich die Testergebnisse der drei Testfälle nach dem
Plattform-Kriterium nicht untereinander.
Nachdem in den zurückliegenden Abschnitten die Ergebnisse der einzelnen Testbereiche ausführlich beschrieben wurden, sollen hier noch einmal die zentralen Aussagen und die damit
verbundenen Konsequenzen der jeweiligen Testbereiche erläutert werden.
5.6.1. Data Caging
Jeder Prozess kann grundsätzlich auf alle geschützten Verzeichnisse nur dann schreibend oder
lesend zugreifen, wenn er die dafür benötigten Capabilities besitzt. Ohne die entsprechende
Capability kann ein Prozess nicht auf das geschützte Verzeichnis zugreifen. Diese Tests haben
gezeigt, dass die Data-Caging-Zugangsregeln aus Abschnitt 2.2.4, Tabelle 2.5 eingehalten werden und korrekt mit den jeweiligen Capabilities funktionieren. Das Regeln-Kriterium für das
Data Caging wird somit erfüllt. Die Trennung zwischen lesendem und schreibendem Zugriff
innerhalb der geschützten Verzeichnisse konnte ohne Probleme nachvollzogen werden. Die Ergebnisse der Testfälle haben aber auch schon hier die Eigenschaften der Capabilities gezeigt.
Das heißt, ein Prozess konnte mit der ihm zugewiesenen Capability nur auf die Verzeichnisse
zugreifen, die es die Capability erlaubt. Selbst ein Prozess, der mit der Tcb Capability ausgestattet wurde, kann nicht auf Verzeichnisse zugreifen, die eine AllFiles Capability verlangen.
Anhand der Ergebnisse im Emulator, kann die Eigenschaft, dass das Data Caging nur von den
Verzeichnissen abhängt und nicht vom Laufwerk, verifiziert werden. Aufgrund dieser Eigenschaft ist das Data Caging sehr flexibel und kann auch auf weiteren Laufwerken, ohne neue
Einstellungen vorzunehmen, verwendet werden.
Die Tests in diesem Bereich haben gezeigt, dass vollständige Installationspakete nicht durch
andere Installationspakete in eine Eclipsing-Situation gebracht werden können. Selbst ein
vertrauenswürdiges Installationspaket kann ein nicht vertrauenswürdiges Installationspaket
in keine Eclipsing-Situation bringen. Eine weitere zentrale Aussage, die mit Hilfe der Testfälle
getroffen werden kann, ist, dass bereits installierte Dateien unabhängig von ihrem Format nicht
durch andere Dateien während der Installation in eine Eclipsing-Situation gebracht werden
können. Dabei spielt es keine Rolle, ob es sich um eine Text-, EXE- oder DLL-Datei handelt.
Jeder Versuch, eine dieser Dateien in eine Eclipsing-Situation zu bringen, endete mit einem
87
Aktualisierungsfehler. Mit dieser Aussage kann die Eclipsing-Regel in Abschnitt 2.4.2 nicht
verifiziert werden. In den Testfällen konnte ich nicht feststellen, dass ein vertrauenswürdiges
Installationspaket eine Eclipsing-Situation mit einer Datei eines nicht vertrauenswürdigen
Installationspaketes erfolgreich herstellen konnte. In diesem Fall ließ der SWInstaller nicht zu,
wählen zu können, ob die vorhandene Datei des nicht vertrauenswürdigen Installationspaketes
gelöscht werden soll. Aufgrund dieses Verhaltens kann das Regeln-Kriterium für das Data
Caging nicht völlig erfüllt werden. Jedoch konnten die Testfälle zeigen, dass zur Laufzeit
Text-Dateien in eine Eclipsing-Situation gebracht werden können.
Die Ergebnisse der File-Overwriting-Testfälle konnten zunächst zeigen, dass das Überschreiben einer bereits installierten Anwendung nur über ein SA-Update bewerkstelligt werden kann,
wenn für das Update alle Voraussetzungen erfüllt sind. Dabei konnte auch festgestellt werden, dass ein vertrauenswürdiges Installationspaket nicht durch ein nicht vertrauenswürdiges
Installationspaket überschrieben werden kann. Eine weitere wichtige Aussage in diesem Testbereich ist, dass einzelne Dateien, ob Text-, EXE- oder DLL-Dateien, während der Installation
nicht durch andere Dateien überschrieben werden können. Nicht mal „root“ signierten Installationspaketen ist es möglich, andere Dateien zu überschreiben. Anhand der Update-Testfälle
konnte das spezifizierte Verhalten gezeigt und gemäß dem Verifikationskriterium verifiziert
werden. Diese Testfälle haben erneut gezeigt, dass ein vertrauenswürdiges Installationspaket nicht durch ein nicht vertrauenswürdiges Installationspaket aktualisiert werden kann. Die
File-Overwriting-Testfälle haben somit auch das Regeln-Kriterium erfüllt. Eine abschließende
Aussage, die aus den Testergebnissen gezogen werden kann, besagt, dass Text-Dateien zur
Laufzeit überschrieben werden können.
5.6.4. SWInstaller
Die Ergebnisse der SWInstaller-Testfälle haben gezeigt, dass Anwendungen, die nicht signiert
oder selbst signiert sind, nur diejenigen User Capabilities benutzen können, die in der SWIPolicy definiert sind. Die weiteren Tests konnten aber zusätzlich noch zeigen, dass bei der
Definition der UserCapabilities in der SWIPolicy die Capabilities nicht nur auf User Capabilities beschränkt sind, sondern dort alle Capabilities definiert werden können. Als Konsequenz dessen kommt der richtigen Konfiguration der SWIPolicy eine wichtige Bedeutung
zu. Mit Hilfe dieser Ergebnisse konnte auch die Frage nach der Priorisierung der SWIPolicy
gemäß dem SWInstaller-Einstellungen-Kriterium beantwortet werden, wonach die SWIPolicy
als erste Instanz gesehen werden kann und erst wenn eine Entscheidung unter Zuhilfenahme
der SWIPolicy gefunden werden konnte, kann im nächsten Schritt eine Entscheidung gemäß
den SWInstaller-Einstellungen getroffen werden. In den weiteren Testfällen konnte beobachtet werden, dass EXE-Dateien in jedes geschützte Verzeichnis mit Ausnahme des \private
Verzeichnisses kopiert werden konnten. Das ist damit zu erklären, dass EXE-Dateien nur in
\sys\bin ausgeführt werden können und somit in anderen Verzeichnissen keine große Sicherheitsrelevanz besitzen. Die oben angesprochene Ausnahme bezieht sich aber auch auf TextDateien, sodass weder EXE- noch Text-Dateien in das \private Verzeichnis kopiert werden
können. Die Ergebnisse der SWInstaller-Tests haben aber auch gezeigt, dass Text-Dateien
bei der Installation nicht in das \sys\bin Verzeichnis kopiert werden können. Bei diesem
88
Ergebnis konnte mit dem Symbian-Versionen-Kriterium ein Unterschied zwischen den Symbian Versionen 9.1 und 9.2 festgestellt werden, der sich beim Abbruch der Installation durch
Anzeige eines anderen Fehlers äußert. Auf Grundlage der Ergebnisse, in denen der MIME-Typ
untersucht wurde, kann die Aussage getroffen werden, dass eine EXE-Datei nur dann durch
ein nicht signiertes Installationspaket während der Installation ausgeführt werden kann, wenn
die SWIPolicy dieses Verhalten zulässt. Ansonsten können nur durch vertrauenswürdige Installationspakete EXE-Dateien während der Installation ausgeführt werden.
Insgesamt konnten die Testfälle das Verifikationskriterium erfüllen und die korrekte Funktionsweise des SWInstallers zeigen. Dabei konnte auch in den einzelnen Testfällen die Mächtigkeit
des SWInstallers getestet und nach dem SWInstaller-Kriterium das spezifizierte Verhalten des
SWInstallers entsprechend der SWIPolicy gezeigt werden, sodass auch gemäß dem SWIPolicyKriterium mit den drei SWIPolicies nur das definierte Verhalten in der SWIPolicy beobachtet
werden konnte, unabhängig von der Symbian Version und dem Gerätemodell.
5.6.5. Certificate
Anhand der Ergebnisse der Certificate-Testfälle konnten die einzelnen Zertifikate und deren
Mächtigkeit, Capabilities zu gewähren, verifiziert werden. Dabei konnte nach dem Verifikationskriterium jedem Zertifikat das spezifizierte Verhalten, Capabilities zu gewähren, nachgewiesen werden. Eine weitere Aussage der Testfälle konnte mit verschiedenen SWIPolicies
dargestellt werden. Dabei wurde die Abhängigkeit der Zertifikate von den Einstellungen in
der SWIPolicy deutlich. Selbst ein „root“-Zertifikat kann mit den richtigen Einstellungen in
der SWIPolicy als nicht vertrauenswürdig vom SWInstaller eingestuft werden. Eine überraschende Aussage konnte über die OCSP-Prüfung getroffen werden. Trotz der aktivierten
Option für das OCSP in der SWIPolicy ist es dem Benutzer immer noch möglich, die Prüfung
in den Einstellungen des SWInstaller zu deaktivieren und der OCSP-Prüfung zu entgehen.
Dennoch scheint aber die OCSP-Prüfung noch nicht zu funktionieren, denn es ist weder ist
eine Standard-Adresse im SWInstaller hinterlegt noch besitzen die getesteten Zertifikate eine
alternative OCSP-Adresse.
5.6.6. Capabilities
Die Ergebnisse der Capability-Testfälle konnten die korrekte Funktionsweise der CapabilityRegeln anhand einfacher und etwas komplexerer Testfälle, in denen bis zu drei DLL ineinander „gelinkt“ wurden, verifiziert werden. Dadurch konnte auch das Regeln-Kriterium in
den Capability-Testfällen erfüllt werden. Durch die Ergebnisse der einzelnen Capability-Tests
konnte die korrekte Funktionsweise der Capabilities gemäß dem Verifikationskriterium gezeigt
werden. Nur durch die definierte Capability kann in den meisten Fällen auf die Funktion, die
die Capability gewährt, zugegriffen werden. Hier sollte aber die Dokumentation der Funktionen, die durch Capabilities geschützt werden, gründlich überarbeitet werden, denn nicht
immer kann mit der angegebenen Capability auch die beschriebene Funktion genutzt werden.
Mit den Ergebnissen der Client/Server-Testfälle konnte die Funktionsweise der Client/ServerArchitektur verifiziert und damit auch das Verifikationskriterium erfüllt werden. Wird ein
Server in der Standard-Konfiguration implementiert und ist dieser selbst mit der Tcb Capability ausgestattet, so kann immer noch ein Client auf den Server zugreifen, auch wenn der
89
Client keine Capabilities besitzt. Bei der Implementierung eines Servers sollte deshalb die
sichere Variante gewählt werden, in der der Server eine Policy definiert, die den Zugriff nur
für bestimmte Clients mit den entsprechenden Capabilities gewährt.
5.6.7. Integrity
Die ersten Testfälle zeigen, dass die Integrität der Installationsdateien nicht 100-prozentig gegeben ist. Das untermauert besonders der Testfall, dessen Installationsdatei durch Null-Bytes
vergrößert und installiert werden konnte. Mit etwas mehr Aufwand und Verständnis für das
SIS-Installationspaket könnte die Installationsdatei erfolgreich verändert und ohne Fehler installiert werden. In weiteren Testfällen konnte gezeigt werden, dass bei der Installation auf
Laufwerk C der SWInstaller wie bei der Installation auf einer Speicherkarte einen Hash der installierten EXE-Datei erstellt. Jedoch werden diese Hash-Werte auf Laufwerk C nicht benutzt.
Wurden die Testanwendungen korrekt auf der Speicherkarte installiert, unabhängig davon ob
es sich bei der Installation um einen SA- oder PA-Installationstyp gehandelt hat, konnten die
modifizierten Testanwendungen nur dann ausgeführt werden, wenn die Hash-Werte der EXEDateien angepasst wurden. Die weiteren Ergebnisse zeigen, dass die Integrität noch nicht
installierter PA-Testanwendungen durch die „Stub“-Datei gegeben ist. Diese Testergebnisse
machen deutlich, dass die Integrität der EXE-Dateien auf einer Speicherkarte ausreichend
durch den Hash-Wert geschützt ist, jedoch nur, wenn kein Zugang zu den geschützten Verzeichnissen besteht. Anhand dieses Ergebnisses ist Integrität der EXE-Dateien gemäß dem
Verifikationskriterium gegeben. Durch die Ergebnisse der Ressource-Dateien konnte festgestellt werden, dass die Ressource-Dateien auf Laufwerk E nicht durch weitere Mechanismen
geschützt sind. Dadurch kann die Speicherkarte aus dem Mobiltelefon entnommen und die
Ressource-Dateien verändert werden. Die Ergebnisse im Emulator können nicht direkt mit
den Ergebnissen, die mit den Testgeräten erzielt wurden, verglichen werden. Das Dateiformat
der EXE-Dateien im Emulator unterscheidet sich zu sehr von den Testgeräten. Da es sich
dabei auch um unterschiedliche Plattformen handelt, kann die Integrität der EXE-Dateien
nicht miteinander verglichen werden.
5.6.8. Shared-Data
Die Ergebnisse der Shared-Data-Testfälle zeigten beim Publish & Subscribe, dass ein Prozess
nur dann auf eine definierte Property zugreifen kann, wenn die definierten Capabilities in
der Read- oder WritePolicy mit den Capabilities, die der Prozess besitzt, übereinstimmen.
Nur in diesem Fall kann der Prozess die Property beschreiben oder ihren Wert lesen. In allen anderen Fällen wird der Zugriff auf die Property verweigert. Die Ergebnisse der Publish
& Subscribe-Testfälle verdeutlichen, dass das Verifikationskriterium erfüllt wurde. Publish &
Subscribe kann als Grundbaustein für weitere Techniken, die solche Sicherheitsmechanismen
nicht bereitstellen, verwendet werden, beispielsweise für File Handles oder Data Chunks, die
in ihrer Grundfunktionalität diese Merkmale nicht besitzen. Durch die Ergebnisse der FileHandle- und Data-Chunk-Testfälle wurde deutlich, dass der Zugriff auf das jeweilige Objekt
auch ohne eine Capability erfolgen kann. Als Konsequenz dessen sollten diese zuletzt genannten Techniken nur über das Publish & Subscribe Konzept genutzt werden.
90
5.7. Fazit der Ergebnisse
5.6.9. IDs
Im IDs-Testbereich konnte zunächst einmal die Verwendung der IDs verifiziert werden. Dabei
konnte beobachtet werden, dass für die Verwendung von IDs aus dem geschützten UID-Bereich
die Installationspakete mindestens mit einem Developer-Zertifikat signiert sein müssen. Für
IDs aus dem UID-Testbereich gilt diese Beschränkung nicht. Es konnte ebenfalls verifiziert
werden, dass bei der Verwendung einer VID das Installationspaket auch mindestens mit einem
Developer-Zertifikat signiert sein muss. Gemäß dem Verifikationskriterium konnte die Spezifikation der UIDs und der damit benötigten Zertifikate verifiziert werden. Eine abschließende
Aussage kann über die Verwendung von völlig unterschiedlichen IDs innerhalb der Installationspakete getroffen werden. In der Spezifikation der PSA ist es nur eine Empfehlung, die
gleiche UID sowohl für die UID3 als auch für die SID zu verwenden. Der SWInstaller hingegen sieht es aber als Notwendigkeit an, die gleiche UID als UID3 und SID zu verwenden.
Letztendlich sollte es aber als Empfehlung angesehen werden, denn wie der Emulator beweist,
sind auch diese Testfälle lauffähig.
5.6.10. Emulator
Die Ergebnisse der Emulator-Testfälle haben gezeigt, dass mit dem Emulator nicht alle Merkmale der PSA erfasst werden können. Der Emulator kann in dieser Hinsicht nur als zusätzliche
Möglichkeit neben dem Mobiltelefon eingesetzt werden. Zwar kann der Emulator einen großen
Bereich der PSA abdecken, dient aber hauptsächlich als Entwicklungswerkzeug zur Verifikation der Funktionsweise der zu testenden Anwendung. Dadurch kann der Emulator in bestimmten Situationen nicht mit einem echten Mobiltelefon verglichen werden. Beispielsweise zeigen
die Integrity-Testfälle, dass aufgrund des unterschiedlichen Dateiformats der EXE-Dateien die
Testfälle nicht miteinander verglichen werden können. Dennoch kann der Emulator in einigen
Bereichen mit dem Mobiltelefon verglichen werden und somit auch das Plattform-Kriterium
berechtigterweise eingesetzt werden. Die beiden Kriterien Verifikation und Regeln liefern im
Emulator dennoch eine vertrauenswürdige Grundlage für die Ergebnisse, da im Emulator
größtenteils der gleiche Symbian OS Quellcode verwendet wird.
5.7. Fazit der Ergebnisse
Größtenteils konnte die Spezifikation der PSA durch die Testfällen verifiziert werden. Wie
jedoch zu erwarten war, gab es nur sehr wenige Unterschiede zwischen den einzelnen Testgeräten und den Symbian Versionen. Auch die untersuchten Versionen der Emulatoren brachten
untereinander keine unterschiedlichen Ergebnisse hervor.
Während der Installation konnte nicht verifiziert werden, dass Dateien aus vertrauenswürdigen Installationspaketen andere Dateien bereits installierter Anwendungen, die durch ein
nicht vertrauenswürdiges Installationspaket installiert wurden, überschreiben können. Auch
beim File Eclipsing konnte in diesem Fall, keine Eclipsing-Situation verursacht werden. Jedoch
können Text-Dateien zur Laufzeit sowohl überschrieben als auch in eine Eclipsing-Situation
gebracht werden. Daraus kann gefolgert werden, dass mit den entsprechenden Capabilities
auch EXE- und DLL-Dateien zur Laufzeit überschrieben beziehungsweise in eine EclipsingSituation gebracht werden können. Durch die entsprechende Konfiguration der SWIPolicy
91
kann jede unsignierte Anwendung mit den höchsten Capabilities installiert werden. Aber
auch auf die gleiche Art kann die SWIPolicy so konfiguriert werden, dass keine weiteren
Anwendungen, selbst „root“ signierte, installiert werden können. Trotz der Priorisierung der
SWIPolicy gegenüber den SWInstaller-Einstellungen kann der Benutzer die OCSP-Prüfung
ein- beziehungsweise ausschalten. Wahrscheinlich wurde dem Benutzer diese Möglichkeit nur
eingeräumt, weil die OCSP-Prüfung mit der gegenwärtigen Konfiguration der SWInstallerEinstellungen und der Zertifikate nicht funktioniert. Wird der Versuch unternommen Anwendungen mit unterschiedlichen UIDs zu installieren, besonders wenn die UID3 nicht mit der
SID übereinstimmt, so verweigert der SWInstaller die Installation, obwohl die Anwendungen
lauffähig sind. Obwohl die Installationspakete durch Prüfsummen und Signaturen geschützt
sind, konnten sie trotzdem in einigen Fällen modifiziert und anschließend erfolgreich installiert werden. Die Dokumentation der Capabilities für die jeweiligen APIs sind nicht immer
vollständig definiert, sodass teilweise nicht das spezifizierte Verhalten zu erwarten ist.
92
6. Diskussion
In diesem Kapitel wird zu Beginn die Bedeutung von Symbian Signed herausgestellt. Der
nächste Abschnitt diskutiert die Symbian Capabilities, während die beiden abschließenden
Abschnitte die SWIPolicy und den SWInstaller beleuchten.
6.1. Symbian Signed
Dieser Abschnitt beleuchtet die Bedeutung von Symbian Signed und die damit verbundene
Verantwortung. Anschließend werden die Testkriterien von Symbian Signed näher erläutert.
6.1.1. Bedeutung und Verantwortung
Mit der Einführung von Symbian OS Version 9 wurde ein Zertifizierungsprogramm benötigt, das eine formale Verbindung zwischen einer Anwendung und ihrer Herkunft herstellt.
Mit Symbian Signed konnte eine Infrastruktur geschaffen werden, durch die Anwendungen
identifiziert, verifiziert und signiert werden konnten. Mittlerweile können Anwendungen nicht
nur durch Symbian Signed, sondern auch durch andere Zertifizierungsstellen signiert werden. Jedoch stieg für Symbian Signed mit dieser Plattform auch die Verantwortung, diesen
Pflichten nachzugehen. Nach anfänglichen Schwierigkeiten stehen nun Entwicklern und ganzen Software-Entwicklungsunternehmen drei Möglichkeiten zur Verfügung, ihre Anwendung
zu signieren. Beispielsweise hat sich das Open-Signed-Zertifizierungsprogramm in den letzten
beiden Jahren stark verändert. Im letzten Jahr existierte dieses Verfahren noch nicht in der
jetzigen Form. Jeder registrierte Benutzer von Symbian Signed konnte ein Developer-Zertifikat
zu Entwicklungszwecken anfordern. In dieser Zeit konnte für jede IMEI eines Mobiltelefons
ein eigenes Developer-Zertifikat kostenfrei erworben werden. Aktuell wurden die DeveloperZertifikate in das Open-Signed-Zertifizierungsprogramm integriert. Das bedeutet, eine Anwendung kann nun nicht mehr zu Testzwecken wie es heißt „Offline“ ohne eine Publisher-ID
durch ein Developer-Zertifikat signiert werden. Nun muss immer der Weg über die Symbian
Signed Webseite genommen werden, damit eine Anwendung mit einem Developer-Zertifikat
signiert werden kann. Mit diesem Zustand hat sich aber auch nicht die Tatsache geändert,
dass durch ein solches Developer-Zertifikat nur die Developer Capabilities gewährt werden
können. Hier verfolgt Symbian Signed anscheinend das Ziel, mehr Entwickler an Symbian Signed durch eine Publisher-ID zu binden und die Entwickler zu authentifizieren. Jedoch macht
es wenig Sinn, einen Teil der gesamten Capabilities durch ein Developer-Zertifikat zu Testund Entwicklungszwecken zu beschränken. Wie soll es einem Entwickler möglich sein, Symbian Signed Capabilities für seine Anwendung auf einem Mobiltelefon testen zu können, wenn
es ein Zertifikat gibt, das genau zu diesem Zweck geschaffen wurde, es aber nicht erlaubt? In
dieser Situation kann der Entwickler nur im Emulator testen oder muss in der Entwicklung
93
6. Diskussion
auf andere Möglichkeiten zurückgreifen, die im folgenden Kapitel 7 beschrieben werden. Oder
Symbian ist der Meinung, dass Entwickler ohne eine Publisher-ID Symbian Signed Capabilities nicht benutzten sollen. Größere Software-Entwicklungsunternehmen haben sicherlich die
Möglichkeit, ihre Anwendungen zu Testzwecken mit einem internen „root“-Zertifikat signieren
zu können. Symbian sollte jedoch jedem Entwickler die Möglichkeit geben, eine Anwendung
zunächst ohne jegliche Behinderung entwickeln zu können. Aufgrund der Beschränkung eines
Developer-Zertifikates auf die IMEI eines Mobiltelefons kann eine Anwendung ohne vorherige Kenntnis der IMEI nicht weiter verbreitet werden. Symbian sieht hier jedoch durch das
Gewähren aller Capabilities für Entwickler ohne eine Publisher-ID die Gefahr, dass die Netzwerkintegrität des Mobilfunkanbieters beeinträchtigt wird. Doch selbst mit dem Zugang zum
Kernel und damit zur Hardware kann ohne das entsprechende SDK nicht ohne weiteres das
Netzwerk oder weitere Mobiltelefone beeinträchtigt werden. Symbian sollte deshalb für Entwickler, die keine Publisher-ID besitzen, auch Verständnis zeigen und ihnen zumindest die
Symbian Signed Capabilities durch ein Developer-Zertifikat gewähren. Die Manufacturer Capabilities könnten dann auch Entwicklern mit einer Publisher-ID verfügbar gemacht werden.
Denn mit einer Publisher-ID hat Symbian durch die Einführung von OCSP die Möglichkeit, das Anwendungszertifikat zu widerrufen und in Ausnahmefällen sogar den Entwickler
von zukünftigen Einreichungen abzuhalten. Diese Möglichkeit muss über OCSP jedoch erst
einmal in der SWIPolicy aktiviert werden und anschließend muss diese Option noch in den
SWInstaller-Einstellungen ebenfalls aktiviert werden. Aufgrund der ganzen Testfälle kann ich
aber sagen, dass das OCSP in seiner jetzigen Version noch nicht so funktioniert wie es soll.
Hier müsste Symbian in den Standard Einstellungen der SWIPolicy und auch in den SWInstaller Einstellungen nachbessern. Zumindest sollte eine Adresse angegeben werden, unter
der der SWInstaller die nötigen Informationen über das jeweilige Zertifikat finden kann. Für
diesen weiteren Schutz dem Anwender gegenüber müssten die zahlreichen Mobilfunkanbieter
die Möglichkeit bieten, diese OCSP-Status-Prüfungen unentgeltlich zur Verfügung zu stellen. Kein Benutzer wird freiwillig weitere Kosten auf sich nehmen, um nur den Status eines
Anwendungszertifikates zu überprüfen. Damit dieser Dienst in seinem vollen Funktionsumfang genutzt werden kann, muss Symbian mit den großen Mobilfunkanbietern zusammenarbeiten, damit keine zusätzlichen Kosten für den Benutzer entstehen. Neben den möglichen
Kosten, die auf die Benutzer zukommen könnten, sollte Symbian Signed gewährleisten, dass
die „Revocation-Datenbanken“ stets aktuell und verfügbar sind.
6.1.2. Testkriterien
Damit Anwendungen in den beiden Zertifizierungsprogrammen Express Signed und Certified
Signed signiert werden können, müssen sie zunächst eine Reihe von Testkriterien bestehen. In
den Grundlagen (Abschnitt 2.2.5) wurden die Testkriterien kurz zusammengefasst und sind
in Abbildung 6.2 etwas ausführlicher dargestellt. Eine Anwendung, die durch das Certified
Signed Zertifizierungsprogramm signiert wurde, kann das „for Symbian OS“-Logo (Abbildung
6.1) tragen. Das Logo soll dem Benutzer signalisieren, dass es sich bei der Anwendung um eine
Abbildung 6.1.: Symbian Logo für Symbian Signed Anwendungen
94
6.1. Symbian Signed
vertrauenswürdige Symbian Signed Anwendung handelt. Es soll ein Qualitätsmerkmal für den
Benutzer darstellen und für den Entwickler gleichzeitig ein lohnenswertes Ziel sein, die Anwendungen durch Certified Signed signieren lassen zu können. Eine Symbian Signed Anwendung
hat nicht nur den Vorteil, dass keine Sicherheitswarnungen bei der Installation auftreten, sondern auch eine gute Reputation, eine getestete und vertrauenswürdige Software zu besitzen.
Benutzer sollten sensibilisiert werden, nicht jede beliebige Software auf ihren Mobiltelefonen
zu installieren. Den Benutzern steht eine Vielzahl an Anwendungen zur Verfügung, die jedoch in den meisten Fällen nicht oder selbst signiert sind. Bei dieser Art von nicht signierter
Software besteht die Gefahr, dass die Benutzer gegenüber Sicherheitswarnungen „abstumpfen“ und ohne groß nachzudenken jegliche Software auf ihren Mobiltelefonen installieren. Das
ermöglicht jedoch Schadsoftware eine unkomplizierte Installation. Benutzern sollte vermittelt
werden, dass sie auf vertrauenswürdige Software von Symbian Signed achten und nicht signierter Software misstrauisch begegnen sollen. Jedoch können sich einige Benutzer auch fragen,
ob die Testkriterien von Symbian Signed auch ein ausreichender Identikator für den Schutz
vor bösartiger Software sind. Einige Unternehmen haben diese Testkriterien auch für ihren ei-
Abbildung 6.2.: Symbian Signed Testkriterien [4]
95
6. Diskussion
genen Entwicklungsprozess übernommen und teilweise weitere Testkriterien hinzugefügt. Die
Testkriterien umfassen Tests, die das Installations- und Deinstallationsverhalten untersuchen,
aber auch die Zuverlässigkeit und den Umgang mit wenig Speicher. Zusätzlich gibt es zu jeder
Capability weitere Testfälle, die der Abbildung 6.2 zu entnehmen sind. Die Anwendung, die
zum Testen eingereicht wird, wird nur zur Laufzeit gemäß den Testkriterien untersucht und
ob die Anwendung sich an die eigene Spezifikation hält. Eine detaillierte Quellcode-Analyse
ist zum einen nicht möglich, da der Quellcode nicht zum Testen eingereicht wird und zum anderen würde kein Entwickler oder ein ganzes Software-Entwicklungsunternehmen seine nicht
„Open Source“-Anwendung den Quellcode freiwillig herausgeben. Eine andere Alternative, um
das Programmverhalten der Anwendung besser zu untersuchen, wäre die Anwendung in einer
kontrollierten Umgebung, wie sie zum Beispiel eine „Sandbox“ zur Verfügung stellt, auszuführen. Auf diese Weise könnten mögliche versteckte Funktionsaufrufe ermittelt werden, die
zur Laufzeit auf einem Mobiltelefon nicht sichtbar wären. Diese Vorgehensweise würde zwar
die Anforderungen an die Tests erhöhen, aber der kritische Benutzer könnte auf diese Weise
besänftigt und die Sicherheitsanforderungen könnten dadurch erhöht werden.
6.2. Capabilities
Symbian stellt insgesamt 20 Capabilities zur Verfügung, die grob in drei Bereiche geteilt
sind. Die einzelnen Capabilities sind in Kapitel 2.2.3 genau beschrieben. Dieser Abschnitt
diskutiert die Verantwortung für das Gewähren dieser Capabilities und die Verteilung der
einzelnen Capabilities.
6.2.1. Verantwortung für das Gewähren von Capabilities
In Symbian OS stehen Anwendungsentwicklern viele Möglichkeiten zur Verfügung, wie sie ihre
Anwendung auf ein Mobiltelefon bringen können. Dabei können Anwendungen kommerziell
vertrieben oder frei zur Verfügung gestellt werden. Anwendungen, die für den Software-Markt
geschrieben werden, sind der Hauptverwendungszweck von Capabilities. Nur durch die Capabilities können die geschützten APIs verwendet werden. Aber neben dem Software-Markt
müssen auch für die Anwendungen, die bereits auf dem Mobiltelefon nach der Auslieferung
installiert sind, die Capabilities gewährt werden. In Symbian OS können Anwendungen in
speziellen Laufzeitumgebungen ausgeführt werden, die jedoch besondere Anforderungen stellen.
Dritthersteller Anwendungen
Die meisten kommerziellen Anwendungen auf dem Software-Markt sind Symbian Signed oder
Express Signed signiert. Wie schon im vorherigen Abschnitt erwähnt, kann es durchaus von
Vorteil sein, wenn eine Anwendung mit einem vertrauenswürdigen Zertifikat signiert ist. Mit
jeder gewährten Capability steigt die Verantwortung der Zertifizierungsstelle. Jede weitere
gewährte Capability bedeutet einen weiteren Zugriff auf geschützte APIs und somit größeres
Risiko hinsichtlich Missbrauch dieser Capabilities. Symbian hat dafür verschiedene Zertifizierungsprogramme mit entsprechenden Testkriterien für jedes einzelne Programm entwickelt,
96
6.2. Capabilities
die auch schon in Abschnitt 6.1 diskutiert wurden. Auf diese Weise besteht zwar kein 100prozentiger Schutz vor Missbrauch der Capabilities, aber wenigstens kann bei den meisten
kommerziellen Anwendung die Herkunft der jeweiligen Anwendungen nachvollzogen werden.
Built-in Code
Im Gegensatz zu Dritthersteller-Anwendungen werden die Capabilities von bereits installierten Anwendungen, die in der Firmware des Mobiltelefons integriert sind, durch die Mobiltelefonhersteller gewährt. Bei diesen Anwendungen ist jedoch entscheidend, welchem Teil der
Trusted Computing Platform die Anwendung zugeteilt werden kann. Interne Testzyklen sorgen aber dafür, dass die Anwendungen in den entsprechenden Teilen der Trusted Computing
Platform genau das tun, wofür sie entwickelt wurden. Der Mobiltelefonhersteller trägt hier
die meiste Verantwortung gegenüber den Benutzern.
Spezielle Laufzeitumgebungen
Spezielle Laufzeitumgebungen wie Java, Visual Basic und Python stellen eine besondere Herausforderung an die PSA dar. Damit diesen Laufzeitumgebungen eine große Menge an Funktionalität zur Verfügung gestellt werden kann, müssen die bereitgestellten Funktion der jeweiligen Laufzeitumgebung auf die geschützten APIs des Betriebssystems zugreifen können.
Der Zugriff auf die jeweiligen APIs kann nur gewährt werden, wenn die Laufzeitumgebung die
entsprechenden Capabilities besitzt. Um jedoch zu verhindern, dass das Sicherheitsmodell der
PSA nicht kompromittiert wird, muss die Laufzeitumgebung ein ergänzendes Sicherheitsmodell zum nativen Betriebssystem bereitstellen. Den Anwendungen in der Laufzeitumgebung
darf es nicht gelingen, das Sicherheitsmodell der PSA zu umgeben. Deshalb darf die Laufzeitumgebung nicht mehr Capabilities besitzen als sie selbst benötigt. Jede Anwendung innerhalb der Laufzeitumgebung kann mit den gleichen Capabilities ausgeführt werden, die die
Laufzeitumgebung selbst besitzt. Die Zertifizierungsstellen haben damit eine große Verantwortung, Laufzeitumgebungen sensible Capabilities zu gewähren. Wird zum Beispiel Python
für Symbian OS [27] betrachtet, so kann festgestellt werden, dass der Laufzeitumgebung alle
Capabilities außer AllFiles, DRM und Tcb gewährt wurden. Wie das Beispiel zeigt, werden
die Manufacturer Capabilities nicht gewährt. Auf diese Weise kann sichergestellt werden, dass
das Dateisystem nicht modifiziert, die Integrität des Mobiltelefons nicht beeinträchtigt und
auf die geschützten Verzeichnisse nicht zugegriffen werden kann.
6.2.2. Verteilung der Capabilities
Symbian überlässt die Verantwortung für das Gewähren von User Capabilities dem Benutzer.
Symbian ist der festen Überzeugung, dass der Benutzer die Verwendung der User Capabilities
versteht und somit auch diese gewähren kann. Vielen Benutzern ist jedoch nicht klar, was mit
diesen Capabilities alles erreicht werden kann. Die Capabilities können zwar die Integrität
des Mobiltelefons nicht beeinträchtigen, aber sie können dafür genutzt werden, dem Benutzer
Kosten zu verursachen, seine persönlichen Benutzerdaten zu verändern und diese beispielsweise per Bluetooth oder SMS zu versenden. Die Benutzer sollten daher Software nur von
vertrauenswürdigen Quellen beziehen.
97
6. Diskussion
Symbian beschreibt die Anzahl der 20 Capabilities als Gleichgewicht zwischen Komplexität
und Kontrolle der Capabilities. Mehr Capabilities hätten zwar eine feinere Kontrolle der einzelnen APIs zur Folge, aber gleichzeitig würde sich die Komplexität des Sicherheitssystems
erhöhen. Trotz der definierten 20 Capabilities werden in Symbian Version 9.1 nur 18 dieser
Capabilities genutzt. Die Location Capability kann beispielsweise nicht alleine benutzt werden, sondern nur im Verbund mit der ReadDeviceData und ReadUserData Capability. In den
beiden anderen Symbian Versionen 9.2 und 9.3 hat diese Capability keine Funktion mehr,
sodass in diesen Versionen nur 17 Capabilities verwendet werden, wie aus aus den Dokumenten „Capabilities nach Funktionen gelistet“ [18, 19, 28] entnommen werden kann. Sind die 20
Capabilities von Symbian nun doch zu fein gewählt oder werden sie einfach nur im öffentlichen
SDK nicht benutzt. Die Definition der benötigten Capabilities ist nur dann richtig gewählt,
wenn auch wirklich alle Capabilities gebraucht werden und den entsprechenden Funktionen
zugeteilt sind. Im öffentlichen SDK kann das nicht behauptet werden.
6.3. SWIPolicy
Die SWIPolicy stellt die Grundlage für den SWInstaller dar und ist damit die entscheidendste
Konfigurationsmöglichkeit der PSA. Anhand der Konfiguration der SWIPolicy kann das Verhalten es SWInstallers beeinflusst werden. Die SWInstaller-Tests haben gezeigt, dass abhängig
der Konfiguration der SWIPolicy jede Anwendung installiert werden kann. Sogar nicht und
selbst signierte Anwendungen konnten ohne Einschränkungen mit Tcb und AllFiles Capabilities, wenn die Sicherheitswarnungen außer Acht gelassen werden, installiert werden. Vielen
Mobilfunkanbietern ist wahrscheinlich die Bedeutung der SWIPolicy nicht vollkommen bewusst. Letztendlich wird die „Firmware“ durch den Mobiltelefonhersteller bereitgestellt, jedoch
können die Mobilfunkanbieter auf die Konfiguration der „Firmware“ entsprechend den eigenen
Bedürfnissen und Vorgaben einwirken. Dadurch entstehen so genannte „Software-Brandings“,
die in den meisten Fällen auf den Mobilfunkanbieter angepasst sind. Im Rahmen der Tests
konnte ich die SWIPolicies der Testgeräte (Tabelle 5.1) und weitere private Geräte miteinander vergleichen. Zusätzlich zu den Testgeräten handelt es sich um ein Nokia N95 8GB sowie
ein weiteres Nokia-Modell, ein 6220 Classic mit Symbian Version 9.3. Vom Samsung SGH-i550
konnte ebenfalls die SWIPolicy verglichen werden. Dabei ist aufgefallen, dass die SWIPolicies
sich voneinander nur wenig unterscheiden. In den Testgeräten ab Symbian Version 9.2 sind
zwei weitere Einstellungen in der SWIPolicy hinzugekommen, die jedoch auf allen Mobiltelefonen, die dieses Merkmal ausweisen, identisch sind. Auf dem Symbian Version 9.3 Mobiltelefon
ist nur aufgefallen, dass eine weitere User Capability in der UserCapabilities-Liste der SWIPolicy hinzugekommen ist, die auf den anderen Testgeräten nicht vorhanden ist. In diesem
Vergleich sind keine Unterschiede zwischen Mobiltelefonen mit einem „Software-Branding“
und freien Mobiltelefonen aufgefallen. Auch beim Samsung-Modell konnte kein Unterschied
gefunden werden. Daher kann aus diesem Vergleich gefolgert werden, dass die Mobilfunkanbieter ihre Möglichkeiten nicht ausschöpfen wollen, die SWIPolicy weiter zu konfigurieren
oder es einfach nicht können. Werden nun die SWIPolicies der Testgeräte mit den beiden Beispielen, die in der Dokumentation der SWIPolicy aufgeführt sind, verglichen, so können nur
drei Unterschiede festgestellt werden. In den Beispielen ist die User Capability Location, die
auch im Nokia 6220 definiert ist, ebenfalls enthalten. Ein weiterer Konfigurationsparameter
RunWaitTimeoutSeconds ist gegenüber den Mobiltelefonen auf einen anderen Wert gesetzt.
Der zusätzliche Konfigurationsparameter ApplicationShutdownTimeoutSeconds ist in der
98
6.3. SWIPolicy
SWIPolicy auf den Testgeräten nicht enthalten, jedoch standardmäßig mit dem gleichen Wert
definiert. Durch die wenigen Unterschiede zwischen der Beispiel-SWIPolicy aus der Dokumentation und den SWIPolicies auf den Testgeräten könnte der Verdacht aufkommen, dass bei
der Konfiguration der Mobiltelefone durch die Hersteller die Beispiel-SWIPolicy zum Einsatz
gekommen ist.
Alle untersuchten SWIPolicies, erlauben keine unsignierten Anwendungen zu installieren.
Auch wenn der Benutzer in den SWInstaller-Einstellungen alle Software-Installationen zulässt,
können dennoch keine unsignierten Anwendungen installiert werden, wenn es die SWIPolicy
nicht zulässt. Warum werden auf der anderen Seite User Capabilities gewährt, wenn damit
die Installationspakete mindestens mit einem selbst erstellten Zertifikat signiert sein müssen,
um mit den User Capabilities installiert werden zu können. Es kann nicht von jedem Benutzer
erwartet werden, nicht signierte Software selbst zu signieren. Jedoch könnten die Entwickler
angehalten werden, ihre Software selbst zu signieren. Für den SWInstaller macht es daher
keinen Unterschied, ob ein Installationspaket selbst oder nicht signiert ist. Der SWInstaller
kann in beiden Fällen keine vertrauenswürdige Basis finden, von der das selbst signierte Installationspaket abgeleitet werden könnte. Dem Benutzer sollte die Wahl gelassen werden, bei
Anwendungen, die nur User Capabilities benutzen, selbst entscheiden zu können, ob er diese
Anwendung installieren will. Letztendlich ist es dieser Gedanke, der hinter den User Capabilities steht, dass Benutzer über Capabilities entscheiden können, die sie auch verstehen. In der
Symbian Version 9.1 und 9.2 wurde den Benutzern beispielsweise eine User Capability vorenthalten. Diese Capability ist zumindest in der SWIPolicy des Symbian Version 9.3 Mobiltelefons
wieder definiert. Wenn die PSA schon User Capabilities definiert, sollten die Benutzer auch alle
User Capabilities benutzen können. Mit dem MandatePolicies Parameter müssen die signierten Anwendungen bei der Installation die definierte Oid in der SWIPolicy besitzen, ansonsten
kann die Anwendung nicht installiert werden. Ist diese Option aktiviert, muss das Zertifikat
mit dem die Anwendung signiert wurde, diese Oid besitzen. In den jeweiligen SWIPolicies sind
zwar Oids definiert, jedoch werden sie nicht benutzt, wenn der MandatePolicies Parameter
nicht gesetzt ist. Die Oids sind in diesem Fall nutzlos und bräuchten nicht definiert werden. Vor
allem wie diese Oids in der SWIPolicy definiert sind, mit Zahlenfolgen wie 1.2.3.4.5.6 oder
2.3.4.5.6.7, lässt darauf schließen, dass die Oids aus dem SWIPolicy-Beispiel übernommen
wurden, ohne die Bedeutung der Oids zu kennen. Ab der Symbian Version 9.2 wurde die SWIPolicy durch den Parameter AlternativeCodeSigningOID erweitert. Jedoch wie schon bei den
Oids, wird auch diese alternative Oid nicht genutzt, da MandateCodeSigningExtension nicht
aktiviert ist. Aus diesem Grund ist dieser Eintrag in der SWIPolicy unnötig.
Die SWIPolicy sollte so konfiguriert werden, dass der Benutzer die Möglichkeit besitzt, bei allen relevanten Entscheidungen einbezogen zu werden. Auf der anderen Seite können jedoch einige Benutzer überfordert sein, ob beispielsweise nicht registrierte Dateien bei der Installation
überschrieben werden dürfen. Dieser Punkt ist jedoch besonders dann von Bedeutung, wenn
vorhandene nicht registrierte Dateien die Installation von neuen Dateien behindern. Daher
sollten sowohl AllowOrphanOverwrite als auch AllowProtectedOrphanOverwrite mit true
konfiguriert werden. Dabei können nur Dateien, die nicht zu einem installierten Paket gehören
oder nicht im „ROM stub controller“ registriert sind, nach Zustimmung des Benutzers während
der Installation überschrieben werden. Ein weiterer Parameter ist DeletePreinstalledFiles
OnUninstall. Dieser Wert ist in allen SWIPolicies auf true gesetzt und bewirkt, dass alle Dateien eines PA-Installationstyps bei der Deinstallation auf einer Speicherkarte gelöscht werden.
Hier besteht die Gefahr, dass falls ein Benutzer seine Speicherkarte einem anderen Benutzer
99
6. Diskussion
überlässt, um beispielsweise Dateien auszutauschen, der andere Benutzer die Dateien der
PA-Anwendung versehentlich löschen kann. Daher sollte dieser Parameter auf false gesetzt
werden.
Werden nun die einzelnen Punkte, die ich im obigen Text angemerkt habe, in einer SWIPolicy
zusammengefasst, ergibt sich die im Listing 6.1 aufgeführte SWIPolicy.
Quelltext 6.1: Konfiguration der SWIPolicy
AllowUnsigned = true
MandatePolicies = false
Mandate C od e Si g n in g Ex t e ns i on = false
DRMEnabled = true
DRMIntent = 3
OcspMandatory = false
OcspEnabled = true
AllowGr a nt Us er C ap ab il i ti es = true
AllowOrphanedOverwrite = true
AllowPr o t e c te d O r p h a n O v e r w r i t e = true
UserCapabilities = NetworkServices LocalServices ReadUserData
WriteUserData UserEnvironment Location
AllowPackagePropagate = true
SISComp a t i b l e I f N o T a r g e t D e v i c e s = false
RunWaitTimeoutSeconds = 600
AllowRu n On In st a ll Un in s ta ll = false
De le te P r e i n s t a l l e d F i l e s O n U n i n s t a l l = false
RemoveO n ly W it h L as t De p e nd e nt = true
PhoneTsyName = phonetsy
Der Mobilfunkanbieter sollte jedoch die Möglichkeit nutzen, die SWIPolicy selbst zu konfigurieren. Bei der Konfiguration sollte aber beachtet werden, dass Benutzer mit wenig Vorwissen
auch zusätzliche Software installieren können, ohne sich dabei Gedanken über mögliche Signierungen oder Zertifikate machen zu müssen.
6.4. SWInstaller
Der SWInstaller ist der einzige Zugangspunkt, der es in Symbian OS Version 9 erlaubt, zusätzliche Software zu installieren. Er ist dafür verantwortlich, dass zunächst die Signierungen
der Anwendungen korrekt verifiziert werden. Anschließend muss der SWInstaller noch die Dateien in die richtigen Verzeichnisse kopieren und diese registrieren. Nur an diesem Punkt wird
entschieden, ob eine Anwendung erfolgreich installiert werden kann oder ob die Installation
der Anwendung verweigert werden muss. Der SWInstaller ist ein Teil der TCB und unterscheidet sich in den verschiedenen Symbian Varianten wie Series 60 und UIQ nicht voneinander.
Selbst wenn das Mobiltelefon mit einem PC verbunden ist und die Installation einer Anwendung vom PC initiiert wird, tritt der SWInstaller in Aktion. Die Entscheidungsgrundlage für
den SWInstaller bildet die SWIPolicy, die auch schon in 6.3 diskutiert wurde. Gemäß diesen
Richtlinien kann der SWInstaller weitere Maßnahmen treffen, wie zum Beispiel das OCSP
initialisieren.
100
6.4. SWInstaller
Benutzer können den SWInstaller in einigen Punkten auch selbst konfigurieren. In Abschnitt
3.2.2 sind diese Punkte aufgeführt. Der Benutzer kann in diesen Einstellungen nur das erlauben beziehungsweise verweigern, was auch in der SWIPolicy erlaubt ist. In der StandardKonfiguration der SWIPolicy kann der Benutzer im Endeffekt nur das OCSP aktivieren. An
dieser Stelle kann erneut die begrenzte Entscheidungsfreiheit des Benutzers diskutiert werden. Symbian sollte es deshalb den Benutzern ermöglichen, selbst zu entscheiden, ob sie nicht
signierte Anwendungen installieren wollen oder nicht. Diese Entscheidung sollte jedoch unabhängig von der SWIPolicy getroffen werden können. Wie schon in Gliederungspunkt 6.3
angesprochen, ist es für den SWInstaller unerheblich, ob eine Anwendung nicht signiert oder
selbst signiert ist. Ausschlaggebend sollten nur die verwendeten Capabilities und weitere in
der SWIPolicy definierte Oids sein.
101
Dieses Kapitel beschreibt zunächst die verschiedenen Möglichkeiten, Privilegien von Symbian OS Anwendungen zu erhöhen. Anschließend wird das Gefahrenpotential, das von diesen
Möglichkeiten ausgeht, beleuchtet und die Maßnahmen gegen diese Möglichkeiten der Mobiltelefonhersteller erläutert. Der abschließende Abschnitt beschreibt die Möglichkeit, die „Mobile
Sandbox“ auf Symbian Version 9 zu übertragen.
7.1. Beschreibung
Während ich an meiner Diplomarbeit gearbeitet habe, sind einige Methoden veröffentlicht
worden, wie Privilegien von Symbian Software erhöht werden können. Dieser Abschnitt beschreibt die Methoden, die benutzt werden können, die PSA zu umgehen und Zugang zu allen
geschützten APIs zu bekommen. Die meisten hier vorgestellten Methoden konnte ich selbst
ausprobieren und teilweise in diese Arbeit einfließen lassen.
7.1.1. SWIPolicy modifizieren
Die erste Methode, die 2007 aufgetaucht ist, beschreibt die Veränderung der SWIPolicy. Da
in dieser Zeit die SWIPolicy auf dem Mobiltelefon nicht verändert werden konnte, musste dies
auf eine andere Weise bewerkstelligt werden. Nokia bietet beispielsweise ein Programm an, mit
dessen Hilfe Mobiltelefone auf die neuste „Firmware“ aktualisiert werden können. Bei diesem
Vorgang muss zunächst das Abbild der „Firmware“ lokal auf einem PC gespeichert werden.
Dabei ist in [29] bekannt geworden, dass die SWIPolicy unverschlüsselt in diesem Abbild zu
finden ist. Wird nun die SWIPolicy in diesem Abbild verändert, kann anschließend das Abbild
der „Firmware“ auf dem Mobiltelefon mit dem „Nokia Software Updater“ installiert werden.
Bei der Veränderung der SWIPolicy darf aber die Größe der SWIPolicy in dem Abbild der
„Firmware“ nicht verändert werden. Ansonsten kann es passieren, dass die Prüfsummen nicht
übereinstimmen und dadurch die Installation der „Firmware“ abgebrochen wird. Bricht jedoch
die Installation der „Firmware“ ab, kann das Mobiltelefon dadurch irreperabel beschädigt
werden.
In einem praktischen Versuch konnte ich diese Variante auch ohne Probleme durchführen.
Dabei konnte ich die SWIPolicy so verändern, dass nicht signierte Anwendungen installiert werden konnten. In einem weiteren Schritt habe ich zusätzlich auf dem Nokia E61 die
UserCapabilities der SWIPolicy durch die AllFiles Capability erweitert. Auf diese Wiese
konnten nicht signierte und mit der AllFiles Capability versehene Anwendungen installiert werden. In [30] wird beispielsweise beschrieben, wie ein Symbian-Dateimanager mit der
AllFiles Capability lesend auf die geschützten Verzeichnisse zugreifen kann.
103
7.1.2. Capabilities zur Laufzeit ausschalten
Fast ein halbes Jahr später schien die oben beschriebene Methode immer noch die einzige zu
sein, die es erlaubte, die Capabilities der SWIPolicy zu verändern. In dieser Zeit ist es jedoch
gelungen, die Capabilities zur Laufzeit auszuschalten [31, 32]. Das Positive an dieser Methode
ist das geringere Risiko im Vergleich zur Veränderung der SWIPolicy. Nach Ausführung dieser
Methode zur Laufzeit kann das Mobiltelefon neu gestartet werden und die ursprüngliche
Konfiguration des Mobiltelefons ist wieder hergestellt.
Im Symbian Emulator können die Capabilities deaktiviert werden, sodass bei einer CapabilityVerletzung nur eine Warnung protokolliert wird. Die Sicherheitseinstellungen im Emulator
werden in der epoc.ini konfiguriert und mittels PlatSecEnforcement OFF können die Capabilities deaktiviert werden. Im Speicher des Mobiltelefons existiert diese Einstellung auch, ist
aber direkt nicht veränderbar. Dennoch ist es aber mit einem „On-Device Debugger“ gelungen, diese Speicherstelle auf einem Mobiltelefon zu finden und auch zu verändern. Der „Metro
TRK Debugger“, der im Symbian S60 SDK mitgeliefert wird, erlaubt durch seine starke Signierung auf den Speicherbereich anderer Prozesse zuzugreifen. Damit jeder Benutzer diese
Modifikation durchführen kann, wurde ein kleines Python-Skript [33] entwickelt, das die Rolle
des „Debuggers“ simuliert und die nötigen Modifikationen im Speicher durchführt. Für diese
Methode ist ein PC nötig, der das Python-Skript ausführt und mit einem Mobiltelefon verbunden ist. Auf dem Mobiltelefon sollte das „Metro TRK“ ausgeführt werden. Diese Methode
konnte auf allen vier Testgeräten erfolgreich durchgeführt werden. Wenige Wochen später,
tauchten zwei neue Anwendungen auf, die die Verbindung zum PC überflüssig machen sollten. Mit „CapsON“ und „CapsOFF“ sollten die Capabilities zur Laufzeit ein- beziehungsweise
ausgeschaltet werden. Zuvor musste aber noch eine Datei, die für die beiden Anwendungen
unerlässlich ist, in das geschützte Verzeichnis \sys\bin kopiert werden. Für die beiden Anwendungen musste aber immer noch im Hintergrund die „Metro TRK“-Anwendung ausgeführt
werden. Die Funktion der beiden Anwendungen kann ich aber nicht bestätigen, da keine dieser
Anwendungen auf den Testgeräten funktioniert hat.
7.1.3. Root-Zertifikat
Einen Monat nach bekannt werden des Capability-Hacks, tauchte ein Symbian „root“-Zertifikat
auf [34]. Damit Symbian Anwendungen mit diesem Zertifikat signiert und installiert werden können, muss für den SWInstaller eine Verifikationsgrundlage geschaffen werden, mit
der der SWInstaller das „root“-Zertifikat als korrekt verifiziert. Dafür muss das Verzeichnis
\swicertstore\dat in C:\resource erstellt werden. Für den schreibenden Zugriff auf das
\resource Verzeichnis müssen die Capabilities nach der zweiten Methode ausgeschaltet, das
Verzeichnis erstellt und die Verifikationsgrundlage in dieses Verzeichnis kopiert werden. Damit dieses Verzeichnis nicht bei jedem Neustart des Mobiltelefons gelöscht wird, muss es als
schreibgeschützt markiert werden. Anschließend können alle Anwendungen mit dem „root“Zertifikat signiert und auf dem Mobiltelefon installiert werden.
104
7.2. Gefahrenpotential
7.1.4. ROM-Patcher
Der ROM-Patcher [35] ist eine Symbian Anwendung, mit der es möglich ist, Dateien im ROM
zu verändern. Dabei kann der ROM-Patcher auf zwei verschiedene Arten installiert werden.
In der ersten Version dieser Anwendung müssen zunächst die Capabilities, wie in Abschnitt
7.1.2 beschrieben, ausgeschaltet werden. Anschließend können die Dateien des ROM-Patchers
auf das Mobiltelefon kopiert werden. Den Installationsvorgang übernimmt dabei eine selbst
geschriebene Windows-Anwendung, die die Dateien des ROM-Patchers an die richtigen Stellen kopiert. Auf diese Weise wird der SWInstaller übergangen. Die nachfolgende Version des
ROM-Patchers konnte hingegen wieder mit dem SWInstaller installiert werden. Da jedoch die
Anwendung alle Symbian Capabilities benötigt, muss sie zunächst mit dem „root“-Zertifikat
signiert werden. Damit der ROM-Patcher nun verwendet werden kann, muss zuerst ein sogenannter „Patch“ erstellt werden. Ein Patch ist in diesem Zusammenhang eine Datei, die
der ROM-Patcher lädt und die darin enthaltenen Anweisungen ausführt. Ein möglicher Patch
könnte beispielsweise die Veränderung der SWIPolicy sein. Dazu wird das „SnR“-Kommando
des ROM-Patchers verwendet, in der securitymanager.dll den Pfad der SWIPolicy durch
einen anderen zu ersetzen. Der ursprüngliche Pfad z:\system\data\swipolicy.ini wird
einfach durch e:\system\data\swipolicy.ini ersetzt, sodass auf der Speicherkarte eine beliebige SWIPolicy hinterlegt werden kann. Im Patch muss nur darauf geachtet werden, dass
die hexadezimale Schreibweise für die Pfadangaben verwendet wird.
7.1.5. HelloCarbide
„HelloCarbide“ [36] ist die aktuellste Methode1 und stellt die Weiterentwicklung der Idee
hinter der „CapsON“- beziehungsweise „CapsOFF“-Anwendung dar. Mit Hilfe dieser Anwendung können ohne das „Metro TRK“ die Capabilities zur Laufzeit ausgeschaltet werden. Der
große Vorteil dieser Anwendung ist, dass sie nur User Capabilities verwendet und dadurch
ohne Schwierigkeiten installiert werden kann. Ein Problem der Anwendung ist aber, dass sich
nach Ausführung der Anwendung keine andere Anwendung mehr starten lässt. Wird aber
zunächst ein Datei-Manager gestartet und anschließend „HelloCarbide“ ausgeführt, kann der
Datei-Manager auf alle geschützten Verzeichnisse lesend und schreibend zugreifen.
7.2. Gefahrenpotential
Bei all diesen vorgestellten Methoden zur Erhöhung der Privilegien von Symbian Software
muss sich die Frage nach dem Gefahrenpotential dieser Methoden gestellt werden. Die Veränderung der SWIPolicy während der Aktualisierung der „Firmware“ stellt dabei das geringste
Gefahrenpotential dar. Da diese Veränderung nur lokal auf einem Mobiltelefon durchgeführt
werden kann und zudem sehr risikobehaftet ist, werden sie nur die wenigsten Benutzer durchführen. Des Weiteren betreffen die Änderungen nur den SWInstaller und können von Benutzer
zu Benutzer unterschiedliche SWIPolicies hervorbringen. Dennoch können mit dieser Methode
Anwendungen mit Manufacturer Capabilities installiert werden.
1
Stand August 2008
105
Die Methode Capabilities zur Laufzeit auszuschalten, bietet ein weitaus größeres Gefahrenpotential, denn auf diese Weise können Anwendungen ohne die entsprechenden Capabilities
installiert werden. Es gibt dadurch keine Kontrollmechanismen, die den Zugriff auf die geschützten APIs überprüfen und somit können Anwendungen auf alle geschützten APIs zu
greifen. Von dieser Methode sind zunächst nur Nokia-Mobiltelefone betroffen, da sich das
„Metro TRK“ aufgrund seiner Signierung nur auf Nokia-Mobiltelefonen installieren lässt.
Von der „root“-Zertifikat-Methode geht nur die Gefahr aus, dass Benutzer Anwendungen mit
allen Capabilities installieren können. Auf diese Weise können Symbian Signed oder die Mobiltelefonhersteller nicht mehr kontrollieren, welche Anwendung zu welchem Zweck Manufacturer
Capabilities benutzt. Somit ist nicht nur die Integrität der Mobiltelefone gefährdet, die das
„root“-Zertifikat benutzen, sondern auch die Netzwerkintegrität der Mobilfunkanbieter kann
durch die unsachgemäße Verwendung der Manufacturer Capabilities beeinträchtigt werden.
Da mit dem ROM-Patcher die SWIPolicy verändert werden kann, können die gleichen Gefahren, wie sie durch das „root“-Zertifikat entstehen können, angenommen werden. Aber auch
durch die Veränderung weiterer ROM-Dateien kann die Integrität des Mobiltelefons beeinträchtigt werden.
Das Gefahrenpotential der „HelloCarbide“-Anwendung kann in der aktuellen Version als gering
bezeichnet werden. Zwar benötigt die Anwendung nur User Capabilities und muss somit auch
nicht Symbian Signed sein, aber nachdem die Capabilities deaktiviert werden, können keine
weiteren Anwendungen mehr gestartet werden. Kann die Anwendung jedoch in nächster Zukunft verbessert werden, so ergeben sich aus den Kombinationen mit weiteren Anwendungen
sehr gefährliche Möglichkeiten.
Bei den Methoden, die nur lokal auf einem Mobiltelefon ausgeführt werden können, besteht
keine direkte Gefahr für andere Mobiltelefone. Zur Verbreitung von Schadsoftware mit Hilfe der beschriebenen Methoden muss entweder das Vorwissen über das andere Mobiltelefon
gegeben sein, beispielsweise welche Capabilities als UserCapabilities in der SWIPolicy definiert sind oder ob die Capabilities ausgeschaltet sind. Doch selbst wenn diese Faktoren in
Erfahrung gebracht werden können, muss der Benutzer immer noch dazu gebracht werden die
Schadsoftware zu installieren. Dadurch stellen die beschriebenen Methoden zur Verbreitung
von Schadsoftware eher eine theoretische Gefahr dar.
7.3. Maßnahmen gegen diese Methoden
Die Veränderung der SWIPolicy kann nur dadurch verhindert werden, dass die SWIPolicy bei
der Aktualisierung der „Firmware“ nicht mehr im Klartext gespeichert wird. Eine Verschlüsselung des „Firmware“-Abbildes wäre vollkommen ausreichend. Beispielsweise praktiziert Nokia
ab den Symbian Version 9.2 Mobiltelefonen bei jedem Aktualisierungsversuch der „Firmware“,
das Abbild jedes Mal neu herunterzuladen. Da die „Firmware“ immer noch nicht verschlüsselt
ist, kann dennoch die SWIPolicy in diesem Abbild verändert werden.
Bei den aktuellen Symbian Version 9.2 Mobiltelefonen versucht Nokia durch neue „Firmwares“ die Installation des „Metro TRK“ zu unterbinden. Die aktuelle „Firmware“ des Nokia E90
bestätigt diese Verhalten [37]. Die neuen Symbian Version 9.3 Mobiltelefone unterbinden die
106
7.4. Sandbox auf Symbian OS Version 9
Installation des „Metro TRK“ schon von Grund auf. Nokia versucht aber auch durch aktualisierte „Connectivity-Treiber“ die Verbindung zwischen „Metro TRK“ und dem Python-Skript
zu verhindern. Mit den aktuellen „Connectivity-Treibern“, die für die Verbindung zwischen
Mobiltelefon und PC zuständig sind, lassen sich beispielsweise die Capabilities nicht mehr
über das Python-Skript ausschalten.
Die Installation des ROM-Patchers oder des „root“-Zertifikates kann nur verhindert werden,
wenn die Capabilities nicht mehr ausgeschaltet werden können. Dadurch könnte nicht mehr
ohne eine gültige Signierung auf die geschützten Verzeichnisse zugegriffen werden. Die Folge
hiervon wäre, dass das „root“-Zertifikat nicht mehr installiert werden könnte und somit könnte
auch der ROM-Patcher ohne eine gültige Signierung nicht mehr installiert werden.
Dieser Anschnitt beschäftigt sich mit der Frage, ob die „MobileSandbox“ [5] auch auf Symbian OS Version 9 realisierbar wäre. Um diese Frage zu klären, wird zunächst das Symbian
Dateiformat vorgestellt und anschließend der Symbian „Loader Server“.
7.4.1. Symbian Dateiformat
Das Symbian „E32 Image“-Dateiformt besteht aus bis zu neun Bereichen, die folgendermaßen
spezifiziert sind:
Image Header Der Bereich enthält alle relevanten Informationen über die ausführbare Datei,
wie zum Beispiel UID1-3, CRC-Prüfsumme, Stack- und Heapgröße.
Code Section -.text Dieser Bereiche beinhaltet den auszuführenden Quellcode.
Constant Data Section -.rdata Beinhaltet konstante schreibgeschützte Daten.
Import Address Table (IAT) Die Tabelle enthält für jede Funktion einen Eintrag, der durch
die ausführbare Datei importiert wird.
Export Directory -.edata Diese Tabelle stellt die Adressen jeder Funktion bereit, die aus
dieser Datei exportiert werden. Jeder Eintrag beinhaltet die Startadresse der Funktion
als Offset relativ zum Start des Code-Bereichs.
Initialized Data Section -.data Dieser Bereich enthält die initialisierten Daten, die in den
RAM kopiert werden, wenn die Datei ausgeführt wird.
Import Data Section -.idata Beinhaltet Daten für jede Funktion, die die ausführbare Datei
importiert. Der „Loader“ benutzt diese Information, um jede referenzierte DLL, die auch
geladen werden muss, zu identifizieren. Zusätzlich benutzt der „Loader“ diese Informationen, um jeden Eintrag in der IAT aufzulösen.
Code Relocation Section Enthält die „Relocation“-Informationen, die auf den Code-Bereich
angewendet werden sollen. Relocation bezeichnet dabei den Prozess, symbolische Referenzen durch aktuelle Speicheradressen zu ersetzen.
107
Data Relocation Section Beinhaltet die Relocation-Informationen, die auf den Daten-Bereich
angewendet werden sollen.
Das oben beschriebe Dateiformat kann nur auf ausführbare Dateien, die nicht im ROM ausgeführt werden, angewendet werden. Das Dateiformat der sogenannten execute-in-place(XIP)
Dateien, also ausführbare Dateien, die direkt im ROM ausgeführt werden, basiert zwar auf
dem „E32 Image“-Dateiformat, unterscheidet sich jedoch in den folgenden Punkten:
• Besitzt einen anderen Image Header.
• Enthält keine IAT.
• Besitzt auch keine Import Data Section (.idata).
• Enthält keine Relocation-Informationen.
• Beinhaltet eine „DLL Reference Table“ nach dem Daten-Bereich. Die Tabelle enthält
jede Bibliothek, die durch die ausführbare Datei referenziert wird, die statische Daten
enthält.
7.4.2. Loader Server
Der „File Server“-Prozess enthält einen zweiten Server, den „Loader Server“. Der Loader Server
hat die Aufgabe, ausführbare Dateien (in diesem Fall EXE- und DLL-Dateien) zu laden. Der
Server wird in einem separaten Thread vom Haupt-File-Server ausgeführt und ist mit Hilfe
der Symbian OS Client/Server-Architektur implementiert. Anders als der „File-Server“ kann
der Loader Server nur eine geringe Anzahl an Diensten zur Verfügung stellen. Im Einzelnen
sind das:
• Einen Prozess starten und die betreffende ausführbare Datei laden.
• Eine DLL laden.
• Informationen über eine bestimmte DLL einholen, das beinhaltet die UIDs der DLL,
die Capabilities und die Modul-Version.
• Einen Gerätetreiber laden.
• Ein „Locale“ laden.
• Ein Dateisystem oder eine „File-Server“-Erweiterung landen.
Vorgang einen Prozess zu laden
Zunächst wird der Vorgang beschrieben, wie der Loader Server einen Prozess im ROM lädt und
anschließend die Unterschiede zum Ladevorgang eines Prozesses nicht im ROM. Dabei muss
als Erstes eine Anfrage an den Loader Server mit RProcess::Create() erstellt werden. Diese
Methode erstellt ein RLoader-Session-Objekt und bei erfolgreichem Verbindungsaufbau wird
die Kontrolle wieder an den Client-Thread zurückgegeben. Die Abbildung 7.1 verdeutlicht den
ersten Schritt. Anschließend ruf der Client die Methode RLoader::LoadProcess() auf, die die
Argumente der Create-Methode an den Server schickt. Als Nächstes allokiert der Server ein
108
Abbildung 7.1.: Anfrage an den Loader Server [2]
E32Image-Objekt für den Hauptprozess der ausführbaren Datei und ruft die LoadProcess()Methode an diesem Objekt auf. Im nächsten Schritt muss die ausführbare Datei lokalisiert
werden. Dazu erstellt der Loader ein RImageFinder-Objekt und ruf die Search-Methode mit
den spezifizierten Argumenten auf. Bei erfolgreicher Suche wird das E32Image-Objekt mit
den gefundenen Informationen durch die Funktion E32Image::Construct() erstellt. Im dritten Schritt wird überprüft, ob ein entsprechendes DCodeSeg-Objekt für die ausführbare Datei
schon existiert. Dazu benutzt der Loader die E32Loader::CodeSeqNext()-Funktion, die den
Kernel auffordert, seine gesamte „Code Segments“-Liste zu durchsuchen. Anschließend kann
der Loader die E32Loader::ProcessCreate-Funktion aufrufen, die den Kernel auffordert, die
Prozessstruktur, den Haupt-Thread und einen globalen Daten-Chunk zu erstellen. Das Ergebnis ist ein DProcess-Objekt, das für den Prozess erstellt wurde. Im nächsten Schritt muss der
Loader jede DLL laden, von der die ausführbare Datei abhängt und statische Daten enthält.
Dafür holt sich der Loader die Adresse der „DLL Reference Table“ aus dem ROM Image Header. Jeder Eintrag in der Tabelle enthält einen Zeiger auf den betreffenden Image Header der
DLL, sodass der Loader für jeden Eintrag ein weiteres E32Image-Objekt generiert. Zusätzlich
muss der Loader für jeden Eintrag ein DCodeSeg-Objekt erhalten. Im letzten Schritt ruft der
Loader die E32Loader::RrocessLoaded()-Kernelfunktion auf, damit der Zustand des neuen
Prozess-Threads aktualisiert wird. Diese Funktion generiert auch ein „Handle“ für den neuen Prozess, das der Loader zurück zum Client schreibt. Anschließend löscht der Loader alle
„Image“-Objekte, die er für die ausführbare Datei erstellt hat und schließt sein eigenes „Handle“
auf den neuen Prozess. Schließlich wird die originale „Load Process“-Nachricht abgeschlossen
und die Kontrolle geht an den Client-Thread zurück. Das schließt auch das RLoader-SessionObjekt und die RProcess::Create()-Methode terminiert. Abbildung 7.2 veranschaulicht den
letzten Schritt grafisch. Nachdem der Loader seinen Dienst erledigt hat, muss der Client nur
noch den neuen Prozess fortsetzen, um ihn zu starten. Der Kernel ruft dann den Einsprungspunkt des Prozesses auf, der den Heap für den Haupt-Thread erstellt. Als Nächstes kopiert
er den initialisierten Data-Bereich an ihre Ausführungsadresse und bereinigt den nicht initialisierten Datenbereich. Ruf die Konstruktoren der EXE-Datei und der verlinkten DLLs auf.
Schließlich ruft der Kernel den öffentlichen Einsprungspunkt, die E32Main()-Funktion, auf.
Der Vorgang einen Prozess zu laden, der nicht im ROM ausgeführt wird, ist etwas komplexer
als einen XIP-Prozess direkt im ROM zu laden, sodass hier nur die Unterschiede beschrieben
werden. Der nächste Unterschied tritt auf, wenn der Loader die E32Loader::ProcessCreate()-
109
Abbildung 7.2.: Vervollständigung der Anfrage [2]
Methode aufruft und der Kernel ein DCodeSeg-Objekt für die ausführbare Datei erstellt. Dabei
muss der Kernel ein „RAM Code Segment“ allokieren, das DCodeSeg-Objekt mit diesem Segment assoziieren und die Ladeadresse des Quellcodes innerhalb des Segments zurückgeben.
Anschließend muss der gesamte Quellcode aus der „Image“-Datei in das „Code Segment“ in
die Ladeadresse des Quellcodes geladen werden. Wenn die ausführbare Datei komprimiert ist,
muss der Loader die Code Section beim Laden dekomprimieren. Nachdem der Loader den
Rest der „Image“-Datei in einen temporären „Image“-Puffer geschrieben hat, muss der Loader
die „Header“-Informationen prüfen, ob die Datei eine Code Relocation Section enthält. Wenn
das der Fall ist, muss der Loader diese Informationen aus dem „Image“-Puffer auslesen und
eine Funktion im „Supervisor Mode“ aufrufen, die jede Relocation auf der gerade geladenen
Code Section durchführt. Enthält die ausführbare Datei ein Export Directory, muss der Loader jeden Eintrag der Ausführungsadresse auflösen und ihn in den Code Segment auf der
Kernelseite schreiben. Enthält die ausführbare Datei eine Initialized Data Section, muss der
Loader diese Daten aus dem „Image“-Puffer in das Code Segment kopieren. Enthält die ausführbare Datei auch noch eine Data Relocation Section, muss der Loader diese Relocations
nach dem gleichen Schema ersetzen wie die Code Relocations. Als Nächstes muss der Loader
alle referenzierten DLL der ausführbaren Datei laden. Jedoch anders als bei den XIP-Dateien
sind die Abhängigkeitsinformationen in der Import Section enthalten und nicht in der „DLL
Reference Table“. Weiter sind nur die Namen der DLL spezifiziert, statt Zeiger zu den Image
Headern wie es bei den XIP-Dateien der Fall ist. Der Loader liest jeden „Import Block“ aus
dem „Image“-Puffer und bearbeitet ihn. Wenn alle „Import Blocks“ bearbeitet wurden, muss
der Loader die IAT für die Hauptdatei und jede Abhängigkeit, die der Loader gerade geladen
hat, auflösen. Nachdem alle Abhängigkeiten bearbeitet wurden, wird der Ladevorgang auf die
gleiche Weise fortgeführt wie bei den XIP-Dateien.
7.4.3. Übertragbarkeit der MobileSandbox
Die Aufgabe der MobileSandbox für Windows Mobile ist die dynamische Analyse von Malware
zur Laufzeit [5]. Dabei wird die zu untersuchende Anwendung in einer Umgebung („Sandbox“)
ausgeführt, die es ermöglicht, jeden einzelnen Schritt der Anwendung zu beobachten. Das
110
Ergebnis der Analyse ist eine Sequenz von API-Aufrufen, die das Programm während seiner
Ausführung benutzt hat.
Eine von der MobileSandbox benutzte Methode ist das „Import Address Table Patching“.
Dabei wird die Adresse jedes Eintrags in der IAT verändert, denn der Windows Loader
muss die Adresse jedes Systemaufrufs nachschauen und diese in die IAT einfügen. Soll nun
Abbildung 7.3.: MobileSandbox IAT Patching [5]
das „IAT-Patching“ auf Symbian Version 9 übertragen werden, muss zunächst die Symbian
Client/Server-Architektur mit einbezogen werden. Dabei kann ein Client nur auf die vom Symbian Loader Server zur Verfügung gestellte Funktion zugreifen. Dadurch wird gewährleistet,
dass der Client nicht auf die privaten Klassen des Loader Servers, die den Kernel anweisen, die
entsprechenden Methoden auszuführen, zugreifen kann. Somit kann in der öffentlichen Version des Symbian SDKs nicht auf die entsprechenden Methoden zugegriffen werden. Jedoch
wurde mit Symbian OS Version 8 eine „File Hook API“ vorgestellt, die es „Plug-ins“ erlaubt,
Dateisystem-Anfragen abzufangen, um beispielsweise Dateien nach Viren zu durchsuchen. Die
API wurde mit Symbian Version 9 deutlich verbessert. Der Zugang zu diesen APIs wird aber
nur durch ein Symbian OS Development Kit (DevKit) oder Symbian OS Binary Access Kit
(BAK) gewährt. In [14] wird auch noch auf zwei weitere Dokumente „Generic fileserver hooks“
und „Virus Scanning Hooks Design for EKA1“ verwiesen. Deshalb sollte es mit Hilfe dieser
API möglich sein, das „IAT-Patching“ auch auf Symbian Version 9 Mobiltelefonen zu implementieren. Dabei muss aber auch noch beachtet werden, dass Dateisystem „Plug-ins“ die Tcb
Capability benötigen und somit die Zustimmung der Mobiltelefonhersteller vorhanden sein
muss.
111
Dieses abschließende Kapitel stellt das Fazit und den Ausblick dieser Diplomarbeit dar. Zusätzlich wird die Frage nach der Offenheit von Symbian OS Version 9 kurz beleuchtet und
anschließend mögliche Themen vorgestellt, die aufbauend auf dieser Arbeit weiter bearbeitet
werden könnten.
8.1. Offenheit von Symbian OS
Die Diskussion, ob ein mobiles Betriebssystem nun für Software von Drittanbietern geöffnet
oder, um die Sicherheit des Mobiltelefons zu erhöhen, stattdessen vor Fremdsoftware geschlossen werden soll, hat in der Vergangenheit gezeigt, dass die zweite genannte Möglichkeit auch
nicht immer das Problem löst. Beispielsweise sei hier das „Orange SPV“-Mobiltelefon genannt,
dessen Windows Betriebssystem zu Beginn geschlossen war. Doch Beschwerden zahlreicher
Entwickler führten dann zur einer Möglichkeit [38], die seitens „Orange“ für Entwicklungszwecke zur Verfügung gestellt wurde, das „Orange SPV“-Mobiltelefon zu entsperren. Das „iPhone“ ist das nächste Beispiel, das zu Beginn für Fremdsoftware geschlossen war. Dennoch ist
es auf diesen Geräten gelungen, Fremdsoftware zu installieren [39, 40]. In diesem Fall wurde
nachträglich ein SDK von Apple zur Verfügung gestellt [41], das es Entwicklern ermöglicht,
Anwendungen für das „iPhone“ zu erstellen. Wie die Beispiele zeigen, wurde in beiden Fällen
das entsprechende Betriebssystem geöffnet. Daran kann aber auch gesehen werden, dass ein
geschlossenes Betriebssystem nicht immer vor der Installation von Fremdsoftware gewahrt ist.
Somit ist nicht immer garantiert, dass durch die Verhinderung der Installation von Fremdsoftware die Sicherheit eines Mobiltelefons gegeben ist.
Symbian betitelt ihr Betriebssystem als „offenes Betriebssystem“, für das jeder Entwickler
Software schreiben kann. Während dieser Arbeit konnte ich aber feststellen, dass das nur auf
einige Bereiche zutrifft. Abhängig vom SDK ist der Zugriff nur auf die jeweiligen Bereiche
gegeben, die durch das entsprechende SDK zur Verfügung gestellt werden. Symbian hat hier
meiner Meinung nach die Balance zwischen einem völlig offenen Betriebssystem und einem
in sich abgeschlossenen Betriebssystem geschafft. Auf der einen Seite kann Symbian OS zwar
als offenes Betriebssystem bezeichnet werden, da es ein öffentlich zugängliches SDK anbietet
und auch weitere Laufzeitumgebungen wie zum Beispiel Java und Python unterstützt. Auf
der anderen Seite sind 40 Prozent der Symbian-APIs im öffentlichen SDK durch Capabilities geschützt. Des Weiteren kann auf bestimmte Bereiche nur zugegriffen werden, wenn das
entsprechende SDK zur Verfügung steht. Beispielsweise kann eine Anti-Virus Anwendung nur
dann entwickelt werden, wenn das Symbian OS „Development Kit“ oder das „Binary Access
Kit“ verfügbar ist und den Zugriff auf die „File Hook API“ ermöglicht. Zusätzlich wird noch
die Tcb Capability benötigt, die nur mit Hilfe einer Mobiltelefonhersteller-Genehmigung erteilt werden kann. In diesem Beispiel hätte ein freier Entwickler nicht die Möglichkeit, eine
113
solche Anwendung zu implementieren, sodass hier die Offenheit, die Symbian sich als architektonisches Ziel (Abschnitt 2.2.6) gesetzt hat, aufgrund der Sicherheitsmerkmale der PSA
nicht völlig gegeben ist. Wie schon die Beispiele zu Beginn dieses Abschnitts verdeutlicht haben, sind auch die Beschränkungen, die Symbian ihren Entwicklern auferlegt hat, größtenteils
durch die Methoden in Kapitel 7 gebrochen worden. Jedoch soll zu Beginn der zweiten Jahreshälfte 2009 die „Symbian Foundation“ [42] dieses Problem lösen. Die „Symbian Foundation“
ist ein Zusammenschluss von Nokia, Sony Ericsson, Motorola und NTT DOCOMO, die sich
das Ziel gesetzt hat, eine offene, mobile Software Plattform zu erstellen, die Symbian OS,
S60, UIQ und MOAP(S) zu einem einzigen, offenen Betriebssystem vereinigt. Zusammen mit
AT&T, LG, Samsung, STMicroelectronics, Texas Instrument und Vodafone soll die „Symbian
Foundation“ genutzt werden, um den Anklang dieser vereinigten Software-Plattform zu erweitern. Die Mitgliedschaft in dieser gemeinnützigen Stiftung soll für alle Organisationen offen
sein. Schon zum Start der Stiftung sollen ausgewählte Komponenten im Quellcode verfügbar
sein. In den darauf folgenden zwei Jahren soll die komplette mobile Software im Quellcode
angeboten werden. Die dabei veröffentlichen Komponenten werden unter der „Eclipse Public
Licence (EPL) 1.0“ [43] veröffentlicht. Bei dieser in Zukunft offenen Plattform muss aber
erneut durch die Erfahrungen mit Symbian OS Version 9 die Frage gestellt werden, welche
Entwicklergruppen auf das komplette Betriebssystem zugreifen werden können.
8.2. Fazit
Das Ziel dieser Diplomarbeit ist die Verifikation der Konfiguration, sowie geeignete Konfigurationsparameter der PSA zu finden. Dafür musste ein Testsystem entwickelt werden, das die
spezifizierte Funktionsweise der PSA verifiziert oder widerlegt. Das Testsystem sollte dabei
mit möglichst wenig Redundanz implementiert werden und die Testfälle sollten anhand einer Konfigurationsdatei automatisch generiert werden können. Während der Spezifikation der
Testfälle konnten insgesamt zehn Testbereiche der PSA identifiziert werden. Dabei konnten
die Merkmale und Kennzeichen der jeweiligen PSA-Eigenschaften auf die einzelnen Testbereiche abgebildet werden. Das Testsystem kann jedem Testbereich entsprechende Testfälle
zur Verfügung stellen. Durch die Unterteilung des Testsystems in einen Code-Builder, einen
Package-Creator und einen Emu-Builder konnte schon auf dieser Ebene mögliche Redundanz
vermieden werden. Durch diesen Aufbau konnte nicht nur eine gemeinsame Quellcode-Basis
für die verfügbaren Plattformen geschaffen werden, sondern der Code Builder garantiert auch,
dass keine Fehler bei der Erstellung der Testfälle entstehen, wenn diese korrekt definiert wurden. Durch die Konfigurationsdatei als zentralen Eingabeparameter für das Testsystem konnte
die automatische Generierung der Testfälle realisiert werden.
Die Ergebnisse der einzelnen Tests haben gezeigt, dass der Emulator nur zur Laufzeit für die
Verifikation der Funktionsweise herangezogen werden kann. In den meisten Testfällen konnte
der Emulator jedoch nicht verwendet werden. Daraus kann gefolgert werden, dass Tests auf
einem Mobiltelefon unabdingbar sind. Die SWIPolicy konnte als der zentrale Konfigurationspunkt der PSA ausgemacht werden. Der Benutzer spielt bei der Konfiguration der PSA
eine untergeordnete Rolle. Die Einstellungen des SWInstallers können nur dann konfiguriert
werden, wenn der entsprechende Parameter der SWIPolicy das auch erlaubt. In diesem Zusammenhang konnte auch festgestellt werden, dass der SWIPolicy von den Mobiltelefonherstellern
und den Mobilfunkanbietern nur wenig Beachtung geschenkt wird.
114
8.3. Ausblick
Alle spezifizierten Testfälle in den jeweiligen Testbereichen konnten die Funktionsweise entsprechend der Symbian PSA Definition verifizieren. Die Testfälle zeigten auch, dass wenn
überhaupt, es nur minimale Unterschiede zwischen den einzelnen Symbian OS Versionen gibt.
Auch beim Vergleich verschiedener Mobiltelefone mit der gleichen Symbian OS Version konnten zwischen diesen Modellen keine Unterschiede festgestellt werden.
In den Testfällen wurde deutlich, dass Symbian Signed mit der Gewährung von Capabilities
eine große Verantwortung auferlegt wurde und dadurch das Signierungsprogramm nicht jedem
Entwickler im vollen Umfang zur Verfügung steht. In Symbian OS ist jede öffentlich zugängliche Komponente gut dokumentiert. Aber aufgrund der Menge dieser Dokumentation ist es
vorgekommen, dass teilweise die gleichen API-Funktionen mit verschiedenen Capabilities definiert wurden. Die beschriebenen Methoden die Privilegien der Symbian Anwendungen zu
erhöhen, besitzen bis jetzt nur lokales Gefahrenpotential. Dennoch können auf diese Weise
unkontrolliert die Manufacturer Capabilities verwendet werden. Jedoch wollten die Mobilfunkanbieter diese Situation verhindern. Kann deshalb behauptet werden, dass die Symbian
PSA gebrochen ist? Die Antwort auf diese Frage kann nicht einfach mit Ja oder Nein beantwortet werden. Die Testfälle haben die korrekte Funktionsweise der PSA und das Zusammenspiel der einzelnen Komponenten in Verbindung mit Symbian Signed verifiziert, sodass
das Konzept der PSA als nicht gebrochen bezeichnet werden kann. Jedoch basieren fast alle
diese Möglichkeiten auf der gleichen Methode, die Capabilities im Emulator zu Testzwecken
zu deaktivieren. In dieser Hinsicht hat Symbian den „Rahmen“ der PSA auf den Mobiltelefonen nicht ausreichend geschützt. Das Konzept und die Implementierung der PSA besitzen
nach den Ergebnissen dieses Diplomarbeit und der Spezifikation von Symbian keine größeren
Fehler, sondern nur die Umgebung die die PSA umfasst.
8.3. Ausblick
Mit der Ankündigung der „Symbian Foundation“ gab es seitens anderer Mobiltelefonhersteller, die neben Nokia auch auf Symbian als Betriebssystem setzen, nur positive Reaktionen.
Anscheinend hat die Symbian-Gemeinde auf solch eine Nachricht schon lange gewartet. Doch
mit dieser Nachricht scheinen die Tage der Symbian Version 9 gezählt zu sein. Die Version
9.3 wird wohl die letzte Iteration von Symbian OS 9 sein. Die bereits spezifizierten Versionen
9.4 und 9.5, werden allem Anschein nach in die neue, offene Plattform integriert werden. Es
besteht wahrscheinlich noch die Möglichkeit Symbian Version 9.4, die für 2008 geplant war
[44], in die kommenden Mobiltelefone zu integrieren, jedoch ist das eine Entscheidung der
Mobiltelefonhersteller.
Die neue „Symbian Foundation“-Plattform wird nicht nur weitere Möglichkeiten für die Zukunft der Plattform anbieten, sondern soll auch die Kompatibilität zur Symbian OS Version 9
bewahren [45]. Dadurch ist nicht nur die aktuell verfügbare Software für Symbian OS 9 auf der
neuen Plattform lauffähig, sondern Entwicklern wird auch die Möglichkeit gegeben, Software
für die Zukunft zu entwickeln. Durch die Kompatibilität zu Symbian OS Version 9 wird auch
die PSA in der neuen Plattform integriert werden. Dadurch wäre auch das PSA-Testsystem
mit der neuen „Symbian Foundation“-Plattform kompatibel.
Bevor die „Symbian Foundation“ den Quellcode von Symbian OS „Open Source“ verfügbar
machen kann, muss zunächst der bestehende Quellcode von Symbian OS und S60 Modul für
115
Modul durchgesehen werden [46]. Dadurch kann der Quellcode von Drittherstellern, die der
„Symbian Foundation“ nicht beitreten, identifiziert werden und auf diese Weise kann außerdem sichergestellt werden, dass nur der Quellcode veröffentlicht wird, der auch veröffentlicht
werden darf. Teilweise müssten Komponenten diverser Dritthersteller ersetzt und neu implementiert werden, um es „Open Source“ verfügbar zu machen. Bei diesem gesamten Umstrukturierungsprozess könnten sich verschiedene Fehler einschleichen. Hier wäre es interessant zu
sehen, wie sich die Umstrukturierung des Symbian-Quellcodes auf das Testsystem auswirken
würde. Zu diesem Zweck könnte das Testsystem erneut eingesetzt werden, um das neue Symbian Betriebssystem auf die gleiche Weise zu untersuchen wie schon Symbian OS Version 9.
Dabei könnten die Testergebnisse beider Versionen miteinander verglichen und so eventuelle
Fehler in der neuen Version gefunden werden.
Das mit dieser Diplomarbeit vorgestellte Testsystem untersucht die Sicherheitsmechanismen
der PSA auf Anwendungsebene, ob die beschriebenen Sicherheitsmerkmale gemäß der Spezifikation funktionieren. Eine weiterführende Arbeit könnte direkt auf die korrekte Implementierung von Symbian OS Version 9 abzielen. Dabei könnte untersucht werden, ob in den
aktuellen Implementierungen der Symbian Versionen 9.x Schwachstellen oder sonstige Fehler
vorhanden sind. Wenn das beispielsweise der Fall ist, könnte der Frage nachgegangen werden,
wie sich diese Schwachstellen ausnutzen lassen könnten. Weiter könnte untersucht werden,
ob die gefundenen Schwachstellen versionsübergreifend sind. Das heißt, sind Schwachstellen
beispielsweise in Symbian OS 9.1 auch in Version 9.2 und 9.3 oder umgekehrt vorhanden.
Diese Frage könnte aber auch auf die „Symbian Foundation“-Plattform ausgeweitet werden,
ob gefundene Schwachstellen in Symbian OS 9.x auch in der neuen Plattform vorhanden sind.
Jedoch müsste für diese Untersuchung auch das entsprechende SDK zur Verfügung gestellt
werden. In der „Symbian Foundation“-Plattform sollte es aber kein Problem darstellen. In
diesem Zusammenhang könnten zunächst die einzelnen Funktionen auf ihre korrekten Rückgabewerte mit spezifischen Eingabeparametern untersucht werden. Zu diesem Zweck könnte
der API-Testbereich verwendet werden, um mögliche Fehler in den Funktionen zu finden. Da
die neue Plattform Symbian OS Version 9.x kompatibel ist, könnten die Testfälle auch für die
neue Plattform genutzt werden. Dafür müsste aber eine möglichst vollständige Definitionsdatei für die API-Testfälle beider Plattformen erstellt werden.
Ein weiteres interessantes Themengebiet zur Symbian PSA wäre die Untersuchung bekannter
Symbian S60 Viren. Hier könnte die Frage nach der Portierbarkeit auf Symbian Version 9 von
„Cabir“, „Skulls“ und Co. beantwortet werden. Ist die Implementierung dieser Viren prinzipiell
machbar, wenn die nötigen Capabilities zur Verfügung gestellt werden. In einem weiteren
Schritt könnte die Frage beantwortet werden, was die kleinstmögliche Menge an Capabilities
für diese Viren wäre. Könnten dadurch auch Viren mit User Capabilities implementiert und auf
Symbian Version 9 Mobiltelefonen verbreitet werden? In einem abschließenden Schritt könnten
in diesem Themengebiet die Methoden zur Privilegienerhöhung weiter untersucht werden.
Dabei könnte auch die Frage erläutert werden, ob diese Methoden zur Privilegienerhöhung
verwendet werden könnten um eine neue Klasse von Symbian-Viren zu erstellen.
Ein abschließendes Themengebiet, das in Zusammenhang mit der PSA bearbeitet werden
kann, ist die „MobileSandbox“. Im Anschnitt 7.4.3 habe ich beschrieben, dass es mit den
entsprechenden „Development Kits“ möglich ist, die „MobileSandbox“ auf Symbian OS Version
9 zu übertragen. In diesem Themengebiet könnte die Frage beantwortet werden, ob das „IATPatching“ auch praktisch für Symbian OS Version implementiert werden könnte.
116
Anhang
A.1. Definition der Testfälle
A. Testsystem
Die Definition der Testfälle soll hier als Referenz für das Testsystem dienen.
Data-Caging:
Capability: AllFiles
Access: read
Drive: C,E,Z
Path: \\sys,\\resource,\\private,\\private\\EHome
Signed: root
Access: write
Drive: C,E,Z
Path: \\sys,\\resource,\\private,\\private\\ EHome
Signed: root
Capability: none
Access: read
Drive: C,E,Z
Signed: root
Capability: none
Access: write
Drive: C,E,Z
Signed: root
Capability: Tcb
Access: read
Drive: C,E,Z
Signed: root
Capability: Tcb
Access: write
Drive: C,E,Z
Signed: root
Capability: Tcb AllFiles
Access: read
Drive: C,E,Z
Signed: root
Capability: Tcb AllFiles
Access: write
Drive: C,E,Z
Signed: root
Capability: none
Access: read
Drive: C,E,Z
Signed: dev
Capability: none
Access: write
Drive: C,E,Z
Signed: dev
Capability: none
Access: read
Drive: C,E,Z
Signed: self
Capability: none
Access: write
Drive: C,E,Z
Signed: self
Capability: none
Access: read
Drive: C,E,Z
Signed: none
Capability: none
Access: write
Drive: C,E,Z
Signed: none
119
A. Testsystem
File-Eclipsing:
Vorbereitung: Erste Konfig-Datei
Eclipsing Situation herstellen: Zweite KonfigDatei
Beide Pakete sollten den gleichen Namen haben.
Paket Eclipsing (Parameter Vertrauenswürdigkeit der Pakete):
Capability: none
Capability: none
Drive: C
Drive: E
File:
File:
Path:
Path:
Type: SA
Type: SA
At Install: true
At Install: true
Version: 1,0,0
Version: 1,0,0
Signed: self
Signed: self
Code[]
Code[]
Capability: none
Capability: none
Drive: C
Drive: E
File:
File:
Path:
Path:
Type: SA
Type: SA
At Install: true
At Install: true
Version: 1,0,0
Version: 1,0,0
Signed: self
Signed: dev
Code[]
Code[]
Capability: none
Capability: none
Drive: C
Drive: E
File:
File:
Path:
Path:
Type: SA
Type: SA
At Install: true
At Install: true
Version: 1,0,0
Version: 1,0,0
Signed: self
Signed: root
Code[]
Code[]
Capability: none
Drive: C
File:
Path:
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
File:
Path:
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
120
Capability: none
Drive: E
File:
Path:
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
File:
Path:
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: C
File:
Path:
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
File:
Path:
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Datei Eclipsing während Installation:
Beide gleiche Konfig-Datei, die zu 2 „clipsende“ Datei steht im Vordergrund.
Capability: none
Capability: none
Drive: C,C,C
Drive: E
File: TestSWISelf_1.txt, TestSWISelf_2.txt,
File: TestSWISelf_1.txt
TestSWISelf_3.txt
Path: \\Test\\Eclipsing
Path: \\Test\\Eclipsing, \\Test\\Eclipsing,
Type: SA
\\Test\\Eclipsing
At Install: true
Type: SA
Version: 1,0,0
At Install: true
Signed: self
Version: 1,0,0
Code[]
Signed: self
Code[]
Capability: none
Capability: none
Drive: E
Drive: E
Type: SA
Type: SA
At Install: true
At Install: true
Version: 1,0,0
Version: 1,0,0
Signed: dev
Signed: root
Code[]
Code[]
Capability: none
Drive: C,C,C
File: TestSWIRoot_1.txt, TestSWIRoot_2.txt,
TestSWIRoot_3.txt
\\Test\\Eclipsing
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
File: TestSWIRoot_2.txt
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
121
A. Testsystem
122
Capability: none
Drive: C,C,C
File: ExeTest_1SimpleEXE.exe,
ExeTest_2SimpleEXE.exe,
ExeTest_3SimpleEXE.exe
Path: \\sys\\bin, \\sys\\bin, \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
File: ExeTest_2SimpleEXE.exe
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C,C,C
ExeTest_2SimpleEXE.exe,
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C,C,C
File: TestDllTest_1DLL.dll,
TestDllTest_2DLL.dll, TestDllTest_3DLL.dll
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
File: TestDllTest_1DLL.dll
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C,C,C
TestDllTest_2DLL.dll, TestDllTest_3DLL.dll
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Datei Eclipsing zur Laufzeit:
Capability: none
Drive: C,C,C
File: TestRuntimeSelf_1.txt,
TestRuntimeSelf_2.txt,
TestRuntimeSelf_3.txt
\\Test\\Eclipsing
Type: SA
At Install: false
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
File: TestRuntimeSelf_2.txt
Type: SA
At Install: false
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
Type: SA
At Install: false
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
Type: SA
At Install: false
Version: 1,0,0
Signed: root
Code[]
123
A. Testsystem
Capability: none
Drive: C,C,C
File: TestRuntimeRoot_1.txt,
TestRuntimeRoot_2.txt,
TestRuntimeRoot_3.txt
\\Test\\Eclipsing
Type: SA
At Install: false
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: E
File: TestRuntimeRoot_2.txt
Type: SA
At Install: false
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: E
Type: SA
At Install: false
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: E
Type: SA
At Install: false
Version: 1,0,0
Signed: root
Code[]
File-Overwriting:
Vorbereitung: Erste Konfig-Datei
Overwriting Situation herstellen: Zweite
Konfig-Datei
Beide Pakete sollten den gleichen Namen haben.
Paket Overwriting (Parameter Vertrauenswürdigkeit der Pakete): funktioniert nur bei Updates,
Updateverhalten
Capability: none
Capability: none
Drive: Drive: File: File: Path: Path: Type: SA
Type: SA
At Install: true
At Install: true
Version: 1,0,0
Version: 2,0,0
Signed: self
Signed: self
Code[]
Code[]
Capability: none
Capability: none
Drive: Drive: File: File: Path: Path: Type: SA
Type: SA
At Install: true
At Install: true
Version: 1,0,0
Version: 2,0,0
Signed: self
Signed: dev
Code[]
Code[]
124
Capability: none
Drive: File: Path: Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
At Install: true
Version: 2,0,0
Signed: root
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
At Install: true
Version: 2,0,0
Signed: self
Code[]
Capability: none
At Install: true
Version: 2,0,0
Signed: dev
Code[]
Capability: none
At Install: true
Version: 2,0,0
Signed: root
Code[]
Update:
Capability: none
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: File: Path: Type: PU
At Install: true
Version: 2,0,0
Signed: self
Code[]
125
A. Testsystem
126
Capability: none
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
At Install: true
Version: 2,0,0
Signed: root
Code[]
Capability: none
At Install: true
Version: 2,0,0
Signed: self
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
File: TestRuntimeNone_1.txt
Path: \\private
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Capability: none
Drive: C
Path: \\private
Type: SP
At Install: true
Version: 2,0,0
Signed: self
Code[]
Capability: none
Drive: C
Path: \\private
Type: SP
At Install: true
Version: 2,0,0
Signed: root
Code[]
Capability: none
Drive: C
Path: \\private
Type: SP
At Install: true
Version: 2,0,0
Signed: self
Code[]
Capability: none
Drive: C
Path: \\private
Type: SP
At Install: true
Version: 2,0,0
Signed: self
Code[]
Datei Overwriting während Installation:
Capability: none
Drive: C,C,C
File: TestSWISelf_1.txt, TestSWISelf_2.txt,
TestSWISelf_3.txt
Path: \\Test\\ Overwriting, \\Test\\
Overwriting, \\Test\\ Overwriting
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Path: \\Test\\ Overwriting
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Code[]
Capability: none
Drive: C
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C,C,C
File: TestSWIRoot_1.txt, TestSWIRoot_2.txt,
TestSWIRoot_3.txt
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
Type: SA
At Install: true
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: C
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C,C
Path: \\sys\\bin, \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Capability: none
Drive: C
Path: \\sys\\ bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
127
A. Testsystem
Code[]
Capability: none
Drive: C
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
128
Capability: none
Drive: C,C
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
Path: \\sys\\ bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C,C
TestDllTest_2DLL.dll
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
Path: \\sys\\ bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C,C
TestDllTest_2DLL.dll
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
Path: \\sys\\bin
Type: SA
At Install: true
Version: 1,0,0
Signed: root
Code[]
Datei Overwriting zur Laufzeit:
Capability: none
Drive: C,C,C
File: TestRuntimeSelf_1.txt,
TestRuntimeSelf_2.txt,
TestRuntimeSelf_3.txt
Type: SA
At Install: false
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Type: SA
At Install: false
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: C,C,C
File: TestRuntimeRoot_1.txt,
TestRuntimeRoot_2.txt,
TestRuntimeRoot_3.txt
Type: SA
At Install: false
Version: 1,0,0
Signed: root
Capability: none
Drive: C
Path: \\sys\\ bin
Type: SA
At Install: true
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Type: SA
At Install: false
Version: 1,0,0
Signed: self
Code[]
Capability: none
Drive: C
Type: SA
At Install: false
Version: 1,0,0
Signed: root
Code[]
Capability: none
Drive: C
Type: SA
At Install: false
Version: 1,0,0
Signed: self
Code[]
129
A. Testsystem
Code[]
Capability: none
Drive: C
Type: SA
At Install: false
Version: 1,0,0
Signed: dev
Code[]
Capability: none
Drive: C
Type: SA
At Install: false
Version: 1,0,0
Signed: root
Code[]
SWInstaller:
MIME Test:
Capability: LocalServices NetworkServices ReadUserData WriteUserData UserEnvironment
Signed: none
MIME: FR,RI
Path: \\sys\\bin
File: Console_SWI.exe
Signed: self
MIME: FR,RI
Path: \\sys\\bin
Signed: dev
MIME: FR,RI
Path: \\sys\\bin
Signed: root
MIME: FR,RI
Path: \\sys\\bin
130
Copy Files Test:
Capability: LocalServices NetworkServices
ReadUserData WriteUserData UserEnvironment
Drive: C
Path: \\sys\\bin
File: TestSWI.txt
Signed: none
Drive: C
Path: \\sys\\bin
File: Console_Copy.exe
Signed: none
Drive: C
Path: \\resource
File: TestSWI.txt
Signed: none
Drive: C
Path: \\resource
Signed: none
Drive: C
Path: \\private\\EHome
File: TestSWI.txt
Signed: none
Drive: C
Signed: none
Drive: C
Path: \\private
File: TestSWI.txt
Signed: none
Drive: C
Path: \\private
Signed: none
Drive: C
Path: \\sys\\bin
File: TestSWI.txt
Signed: self
Drive: C
Path: \\sys\\bin
Signed: self
Drive: C
Path: \\resource
File: TestSWI.txt
Signed: self
Drive: C
Path: \\resource
Signed: self
Drive: C
File: TestSWI.txt
Signed: self
Drive: C
Signed: self
Drive: C
Path: \\private
File: TestSWI.txt
Signed: self
Drive: C
Path: \\private
Signed: self
Drive: C
Path: \\sys\\bin
File: TestSWI.txt
Signed: dev
Drive: C
Path: \\sys\\bin
Signed: dev
Drive: C
Path: \\resource
File: TestSWI.txt
Signed: dev
Drive: C
Path: \\resource
Signed: dev
131
A. Testsystem
Drive: C
File: TestSWI.txt
Signed: dev
Drive: C
Signed: dev
Drive: C
Path: \\private
File: TestSWI.txt
Signed: dev
Drive: C
Path: \\private
Signed: dev
Drive: C
Path: \\sys\\bin
File: TestSWI.txt
Signed: root
Drive: C
Path: \\sys\\bin
Signed: root
Drive: C
Path: \\resource
File: TestSWI.txt
Signed: root
Drive: C
Path: \\resource
Signed: root
Drive: C
File: TestSWI.txt
Signed: root
Drive: C
Signed: root
Drive: C
Path: \\private
File: TestSWI.txt
Signed: root
Drive: C
Path: \\private
Signed: root
Caps Test:
File: MIME: Signed: none
Capability: LocalServices NetworkServices ReadUserData WriteUserData UserEnvironment PowerMgmt
132
DiskAdmin
DiskAdmin TCB
File: MIME: Signed: self
DiskAdmin
DiskAdmin TCB
File: MIME: Signed: dev
DiskAdmin
DiskAdmin TCB
133
A. Testsystem
File: MIME: Signed: root
DiskAdmin
DiskAdmin TCB
Certificate:
Capability: Alle UserCaps
Signed: none
Capability: devCert Caps
Signed: none
Capability: Symbian Signed
Signed: none
Capability: Manu Caps
Signed: none
Signed: self
Signed: self
Signed: self
Signed: self
Signed: dev
Signed: dev
Signed: dev
Signed: dev
Signed: root
Signed: root
Signed: root
Signed: root
Signed: open signed
Signed: open signed
Signed: open signed
Signed: open signed
Capabilities:
134
Capability Regeln:
Capability: None
Signed: self
CapTests: none
Kind: dll
Capability: None
Signed: self
CapTests: none
Kind: exe
Capability: ReadUserData
Signed: self
CapTests: none
Kind: dll
Capability: None
Signed: dev
CapTests: none
Kind: exe
Capability: ReadUserData WriteUserData
Signed: self
CapTests: none
Kind: dll
Capability: None
Signed: root
CapTests: none
Kind: exe
Capability: WriteUserData
Signed: self
CapTests: none
Kind: dll
Signed: self
CapTests: none
Kind: exe
Signed: self
CapTests: none
Kind: dll
Signed: root
CapTests: none
Kind: exe
Capability: WriteUserData ReadUserData
Signed: root
CapTests: none
Kind: dll
Signed: self
CapTests: none
Kind: exe
Capability: none
Signed: root
CapTests: none
Kind: dll-1
Capability: none
Signed: root
CapTests: none
Kind: dll-3
Capability: none
Signed: self
CapTests: none
Kind: dll-2
Capability: none
Signed: self
CapTests: none
Kind: exe
Capability: WriteUserData ReadUserData SWEvent
ReadDeviceData DiskAdmin
Signed: root
CapTests: none
Kind: dll-1
Signed: root
CapTests: none
Kind: dll-3
Signed: root
CapTests: none
Kind: dll-2
Signed: root
CapTests: none
Kind: exe
Signed: root
CapTests: none
Kind: dll-1
Signed: root
CapTests: none
Kind: dll-3
ReadDeviceData
Signed: root
CapTests: none
Kind: dll-2
Signed: root
CapTests: none
Kind: exe
Signed: root
ReadDeviceData
Signed: root
135
A. Testsystem
CapTests: none
Kind: dll-1
ReadDeviceData
Signed: root
CapTests: none
Kind: dll-3
CapTests: none
Kind: dll-2
ReadDeviceData
Signed: root
CapTests: none
Kind: exe
Signed: root
CapTests: none
Kind: dll-1
Signed: root
CapTests: none
Kind: dll-2
ReadDeviceData
Signed: root
CapTests: none
Kind: exe
Signed: root
CapTests: none
Kind: dll-3
Einzelne Capabilities, Zertifikat ist abhängig von der Capability:
Capability: None
Signed: self
Signed: self
CapTests: ReadUserData
CapTests: ReadUserData
Kind: exe
Kind: exe
136
Signed: self
CapTests: WriteUserData
Kind: exe
Capability: None
Signed: self
CapTests: WriteUserData
Kind: exe
Capability: LocalServices
Signed: self
CapTests: LocalServices
Kind: exe
Capability: None
Signed: self
Kind: exe
Capability: NetworkServices
Signed: self
CapTests: NetworkServices
Kind: exe
Capability: None
Signed: self
CapTests: NetworkServices
Kind: exe
Capability:
ReadDeviceData
Signed: dev
Kind: exe
Capability: None
Signed: dev
Kind: exe
Capability:
ReadDeviceData
Signed: root
CapTests:
ReadDeviceData
Kind: exe
Capability:
WriteDeviceData
Signed: dev
CapTests:
WriteDeviceData
Kind: exe
Capability: None
Signed: dev
CapTests:
WriteDeviceData
Kind: exe
Capability:
WriteDeviceData
Signed: root
CapTests:
WriteDeviceData
Kind: exe
Capability: None
Signed: root
CapTests: ReadDeviceData
Kind: exe
Capability: None
Signed: root
CapTests:
WriteDeviceData
Kind: exe
Capability: SWEvent
Signed: dev
CapTests: SWEvent
Kind: exe
Capability: None
Signed: dev
CapTests: SWEvent
Kind: exe
Capability: SWEvent
Signed: root
CapTests: SWEvent
Kind: exe
Capability: None
Signed: root
CapTests: SWEvent
Kind: exe
Capability:
NetworkControl
Signed: root
CapTests: NetworkControl
Kind: exe
Capability: None
Signed: root
CapTests:
NetworkControl
Kind: exe
Capability: DiskAdmin
Signed: root
CapTests: DiskAdmin
Kind: exe
Capability: None
Signed: root
CapTests: DiskAdmin
Kind: exe
Capability: Tcb
Signed: root
CapTests: Tcb
Kind: exe
Capability: None
Signed: root
CapTests: Tcb
Kind: exe
Signed: root
CapTests: AllFiles
Kind: exe
Capability: None
Signed: root
CapTests: AllFiles
Kind: exe
Client/Server (CapTests kann irgendwas sein):
Capability: None
Signed: self
Signed: self
Kind: cs
Kind: cs
Capability: None
Signed: self
Kind: client
Capability: None
Signed: root
Kind: client
Signed: self
Kind: server
Signed: root
Kind: server
Capability: None
Signed: dev
Kind: client
Signed: dev
Kind: server
Signed: self
Kind: client
Signed: root
Kind: client
Capability: None
Signed: self
Kind: server
Capability: None
Signed: root
Kind: server
Signed: dev
Kind: client
Capability: None
Signed: dev
Kind: server
Signed: self
Kind: client
Capability: None
Signed: dev
Kind: server
Signed: dev
Kind: client
Capability: None
Signed: self
Kind: server
Capability: None
Signed: self
Kind: client
Capability: None
Signed: root
Kind: server
Capability: None
Signed: root
Kind: client
Capability: None
Signed: self
Kind: server
Capability: None
Capability: None
137
A. Testsystem
Signed: self
Kind: client
Signed: root
Kind: server
Signed: root
Kind: client
Signed: self
Kind: server
Integrity:
Capability: userCap
Capability: userCap
Capability: userCap
Capability: userCap
Signed: none
Signed: self
Signed: dev
Signed: root
File: File: File: File: Path: Path: Path: Path: Drive: Drive: Drive: Drive: Erstellen und den Hex-Code der SIS-Datei verändern und versuchen zu installieren.
Capability: userCap
Capability: userCap
Capability: userCap
Capability: userCap
Signed: none
Signed: self
Signed: dev
Signed: root
File: File: File: File: Path: Path: Path: Path: Drive: Drive: Drive: Drive: Installieren auf C:, - EXE auf hex ebene verändern-> Kann Anwendung noch gestartet werden?
- EXE, Capability verändern->Kann Anwendung noch gestartet werden?
Installieren auf C:, - EXE auf hex ebene verändern und hash anpassen (neu berechnen)-> Kann Anwendung
noch gestartet werden?
- EXE, Capability verändern und hash anpassen->Kann Anwendung noch gestartet
werden?
Installieren auf E:, - EXE auf hex ebene verändern-> Kann Anwendung noch gestartet werden?
Installieren auf E:, - EXE auf hex ebene verändern und hash anpassen (neu berechnen)-> Kann Anwendung
noch gestartet werden?
- EXE, Capability verändern und hash anpassen->Kann Anwendung noch gestartet
werden?
Capability: userCap
Capability: userCap
Capability: userCap
Capability: userCap
Signed: none
Signed: self
Signed: dev
Signed: root
File: TestIntegrity.txt
Path: Path: Path: Path: Drive: C
Drive: C
Drive: C
Drive: C
Installieren auf C:,- Ressourcen verändern -> Kann Anwendung ausgeführt werden?
- Mitgelieferte Datei verändern -> Kann Anwendung noch ausgeführt werden?
- Lesedatei verändern -> Kann Anwendung ausgeführt werden?
Installieren auf E:,- Ressourcen verändern -> Kann Anwendung ausgeführt werden?
- Mitgelieferte Datei verändern -> Kann Anwendung noch ausgeführt werden?
- Lesedatei verändern -> Kann Anwendung ausgeführt werden?
Capability: userCap
Capability: userCap
Capability: userCap
Capability: userCap
Signed: none
Signed: self
Signed: dev
Signed: root
Path: Path: Path: Path: Drive: C
Drive: C
Drive: C
Drive: C
Type: PA
Type: PA
Type: PA
Type: PA
Auf Speicherkarte kopieren (mit Stub) und Anwendung installieren,
- EXE auf hex ebene verändern-> Kann Anwendung noch gestartet werden?
Auf Speicherkarte kopieren (mit Stub) und Anwendung installieren,
- EXE auf hex ebene verändern und hash anpassen -> Kann Anwendung noch gestartet
138
werden?
- EXE, Capability verändern und hash anpassen ->Kann Anwendung noch gestartet werden?
Auf Speicherkarte kopieren (ohne Stub),
- EXE auf hex ebene verändern und installieren mit stub-> Kann Anwendung noch gestartet
werden?
- EXE, Capability verändern und installieren mit stub ->Kann Anwendung noch gestartet
werden?
Auf Speicherkarte kopieren (ohne Stub),
- EXE auf hex ebene verändern und hash Anpassen und installieren mit stub -> Kann
Anwendung noch gestartet werden?
- EXE, Capability verändern und hash anpassen und installieren mit stub -> Kann
Anwendung noch gestartet werden?
Shared-Data:
Publish & Subscribe:
Capability: none
Signed: self
Kind: ps
ProcessType: main
ReadPolicy: ECapabilityAlwaysPass
WritePolicy: ECapabilityAlwaysPass
Capability: none
Signed: self
Kind: ps
ProcessType: simple
Capability: none
Signed: self
Kind: ps
ProcessType: main
ReadPolicy: ECapabilityAlwaysFail
WritePolicy: ECapabilityAlwaysFail
Capability: none
Signed: self
Kind: ps
ProcessType: simple
Signed: self
Kind: ps
ProcessType: main
ReadPolicy: ECapabilityReadUserData
WritePolicy: ECapabilityWriteUserData
Signed: self
Kind: ps
ProcessType: simple
Capability: none
Signed: self
Kind: ps
ProcessType: main
Signed: self
Kind: ps
ProcessType: simple
Signed: self
Kind: ps
ProcessType: main
Capability: none
Signed: self
Kind: ps
ProcessType: simple
Signed: self
Kind: ps
ProcessType: main
Signed: self
Kind: ps
ProcessType: simple
139
A. Testsystem
ReadPolicy: ECapabilityAlwaysFail
WritePolicy: ECapabilityAlwaysFail
Signed: self
Kind: ps
ProcessType: main
140
Signed: self
Kind: ps
ProcessType: simple
File Handle:
Capability: none
Signed: self
Kind: fh
ProcessType: main
Capability: none
Signed: self
Kind: fh
ProcessType: simple
Signed: self
Kind: fh
ProcessType: main
Signed: self
Kind: fh
ProcessType: simple
Capability: none
Signed: self
Kind: fh
ProcessType: main
Signed: self
Kind: fh
ProcessType: simple
Signed: self
Kind: fh
ProcessType: main
Capability: none
Signed: self
Kind: fh
ProcessType: simple
Data Chunk:
Capability: none
Signed: self
Kind: chunk
ProcessType: main
Capability: none
Signed: self
Kind: chunk
ProcessType: simple
Signed: self
Kind: chunk
ProcessType: main
Signed: self
Kind: chunk
ProcessType: simple
Capability: none
Signed: self
Kind: chunk
ProcessType: main
Signed: self
Kind: chunk
ProcessType: simple
Signed: self
Kind: chunk
ProcessType: main
Capability: none
Signed: self
Kind: chunk
ProcessType: simple
IDs:
Capability: UserCaps
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: E1CA1D5D
UID3: E1BA1D5D
SID: E1CA1D5D
SID: E1BA1D5D
VID: 0
VID: 0
pUID: E1CA1D5D
pUID: E1BA1D5D
Standard Testbereich, UID3=SID=pUID
Signed: dev
UID2: 100039CE
UID3: E1CA1D5F
SID: E1CA1D5F
VID: 0
pUID: E1CA1D5F
Signed: root
UID2: 100039CE
UID3: E2CA1D5F
SID: E2CA1D5F
VID: 0
pUID: E2CA1D5F
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: E1CC1D5D
UID3: E1BA1D51
SID: E1CC1D5D
SID: E1BA1D51
VID: 0
VID: 0
pUID: E1C21D5D
pUID: E1BA1D52
Standard Testbereich, UID3=SID!=pUID
Signed: dev
UID2: 100039CE
UID3: E1CA1D53
SID: E1CA1D53
VID: 0
pUID: E1CA1D54
Signed: root
UID2: 100039CE
UID3: E2CA1D55
SID: E2CA1D55
VID: 0
pUID: E2CA1D56
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: E1CC1D1D
UID3: E1BA1DA1
SID: E1CC1D2D
SID: E1BA1DB1
VID: 0
VID: 0
pUID: E1C21D3D
pUID: E1BA1DC2
Standard Testbereich, UID3!=SID!=pUID
Signed: dev
UID2: 100039CE
UID3: E1CA1DA3
SID: E1CA1DB3
VID: 0
pUID: E1CA1DC4
Signed: root
UID2: 100039CE
UID3: E2CA1DA5
SID: E2CA1DB5
VID: 0
pUID: E2CA1DC6
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: E1CA1D59
UID3: E1BA1D58
SID: E1CA1D59
SID: E1BA1D58
VID: 7A234567
VID: 7A345678
pUID: E1CA1D59
pUID: E1BA1D58
Standard Testbereich, UID3=SID=pUID mit VID
Signed: dev
UID2: 100039CE
UID3: E1CA1D57
SID: E1CA1D57
VID: 7A456789
pUID: E1CA1D57
Signed: root
UID2: 100039CE
UID3: E2CA1D56
SID: E2CA1D56
VID: 7A567890
pUID: E2CA1D56
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: 2AA12345
UID3: 2AA23456
SID: 2AA12345
SID: 2AA23456
VID: 0
VID: 0
pUID: 2AA12345
pUID: 2AA23456
Geschützter Bereich, UID3=SID=pUID
Signed: dev
UID2: 100039CE
UID3: 2AA34567
SID: 2AA34567
VID: 0
pUID: 2AA34567
Signed: root
UID2: 100039CE
UID3: 2AA45678
SID: 2AA45678
VID: 0
pUID: 2AA45678
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: 2AB12345
UID3: 2AB23456
SID: 2AB12345
SID: 2AB23456
VID: 0
VID: 0
pUID: 2AB12346
pUID: 2AB23457
Geschützter Bereich, UID3=SID!=pUID
Signed: dev
UID2: 100039CE
UID3: 2AB34568
SID: 2AB34568
VID: 0
pUID: 2AB34569
Signed: root
UID2: 100039CE
UID3: 2AB45679
SID: 2AB45679
VID: 0
pUID: 2AB45680
141
A. Testsystem
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: 2AC12345
UID3: 2AC23456
SID: 2AC12346
SID: 2AC23457
VID: 0
VID: 0
pUID: 2AC12347
pUID: 2AC23458
Geschützter Bereich, UID3!=SID!=pUID
Signed: dev
UID2: 100039CE
UID3: 2AC34567
SID: 2AC34568
VID: 0
pUID: 2AC34569
Signed: root
UID2: 100039CE
UID3: 2AC45678
SID: 2AC45679
VID: 0
pUID: 2AC45670
Signed: none
Signed: self
UID2: 100039CE
UID2: 100039CE
UID3: 2AD12345
UID3: 2AD23456
SID: 2AD12345
SID: 2AD23456
VID: 7B234567
VID: 7B345678
pUID: 2AD12345
pUID: 2AD23456
Geschützter Bereich, UID3=SID=pUID mit VID
Signed: dev
UID2: 100039CE
UID3: 2AD34567
SID: 2AD34567
VID: 7B456789
pUID: 2AD34567
Signed: root
UID2: 100039CE
UID3: 2AD45678
SID: 2AD45678
VID: 7B567890
pUID: 2AD45678
API:
Class: RFile
Method: Open
ExpectedOutputValue: -1
Parameter: session,_L(“C:\\Data\\TestAPI.txt”),EFileWrite
PrepareCode[
RFs session;
session.Connect();
]
Class: RFile
Method: Create
ExpectedOutputValue: -46
Parameter: session,_L(“C:\\sys\\bin\\TestAPI.txt”),EFileRead
PrepareCode[
RFs session;
session.Connect();
]
Class: RFile
Method: Create
ExpectedOutputValue: 0
Parameter: session,_L(“C:\\TestAPI.txt”),EFileRead
PrepareCode[
RFs session;
session.Connect();
]
142
• Der Pfad \\private wird durch \\private\\<ownSID> ersetzt.
• Für das Schreiben in ein anderes privates Verzeichnis, einfach \\private\\<otherSID>
angeben.
• Beim Eclipsing/Overwriting darf pro Laufwerk nur ein Pfad und eine Datei angegeben
werden.
• Beim Data Caging gilt obige Restriktion nicht.
• Für einen Testfall kann nur ein Zertifikat benutzt werden.
• Ein Standard SA-Package, das nicht als Update vorgesehen ist, bekommt die Versionsnummer 1,0,0.
• Pro Testfall kann nur ein Package-Typ definiert werden.
• Es darf nur ein Update definiert werden (SA, PU, SP), wenn zuvor schon eine SA-Anwendung
mit der Versionsnummer 1,0,0 installiert wurde.
• Die einzelnen Capability-Tests (CapTests) heißen genauso wie ihre Capabilities.
• Wird eine dll in einem Testfall definiert, so muss eine exe folgen, die dann zur dll
gelinkt wird. Werden hingegen mehrere DLL hintereinander definiert, so muss anschließend auch eine exe definiert werden und die einzelnen dll werden ineinander gelinkt.
• Um Testfelder zu deklarieren, müssen sie am Anfang der Konfigurationsdatei hinter das
Schlüsselwort Test Fields, durch ein Komma getrennt, spezifiziert werden.
• Shared-Data
– Der main ProcessType muss immer vor dem simple ProcessType definiert werden.
– Zurzeit wird pro ProcessType main nur ein ProcessType simple unterstützt.
– Die einzelnen Capabilities für die Policies werden durch das Präfix ECapability
gefolgt von der eigentlichen Capability definiert. Diese Definitionen werden durch
eine Komma ohne Leerzeichen voneinander getrennt. Darüber hinaus gibt es noch
die besonderen Policies ECapabilityAlwaysPass und ECapabilityAlwaysFail.
– Read/Write Policy nur relevant bei Publish & Subscribe.
143
A. Testsystem
A.3. Test SWIPolicies
Die hier dargestellten SWIPolicies wurden für die SWInstaller- und Certificate-Testfälle benutzt.
A.3.1. SWInstaller
Quelltext A.1: Developer SWIPolicy
Oid = 1.2.3.4.5.6
DRMEnabled = true
DRMIntent = 3
OcspEnabled = true
UserCapabilities = NetworkServices LocalServices UserEnvironment
ReadUserData WriteUserData Location PowerMgmt
AllowRu n On In st a ll Un in s ta ll = true
De le te P r e i n s t a l l e d F i l e s O n U n i n s t a l l = true
Quelltext A.2: Symbian Signed SWIPolicy
Oid = 1.2.3.4.5.6
DRMEnabled = true
DRMIntent = 3
OcspEnabled = true
DiskAdmin
Quelltext A.3: Device Manufacturer SWIPolicy
144
A.3. Test SWIPolicies
MandateCod e S ig n in g E xt e ns i on = false
Oid = 1.2.3.4.5.6
DRMEnabled = true
DRMIntent = 3
OcspEnabled = true
AllowGrant Us er C ap ab il i ti es = true
DiskAdmin TCB
SISCompa t i b l e I f N o T a r g e t D e v i c e s = false
AllowRunOn In st a ll Un in s ta ll = false
De le te Pr e i n s t a l l e d F i l e s O n U n i n s t a l l = true
A.3.2. Certificate
Quelltext A.4: Certificate SWIPolicy 1
MandatePolicies = true
MandateCod e S ig n in g E xt e ns i on = false
Oid = 1.2.3.4.5.6
DRMEnabled = true
DRMIntent = 3
OcspEnabled = true
AllowGrant Us er C ap ab il i ti es = true
ReadUserData WriteUserData Location
SISCompa t i b l e I f N o T a r g e t D e v i c e s = false
AllowRunOn In st a ll Un in s ta ll = false
De le te Pr e i n s t a l l e d F i l e s O n U n i n s t a l l = true
AllowUnsigned = false
MandatePolicies = true
MandateCod e S ig n in g E xt e ns i on = true
Oid = 1.2.3.4.5.6
DRMEnabled = true
DRMIntent = 3
145
A. Testsystem
OcspEnabled = true
AllowUnsigned = false
Oid = 1.2.3.4.5.6
DRMEnabled = true
DRMIntent = 3
OcspMandatory = true
OcspEnabled = true
146
B. CD-Inhalt
Dieser Abschnitt beschreibt den Inhalt der beigefügten CD.
B.1. Quellcode
In diesem Verzeichnis befindet sich der Quellcode des Testsystems und der einzelnen SymbianTestanwendungen.
\ Quellcode
-\ Batch
-\ Perl
-\ SymbianC ++
B.2. Testsystem
Dieses Verzeichnis beinhaltet die Protokolle der Testläufe und deren Auswertung. Darüber
hinaus enthält dieses Verzeichnis die Konfigurationsdateien und die kompilierten Testfälle für
die jeweilige Plattform.
\ Testsystem
-\ Ergebnisse
-\ Auswertung
-\ E61
-\ E90
-\ Emu
-\ N81_8GB
-\ N95
-\ Standard SWIPolicies
-\ Tests
-\ API
-\ Capabilities
-\ Data - Caging
-\ File - Eclipsing
-\ File - Overwriting
-\ IDs
-\ Integrity
-\ Shared - Data
-\ SWInstaller
147
B. CD-Inhalt
B.3. Privilegien erhöhen
In diesem Verzeichnis sind alle Anwendungen und Skripte enthalten, die im Kapitel 7 beschrieben wurden.
\ Privilegien_erhöhen
-\ ChangePolicyPath
-\ hack_perms
-\ ROMPatcher
-\ root - Certificate
148
[1] Craig Heath. Symbian OS Platform Security. Symbian Press John Wiley & Sons, Ltd,
2006.
[2] Jane Sales. Symbian OS Internals - Real-time Kernel Programming. Symbian Press John
Wiley & Sons, Ltd, 2005.
[3] Symbian. How do i get my symbian os application signed? Technical Report Version 2.4,
Symbian Software Ltd.
[4] Symbian. Symbian Signed Test Criteria. Technical Report Version 3.0.2, Symbian Software Ltd., 2008.
[5] Michael Becher and Felix C. Freiling. Towards Dynamic Malware Analysis to Increase
Mobile Device Security. In Proc. of SICHERHEIT, 2008.
[6] Canalys. Research release 2008/021. Technical report, canalys.com ltd., 2008.
[7] R. Shirey. Internet Security Glossary. RFC 2828 (Informational), May 2000. Obsoleted
by RFC 4949.
[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509 Internet Public
Key Infrastructure Online Certificate Status Protocol - OCSP. RFC 2560 (Proposed
Standard), June 1999.
[9] James P. Anderson. Computer security technology planning study. Electronic Systems
Division, Air Force Systems, Vol. II(ESD-TR-73-51), October 1972.
[10] Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer
systems. Proceedings of the IEEE, 63, Issue: 9:1278– 1308, Sept. 1975.
[11] Jack B. Dennis and Earl C. Van Horn. Programming semantics for multiprogrammed
computations. Commun. ACM, 9(3):143–155, 1966.
[12] Black box testing.
Website.
http://issco-www.unige.ch/ewg95/node82.html\
#SECTION00732000000000000000. Accessed: 03.09.2008.
[13] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile. RFC 3280 (Proposed Standard), April 2002. Obsoleted by RFC 5280, updated by RFCs 4325, 4630.
[14] Symbian. What Symbian OS Development Kit Do I Need? Technical Report Version
1.7, Symbian Software Ltd. https://developer.symbian.com/wiki/pages/viewpage.
action?pageId=1859. Accessed: 03.09.2008.
149
[15] Symbian.
Symbian OS Changes for Platform Security.
Website.
http:
//www.symbian.com/developer/techlib/v9.2docs/doc_source/guide/platsecsdk/
migration.html\#guide.platsec.migration. Accessed: 02.09.2008.
[16] Symbian Software Ltd. SWIPOLICY.INI - Software installer configuration version
9.2. Website. http://www.symbian.com/developer/techlib/v9.2docs/doc_source/
ToolsAndUtilities/Installing-ref/swipolicy.html. Accessed: 05.09.2008.
[17] Symbian Software Ltd. SWIPOLICY.INI - Software installer configuration version 9.3.
Website.
http://www.symbian.com/developer/techlib/v9.3docs/doc_
source/ToolsAndUtilities93/Installing-ref/swipolicy.html\#Installing-ref.
swipolicy.ini-syntax. Accessed: 05.09.2008.
[18] Symbian.
Functions listed by capability - Symbian Version 9.1 API.
Website.
http://www.symbian.com/developer/techlib/v9.2docs/doc_source/guide/
platsecsdk/GT_9.1/FunctionsByCapablity.html. Accessed: 03.09.2008.
[19] Symbian.
Website.
[20] Nokia Forum - Developer Community Wiki. File logger. Website. http://wiki.forum.
nokia.com/index.php/File_logger. Accessed: 02.09.2008.
[21] AutoInstaller v1.0 - A New Full Automatic Installer for S60.
Website.
http://www.symbian-freak.com/downloads/freeware/cat_s60_3rd/descriptions/
systools/autoinstaller__new_full_automatic_installer.htm.
Accessed:
31.08.2008.
[22] Jukka Silvennoinen. Y-Browser: Free filemanager for symbian smartphones. Website.
http://www.drjukka.com/YBrowser.html. Accessed: 31.08.2008.
[23] Maël Hörz. HxD - Freeware Hex Editor and Disk Editor. Website. http://www.
mh-nexus.de/hxd/. Accessed: 31.08.2008.
[24] X-Ways Software Technology AG. WinHex: Software für Computerforensik und Datenrettung, Hex-Editor und Disk-Editor. Website. http://www.x-ways.net/winhex/
index-d.html. Accessed: 31.08.2008.
[25] Symbian. Symbian Phones. Website. http://www.symbian.com/phones/index.html
Accessed: 31.08.2008.
[26] D. Eastlake 3rd and P. Jones. US Secure Hash Algorithm 1 (SHA1). RFC 3174 (Informational), September 2001. Updated by RFC 4634.
[27] Nokia Research Center. Python for S60. Website. http://opensource.nokia.com/
projects/pythonfors60/. Accessed: 02.09.2008.
[28] Symbian.
Website.
150
[29] Symbaali Blog. Goodbye S60 Platform Security, Hello CAPABILITIES! . Website. http://www.symbaali.info/2007/10/goodbye-s60-platform-security-hello.
html. Accessed: 02.09.2008.
[30] Symbaali Blog. Exploring S60 with AllFiles. Website. http://www.symbaali.info/
2007/10/exploring-s60-with-allfiles.html. Accessed: 01.09.2008.
[31] Symbian Freak. Goodbye S60 Platform Security!?? - Hack to override permissions?!! Website. http://www.symbian-freak.com/news/008/03/s60_3rd_ed_has_been_hacked.
htm. Accessed: 01.09.2008.
[32] Part-Time Phone Reviewer. Symbian 9.2 has been hacked! Guide/Tutorial. Website. http://www.finestfones.com/2008/03/symbian-92-has-been-hacked.html. Accessed: 02.09.2008.
[33] Symbian Freak.
Mission Accomplished S60 3rd Edition FP1 hacked!!
Website. http://www.symbian-freak.com/news/008/03/s60_3rd_ed_feature_pack_1_has_
been_hacked.htm. Accessed: 02.09.2008.
[34] iPmart Forum. How to install ANY applications using platform hack! Website. http:
//www.ipmart-forum.com/showthread.php?t=247062. Accessed: 02.09.2008.
[35] Symbian Freak. ROMPatcher - S60 finally and truly open to anything! Website.
http://www.symbian-freak.com/downloads/freeware/cat_s60_3rd/descriptions/
systools/rompatcher_for_s60_3rd_ed_devices.htm. Accessed: 02.09.2008.
[36] Part-Time Phone Reviewer.
New hack available; E90, 6120c and N953 users rejoice!
Website.
http://www.finestfones.com/2008/05/
new-hack-available-e90-6120c-and-n95-3.html. Accessed: 02.09.2008.
[37] Part-Time Phone Reviewer. Nokia has blocked the hack in the E90. Website. http:
//www.finestfones.com/2008/05/nokia-has-blocked-hack-in-e90.html. Accessed:
02.09.2008.
[38] Orange SPV.
Website.
http://web.archive.org/web/20080129215346/http://
developer.orangews.com/orgspv/comdefq.aspx. Accessed: 07.09.2008.
[39] The Metasploit Blog. Cracking the iPhone (part 1) . Website. http://blog.metasploit.
com/2007/10/cracking-iphone-part-1.html. Accessed: 01.09.2008.
[40] AppSnapp Installer for 1.1.1. Website. http://jailbreakme.com/. Accessed:25.08.2008.
[41] Heise
online.
Apple-Chef
kündigt
Entwicklungsumgebung
für
iPhone
an.
Website.
http://www.heise.de/newsticker/
Apple-Chef-kuendigt-Entwicklungsumgebung-fuer-iPhone-an--/meldung/97556.
Accessed: 01.09.2008.
[42] Symbian Foundation.
03.09.2008.
Website.
http://www.symbianfoundation.org/. Accessed:
[43] Eclipse Foundation, Inc. Eclipse Public License - v 1.0. Website. http://www.eclipse.
org/legal/epl-v10.html. Accessed: 26.08.2008.
[44] Symbian. Symbian OS Version 9.4. Website. http://www.symbian.com/files/rx/
file9468.pdf. Accessed: 07.09.2008.
151
[45] Symbian Foundation. Symbian Foundation - Mobile software set free, Juni 2008. White
paper.
[46] RCR Wireless News. A conversation with Nokia’s Mary McDowell, chief development officer. Website. http://www.rcrwireless.com/apps/pbcs.dll/article?AID=
/20080703/SUB/290280005/1015/FREE. Accessed: 01.09.2008.
152

Diplomarbeit von Thomas Badura

Transcrição

Documentos relacionados

Prospekt Mobile Accessibility

Mobile Security - stefanus

Robla blackpowder solvent_en

COAB Lageplan - Coaching Oase Barbara Albisser

es spukt in bovert

tom wesselmann - Galerie Thomas

ALP4 jars unter Eclipse bearbeiten und erstellen

Checkliste: Anforderungen GUI-Testtool für Java und/oder - QF-Test

information in English

Wii Sicherheitskopien erstellen