Version 1.0, 10.09.2013
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. 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, damit für jedes benötigte Sicherheitsniveau ein eigener Schlüssel zur Verfügung steht.
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).
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. Der Absender würde für jede E-Mail (bzw. allgemeiner: jeden verschlüsselten, zusammenhängenden Datenblock) das geforderte Sicherheitsniveau (und Identitätsniveau) 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.
Die Normierung der Sicherheit eines Schlüssels allein reicht natürlich nicht aus. In ähnlicher Weise müsse eine Skala dafür geschaffen werden, wie gesichert die zu einem Schlüssel gehörende Identität ist. Man könnte diese beiden Skalen auch teilweise koppeln, weil es offensichtlich keinen Sinn ergäbe, höchste technische Sicherheit zu verlangen, wenn man nicht vergleichbar sicher ist, dass der Zielschlüssel überhaupt dem beabsichtigten Empfänger gehört.
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.
Eine ähnliche Skala bräuchte man dann auch noch für die Sicherheit der Korrektheit der Identität(sprüfung). 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.
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 |