Security Engineering – A Guide to Building Dependable Distributed Systems

Originally shared by Kristian Köhntopp

Identifikation, Authentisierung, Autorisierung

Wenn ich mit einem Computersystem arbeite, dann tu ich das ja nicht direkt, sondern der Rechner repräsentiert mich intern mit einer Kennung, einer User-ID oder einem Namen. Ich bin etwa der User mit der UID 500 und dem Namen „kris“. Programme, die ich starte, laufen unter dieser Kennung und führen Operationen im System in meinem Auftrag aus.

Solche Identifier, Usernamen und User-IDs, müssen eindeutig sein, damit User voneinander unterscheidbar sind. Sie sind natürlich nicht global eindeutig – Du kannst auf Deinem System UID 500 haben und „kris“ heißen und ich auf meinem. Aber sie müssen innerhalb eines Namensraumes und einer Verwaltungseinheit (‚administrative domain‘) eindeutig sein.

Wenn mein Rechner alleine läuft und keine Medien mit anderen Rechnern tauscht, dann bin ich „hier“ halt kris und Du dort. Wenn wir beide aber unsere Rechner zusammenschalten und etwa ein gemeinsames Netzwerklaufwerk verwenden, dann sind wir beide Teil eines größeren Systems und müssen uns entscheiden, wer hier UID 500 und wer 501 hat und wer hier „kris“ und wer „kkoehntopp“ ist.

Solche Umbenennungen und Umnummerierungen sind häufig und problematisch, wann immer Verwaltungseinheiten zusammengelegt werden, etwa im Rahmen von Firmenaufkäufen, Systemvernetzungen und anderen Dingen, die Netze und Netzwerkstrukturen verändern.

Vielfach schreibt man dann auch nicht den unqualifizierten Usernamen („kris“), sondern den Namen der Verwaltungseinheit mit dazu – je nach System mit Punkten, Strichen oder @-Zeichen abgetrennt. Dann ist man halt KOEHNTOPP\KRIS und ANDEREFAMILIE\KRIS oder man ist kris@koehntopp.de und kris@anderefamilie.ch oder was immer die Konvention im verwendeten System ist.

Wenn ich mich bei einem System anmelde, dann tu ich das mit diesem Namen. Ich behaupte, kris zu sein. Das ist meine Identifikation.

Natürlich glaubt die Karre mir das nicht. Sie will, daß ich beweise kris zu sein. Das ist die Authentisierung. Ich muß also zeigen, daß ich der wahre, echte und reine Kris bin und nicht irgendein zweitklassiger Ersatz.

Das kann ich tun, indem ich ein Geheimnis weiß, daß ich und nur ich kenne – das Paßwort, die PIN, das Sesame-öffne-Dich, das Zauberwort. Das ist das übliche Login mit einem Paßwort.

Ich kann das auch tun, indem ich etwas habe und vorzeige, das nur ich habe und das schwer zu duplizieren ist. Das kann eine Chipkarte sein, oder etwa mein Haustürschlüssel.

Wenn ich den nicht dabei habe, dann komme ich bei mir daheim nicht rein: Ich muß mich an meiner Wohnungstür durch Besitz (und korrekten Gebrauch, Du Saufnase!) des Schlüssels authentisieren. Meine Wohnungstür unterscheidet dabei nicht zwischen verschiedenen Identitäten – meine Frau und ich haben identische Schlüssel und die Tür öffnet sich für jeden, der einen passenden Schlüssel hat.

Bei Türkarten an einer Uni ist das zum Beispiel anders – solche Schlüsselkarten sind alle unterschiedlich und die Tür hat eine Liste von ‚passenden‘ Schlüsseln für diese Tür. Jede Tür kann eine andere Liste von Schlüsseln haben, die ‚passen‘.

Eine weitere Möglichkeit zu beweisen wer man ist, wäre die Eigenschaften von mir zu messen und mich an meinem blenden Aussehen, meinen strahlenden Augen, den markanten Linien meines Kinns oder meiner Fingerkuppen zu erkennen oder andere einmalige Eigenschaften von mir zu wissen und mich daran zu erkennen und von anderen, billigen Imitationen von mir zu unterschieden.

Damit haben wir unterschiedliche Faktoren zur Authentisierung – durch geheimes Wissen, durch Besitz schwer fälschbarer Dinge und durch bestimmtes, einmaliges Sein.

Wenn ich mich bei einem Rechner durch Behauptung („Ich bin kris!“) und Beweis („Das geheime Paßwort heißt ‚Flipperwaldt gersput‘!“) anmelde, dann ist das eine Einfaktor-Authentisierung. Brauche ich außerdem noch zusätzlich einen bestimmten Plug-up-FIDO-U2F-U2F-SK-01-Security, dem ich dem Rechner reinstecke, dann ist das eine Zweifaktor-Authentisierung.

Das ist eine feine Sache, weil sie verhindert, daß jemand anders mit Kenntnis meines Paßwortes einfach meinen Account übernehmen kann. Stattdessen bräuchte ein Angreifer mein Paßwort und müßte mir den Fido-Key stehlen. Das ist insbesondere für einen physisch nicht anwesenden Angreifer sehr schwer, das heißt, solche Zweifaktor-Authentisierung wendet sich insbesondere gegen https://de.wikipedia.org/wiki/Phishing.

Wenn Ihr Google-Dingsi verwendet und noch keinen solchen Fido-Key habt, pausiert ihr hier mal mit dem Lesen und kauft eben schnell so einen. Das Ding ist spottbillig und verhindert sehr sicher, daß Euch der Account abgephisht wird. Ich warte mit dem Text hier solange auf Euch.

Hier ist noch einmal die URL: https://www.amazon.de/Plug-up-FIDO-U2F-U2F-SK-01-Security/dp/B00OGPO3ZS

Wieder da? Gut.

Wenn ich jetzt also behauptet habe, kris zu sein und mir die Möhre das endlich glaubt, dann muß sie sich entscheiden, was ihr das Wert ist. Also, wo darf kris ran und was darf kris machen – das ist meine Autorisierung.

Solche Berechtigungen, die kris hat, kann man nett in Dreiergruppen notieren, also als Sätze mit einem Subjekt, einem Verb und einem Objekt. Da heißt es dann, „kris (subjekt) darf ~/notizen.txt (objekt) vi’en (Verb, ‚mit dem Editor vi bearbeiten‘)“, oder kürzer (kris, vi, ~/notizen.txt). Wir lernen: Subjekte sind immer User-Identitäten, Objekte sind Dinge im Rechner, meist Files, auf die zugegriffen wird und Verben sind Programme, mit denen der Zugriff erfolgt.

In den meisten Fällen ist das Verb ein Wildcard, also ‚mit jedem beliebigen Programm‘. „Kris darf mit ~/notizen.txt machen was immer er will“. Manchmal ist das nicht der Fall. Ich darf zum Beispiel mein Userpasswort in /etc/shadow nicht mit vi ändern, denn ich darf als kris /etc/shadow weder lesen noch schreiben. Aber ich kann das Paßwort darin mit dem Programm passwd ändern.

Es ist also (kris, *, ~/notizen.txt), aber es ist nur (kris, /bin/passwd, /etc/shadow). Und es ist dann so, daß /bin/passwd durch nur das Paßwort von kris ändern wird, wenn ich, kris, das Programm aufrufe, aber nicht das Paßwort von anderen Usern. Dumm gelaufen, denn mit vi könnte ich in der Shadow-Datei nach belieben rum treckern und auch Dein Paßwort ändern.

Ich kann die Rechte, die kris hat, jetzt entweder am Objekt notieren, dann sind das Permissions. An der Datei ~/notizen.txt steht dann halt „kris darf die lesen und schreiben und sonst keiner“ und an der Türsteuerung jedes Schlosses steht eine Liste von Schlüsselcodes, die die Tür öffnen (auf der Schlüsselkarte steht nur eine Türkarten-Nummer, eine Identität).

Oder ich kann solche Dinge am User notieren, dann sind es Capabilities. Am User steht dann halt dran „kris darf die folgenden Dateien lesen: $LISTE“ (so eine C2-Security Extension für OS/2 hat das mal so herum aufgezogen) oder auf der Schlüsselkarte steht signiert und unfälschbar hinterlegt eine Liste der Türen-Nummern, also Objektidentitäten, durch die Kris durchgehen darf. An der Tür muß nichts hinterlegt sein außer dem Root-Cert der Signatur, damit die Daten auf der Karte geprüft werden können.

„Da will ich mehr drüber lernen“ Guckst Du hier: https://www.cl.cam.ac.uk/~rja14/book.html Die Second Edition. Das ist spannend, lehrreich und gut geschrieben, was bei diesem Thema in dieser Combo eher selten ist.

Security Engineering – A Guide to Building Dependable Distributed Systems