Version 1.1, 14.05.2014
Es ist schwer genug, "normale Leute" davon zu überzeugen, dass es sinnvoll ist, Kryptografie zu verwenden. Noch schlimmer wird es, wenn man sie dazu bringen möchte, Kryptografie richtig einzusetzen – oder (unabhängig von Kryptografie) sich ein adäquates Niveau an IT-Sicherheit zuzulegen. Ein immens wichtiger Aspekt dabei ist, dass man den technischen und organisatorischen Aufwand and das Ausmaß der Bedrohung und den jeweiligen Schaden anpasst. Beides ist nicht einheitlich für die Gesamtmenge an Daten, mit denen jemand zu tun hat. Aus diesem Grund benötigt quasi jeder mehr als nur einen Schlüssel (für dieselbe (E-Mail-)Adresse), damit für mehrere Sicherheitsniveaus jeweils ein eigener Schlüssel zur Verfügung steht. Das Argument greift in beide Richtungen: Es geht nicht allein darum, die Sicherheit zu erhöhen, sondern auch darum, in entsprechenden Kontexten das Niveau senken zu können, ohne dass dies schlimme Folgen hat (weil es transparent ist und alle sich darauf einstellen können), weil dadurch die Verbreitung von Kryptografie gefördert werden kann.
Was technisch unmittelbar einsichtig ist, wird zum organisatorischen und infrastrukturellen Alptraum, wenn keine allgemein akzeptierte, gemeinsam verwendete Klassifizierung gibt. Dafür sollte mit der gebotenen Gründlichkeit – spätere erhebliche Änderungen wären kaum möglich – ein Vorschlag für eine solche Skala erarbeitet werden, der dann in wiederum standardisierter Weise in die Zertifikate geschrieben werden müsste (insbesondere auch im Web of Trust).
Ein Beispiel: Mit der Etablierung einer solchen Skala könnte eine Bank sagen: Wenn Sie Ihr Geld zurückhaben möchten, wenn beim Onlinebanking etwas "schiefgeht", dann müssen Sie dafür ein System der Schutzstufe 8 oder höher verwenden.
Mit dieser Angabe kann der Durchschnittsbürger wenig anfangen, aber er kann sich damit an Leute mit mehr Sachkenntnis – Kinder, Enkel, IT-Dienstleister – wenden und denen damit präzise vermitteln, was er braucht.
Eine sinnvolle Vorgehensweise wäre die Erarbeitung eines Konsens’ zwischen der Softwareindustrie, den wesentlichen Leuten auf der Open-Source-Seite und dem BSI. Im Rest der Welt ist noch weniger als in Deutschland zu erkennen, dass Kryptografie zu einem Massenphänomen wird. Entsprechend kleiner ist der Bedarf an einer schnellen Lösung dieses Problems im Ausland. Das lässt Aufwand und Nutzen einer internationalen Lösung in einem schlechten Verhältnis erscheinen. Die Probleme sind nicht länderspezifisch; eine qualitativ hochwertige Vorgabe aus Deutschland mit würde sicherlich übernommen, schon durch die Anpassung der verbreiteten Open-Source-Software.
Es würde sich nicht jeder für jede Sicherheitsstufe einen Schlüssel zulegen (schon weil man gar nicht die entsprechende Auswahl an Geräten hat und es nicht nötig ist, alle abzudecken). Der Absender würde für jede E-Mail (bzw. allgemeiner: jeden verschlüsselten, zusammenhängenden Datenblock) das geforderte Sicherheitsniveau festlegen. Seine Applikation würde dann für den Empfänger nach dem am wenigsten sicheren Schlüssel suchen, der mindestens dieses Niveau hat. Ab einem bestimmten Sicherheitsniveau ist es sinnlos, die Schlüssel an E-Mail-Adressen zu binden, weil diese Schlüssel sowieso nicht sinnvoll mit E-Mails verwendet werden können.
Man sollte bei verschlüsselten, aber nicht signierten Nachrichten ausdrücklich nicht davon ausgehen (d.h., die Applikation sollte eine entsprechende Warnung anzeigen), dass sie in einer Umgebung erzeugt wurden, die das Niveau des Empfängerschlüssels hat. Wenn der Empfänger keinen Schlüssel auf dem Niveau des Senders hat, kann der Sender gezwungen sein, für einen Schlüssel auf höherem Niveau zu verschlüsseln.
Eine ähnliche Skala bräuchte man dann auch noch für die Sicherheit der Korrektheit der Identität(sprüfung) (Authentizität). Für Unternehmen / Organisationen (also den Datenaustausch zwischen Unternehmen) mag es sinnvoll sein eine eigene solche Skala (oder eine Ergänzung zu dieser) zu entwickeln.
Es dürfte darauf hinauslaufen, dass der Authentizitätslevel immer mindestens so hoch sein muss wie der Sicherheitslevel.
Da die Sicherstellung der Authentizität zumeist der aufwendigste und am wenigsten verstandene Teil der Nutzung von Kryptografie ist, wäre Transparenz an dieser Stelle von großem praktischen Nutzen – weil dadurch ohne kritische Reduktion des Sicherheitsniveaus die Benutzerfreundlichkeit (Stichwort opportunistische Verschlüsselung) erhöht werden kann.
Bestandteil der Authentizitätslevel sollten auch Anforderungen an die Aktualisierung (Prüfung der Widerrufslisten) sein.
Das Sicherheitsniveau des Rechners sollte an einheitlicher Stelle hinterlegt sein. Applikationen sollten (für Signaturen und Entschlüsselung; bei Verschlüsselung lässt es sich womöglich nicht vermeiden) die Verwendung von Schlüsseln, die einem höheren Sicherheitslevel zugeordnet sind, als der Rechner es bietet, verweigern.
Wird das Sicherheitsniveau des Rechners nicht festgelegt, sollte dafür ein passabler Maximalwert angenommen werden (5 oder 6).
Für den User mag es eine erhebliche Vereinfachung sein, wenn er sich selber einschätzt. Wenn das System nicht von anderen für ihn eingerichtet wird, wird es typischerweise keine höhere Sicherheit bieten als die Kompetenz des Users hergibt. Dies wäre allerdings keine globale Einstellung, da es sinnvoll sein kann, einzelne Programme gezielt mit einem niedrigeren Wert zu konfigurieren.
Software mit Kryptofunktionen könnte bei der Installation abfragen, wie kompetent der User ist bzw. für welches Niveau er die Software eingerichtet haben will. In Abhängigkeit vom Ergebnis könnten dann viele Konfigurationsoptionen ausgeblendet werden, weil sie auf dem niedrigen Niveau irrelevant sind und diese Anwendergruppe nur stören / verwirren würden.
Daten könnten (z.B. über Dateiattribute oder entsprechende Datenbankeinträge) einem Schutzniveau zugeordnet werden, so dass Programme, die diese Daten importieren oder versenden, diese Information verwerten können – ein Spezialfall von DRM. Wenn ein Programm Daten importiert und daraus eine neue Datei erzeugt, dann wäre das automatisch gewählte Schutzniveau der neuen Datei das höchste der importierten Daten. Wenn Daten verschickt werden, würde die Applikation darauf achten, dass das für den Transport gewählte Schutzniveau mindestens dem der Daten entspricht. Man könnte auch eine Obergrenze für einzelne Applikationen festlegen, so dass das Betriebssystem verhindern könnte, dass Applikationen überhaupt auf Daten zugreifen, "denen sie nicht gewachsen sind".
Es wäre auch hilfreich, die Möglichkeit zu haben, Daten beim Versand entsprechend zu markieren. Wenn jemand Daten mit Schutzniveau 7 bekommt, aber die für ihn auf Schutzniveau 9 verschlüsselt werden, weil er nur Schlüssel für 3, 6 und 9 hat, dann sollten die Daten, solange er nichts anderweitiges festlegt, auf seinem System ebenfalls auf Schutzniveau 7 bearbeitet werden und nicht etwa auf 9, nur weil das zufällig das Niveau des Schlüssels ist.
Als Diskussionsgrundlage folgt ein Vorschlag für eine Einteilung. Es ist wohl nicht sinnvoll, jede kominatorische Abstufung zu berücksichtigen. Nicht jede einzelne Verbesserung muss einen auf ein höheres normiertes Sicherheitsniveau bringen. Wenn man die nächste Stufe erreichen will, ist es zumutbar, dass man mehrere Änderungen vornimmt. Wenn das Ergebnis für normale Nutzer zu kompliziert (kleinteilig) ist, ist es unbrauchbar. Die herausgehobenen Level sollten die "wichtigsten" sein, etwa verstanden als:
die häufigsten (oder jedenfalls häufige) Kombinationen
technisch sinnvolle Kombinationen (nicht viel Aufwand in einem Aspekt, aber wenig in einem anderen)
Es ist ein relativ großer Sprung in der Sicherheit von der nächstniedrigeren Kombination zu dem jeweiligen Level.
möglichst auch intuitiv verständlich (geringe Abweichung bei fehlendem Detailverständnis)
Es spricht aber nichts dagegen, alle Einzelwerte zu vermerken (in einer signature notation). Ein grundsätzliches Problem ist, dass die Realität mehrdimansional ist – sowohl auf dem Rechner zu Hause als auch auf dem diebstahlgefährdeten mobilen Gerät können Patches sofort oder mit erheblicher Verzögerung eingespielt werden –, man das aber kaum in so einer Skala berücksichtigen kann. Dass ein Rechner unter fremder Kontrolle steht, muss kein Problem sein, etwa dann, wenn man jemanden dienstlich kontaktiert.
Level | Stichwort | Softwaresicherheit | Kontrolle des Rechners | selber eingerichtet | Nutzer | physische Sicherheit | Daten diebstahlgeschützt | Einsatz | sauberes Bootmedium | Offline-System | vertrauenswürdiges OS | vertrauenswürdige Hardware | Extras |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | unsicher | ||||||||||||
2 | Internetcafé | niedrig | fremd | nein | Öffentlichkeit | niedrig | nein | alles | nein | nein | nein | nein | |
3 | ungesichertes mobiles Gerät | niedrig | selber | nein | nur selber | niedrig | nein | alles | nein | nein | nein | nein | |
4 | ungesicherter Heimrechner | niedrig | selber | nein | vertrauenswürdige Gruppe | normal | nein | alles | nein | nein | nein | nein | |
5 | Firmenrechner | normal | vertrauenswürdig | nein | begrenzte Gruppe | normal | nein | begrenzt | nein | nein | nein | nein | |
6 | gesichertes mobiles Gerät | hoch | selber | nein | nur selber | niedrig | ja | begrenzt | nein | nein | nein | nein | |
7 | gesicherter Heimrechner | hoch | selber | nein | nur selber | normal | nein | alles | nein | nein | nein | nein | |
8 | gehärteter Heimrechner | gehärtet | selber | ja | nur selber | normal | ja | begrenzt | nein | nein | nein | nein | |
9 | Zweitsystem für Sicherheitsaufgaben | gehärtet | selber | ja | engster Kreis | normal | ja | Whitelist | nein | nein | nein | nein | |
10 | sicher gebootetes Offlinesystem | maximal | selber | ja | nur selber | normal | ja | Whitelist | ja | ja | ja | nein |
Level | Beschreibung |
---|---|
niedrig | keine Vorkehrungen (oder unbekannt) |
normal | häufige Sicherheitsupdates für alle relevanten Programme |
hoch | häufige Sicherheitsupdates; aktueller Virenscanner |
gehärtet | Abkapselung der relevanten Software vom Restsystem (VM, SELinux usw.) |
maximal | Booten eines sicheren Offline-Systems vor dem Bearbeiten von Daten |
Level | Beschreibung |
---|---|
fremd | |
vertrauenswürdig | Arbeitgeber, Verein, Schule, Freunde, ... |
selber | Schlüsselbesitzer (bei privater Adresse) oder die Empfängerorganisation (bei nichtprivaten Adressen) |
Level | Beschreibung |
---|---|
Öffentlichkeit | große Gruppen |
begrenzte Gruppe | Kollegen |
vertrauenswürdige Gruppe | wenige, ausgesuchte Kollegen; Vereinsvorstand; Freunde |
engster Kreis | Familie; Lebenspartner; absolute Vertrauenspersonen |
nur selber |
Level | Beschreibung |
---|---|
niedrig | mobiles oder leicht zugängliches Gerät |
normal | stationärer Rechner in nichtöffentlichen Räumlichkeiten (Firma, Wohnung) |
hoch | gegen Einbruch erheblich gesicherte Räumlichkeiten |
maximal | permanent überwachte Räumlichkeiten |
Level | Beschreibung |
---|---|
alles | alles mögliche an Software installiert; Nutzung nicht eingeschränkt |
begrenzt | kontrollierte Softwareinstallation; Rechner wird überwiegend nur für wenige Dinge eingesetzt (z.B. Arbeits-PC) |
Whitelist | organisatorische oder sogar technische Begrenzung auf zulässige Operationen |