Schlüsseltechnologie

By Xyrillian NoisesTechnology

Schlüsseltechnologie episodes

December 21, 2023STP048: Vertrauen
Nach Xyrills gewaltigem humorischen Auftakt kommen wir zu wirklich wichtigen Dingen: Wem kann vertraut werden und warum? Hat Vertrauen ein Haltbarkeitsdatum? Wem vertraue ich, ohne explizit davon zu wissen? Zum Schluss gibt es noch Aufklärung über die Herkunft des Wortes Spam für unerwünschte Werbung.
Shownotes
Rückbezug zu STP039: Authentifizierung ("Wer ist diese Person?" bzw "Was darf diese Person?")
Problem: Woher weiß man, ob ein Identitätsnachweis verlässlich ist? -> Vertrauen
Vorstellung verschiedener Arten von Vertrauensvermittlung -> Ziel: Vokabular aufbauen, Methoden gegeneinander abwägen
Beispiele im realen Leben: gemeinsame Vorgeschichte und Inside-Jokes, Geheimlosungen, Personalausweise
Vererbung von Vertrauen: Digitale Zertifikate nach dem X.509-Standard
basierend auf asymmetrischer Verschlüsselung (siehe STP043)
Zertifikat = öffentlicher Schlüssel + Identitätsinformationen + Signatur durch ein übergeordnetes Zertifikat
durch die Signaturkette geht Vertrauen vom Anfang der Kette (Zertifikatsautorität, CA) auf die abgeleiteten Zertifikate über
authentifizierende Systeme müssen nur das allererste Zertifikat in der Kette kennen (das Wurzel-Zertifikat bzw. Root-CA)
Beispiel: Wurzelzertifikat signiert Zertifikat einer unterliegenden CA, und dieses signiert ein Zertifikat für einen Nutzer
Einsatzfälle
Transportverschlüsselung im Web (HTTPS, Zertifikat enthält Domain-Namen)
Impfzertifikate in der Corona-Warn-App
Benutzerseitige Zertifikate im Firmen-Intranet oder bei Elster
Äquivalente in der realen Welt: Personalausweis oder Reisepass (ausgestellt durch eine Regierungsstelle), Zugangskarte in der Firma (ausgestellt durch die Liegenschaftsverwaltung der Firma), Mitarbeiteruniform (eine Person in DB-Uniform auf einem Bahnhof wird wahrscheinlich ein DB-Mitarbeiter sein)
Vorteile: skaliert sehr gut auf viele Akteure, nur relativ wenig Speicher notwendig (für die Root-CAs)
Nachteil: erfordert Vertrauen in eine zentrale Stelle
Vertrauen durch Beständigkeit: Trust on first use (TOFU)
beim ersten Kontakt mit einer Person wird deren öffentlichen Schlüssel blind vertraut
bei weiteren Kontakten wird demselben Schlüssel weiterhin vertraut, aber die Präsentation eines neuen Schlüssels wird als Angriffsversuch bzw. Betrugsversuch gewertet
Einsatzfälle
die meisten Messenger mit Ende-zu-Ende-Verschlüsselung (z.B. Signal, WhatsApp, verschlüsselte Chats in Telegram)
Fernzugriff auf Server mittels SSH (für den Teil, wo die Identität des Servers überprüft wird)
Äquivalente in der realen Welt: Bekanntschaften unter Nachbarn oder Vereinsmitgliedern (alles, was auf der Basis von "den kenn ich" läuft)
Vorteil: braucht keinen zentralen Vertrauensanker
Nachteil: anfällig gegen Attacken beim initialen Verbindungsaufbau
Vertrauen durch Vitamin B: Web of Trust (WoT)
Zertifikate ähnlich wie bei X.509: öffentlicher Schlüssel + Identitätsinformatione + Liste von Signaturen
Signaturen nicht vertikal (in einer Hierarchie), sondern horizontal (zwischen gleichrangigen Zertifikaten verschiedener Nutzer)
Vertrauen vererbt sich zwischen Nutzern:
unendliches Vertrauen in das eigene Zertifikat
hohes Vertrauen in Zertifikate, die man selbst signiert hat
mittelhohes Vertrauen in Zertifikate, die von diesen Zertifikaten signiert wurden
und so weiter
Einsatzfälle
E-Mail-Verschlüsselung mit PGP/GPG, siehe auch Keysigning-Parties
Verifikation eines Chat-Kontakts über einen Seitenkanal
Äquivalent in der realen Welt: Bekanntschaften über Bande ("der Freund der Freundin des Schwippschwagers")
Vorteil: braucht keinen zentralen Vertrauensanker
Nachteil: Schlüssel mit vielen Signaturen sind eigentlich wertvoll, aber auch unhandlich; Angriff möglich durch bösartige Müll-Signaturen
Seitenleiste: Wie könnte man solchen Signatur-Spam verhindern?
Problem: Spam (sowohl bei E-Mails als auch GPG-Signaturen) ist für den Versender sehr günstig und für den Empfänger extrem lästig -> Kann man den Spieß umdrehen?
Idee (1990er): wir nutzen Einwegfunktionen (Streuwertfunktionen siehe STP004, STP043), aber drehen die Sache um
Sender muss einen Datensatz bilden, für den eine Streuwertfunktion ein Ergebnis mit X führenden Nullen hat (X kann variiert werden je nach Leistungsfähigkeit aktueller Prozessoren) -> erfordert sehr viel Durchprobieren von Eingabewerten
Empfänger muss nur schauen, dass die Lösung stimmt -> erfordert nur eine Berechnung mit dem präsentierten Eingabewert
Implementation (2002): Hashcash als eines der ersten Proof-of-Work-Verfahren
Vertrauen durch Proof of Work: Blockchain
Kombination von Proof of Work mit Merkle-Bäumen
Merkle-Baum = Baumstruktur aus Datenpaketen, die jeweils die Hash-Werte ihrer untergeordneten Knoten enthalten -> Hash-Wert des Wurzelknotens ist die einzige benötigte Information, um die Integrität des gesamten Baumes zu überprüfen
Blockchain: System zur kontinuierlichen Erweiterung eines Merkle-Baums (genauer: einer Merkle-Kette) um neue Blöcke, aber die Hashes jedes Blocks müssen eine Proof-of-Work-Bedingung erfüllen
kein Vertrauen in einzelne Akteure notwendig, nur in die Sicherheit des Algorithmus
Abendgedanken: Vertrauen lässt sich nicht eliminieren, nur verschieben
Vertraue ich einem Menschen? Einer Maschine? Einer Organisation? Einem Algorithmus?
Niemandem vertrauen ist auch keine Lösung.
im Gespräch erwähnt
Versionsverwaltungssystem "git", wie von uns besprochen im Pentaradio vom Juli 2021
1 hr 20 min
November 30, 2023STP047: Speicherallokation
Ein weiteres Mal beschäftigen wir uns mit Speicher. Diesmal spezifisch mit Haufen davon. Wie man die wieder wegräumt oder gar nicht erst zu groß werden lässt, ist auch ein Thema. Außerdem gibt es ein Novum direkt am Beginn der Folge.
Shownotes
Rückbezug auf STP045: Heap (Haufenspeicher)
keine Strukturvorgaben durch das Betriebssystem oder die Prozessorarchitektur
notwendig für Daten, deren Lebenszeit nicht der Struktur von Unterprogrammen folgt, oder deren Größe die 132 KiB des Stacks übersteigt
neue Frage: Wie kann man diesen unstrukturierten Haufen sinnvoll verwalten?
Analogie: Ein Team verwendet als Speicher ein großes Whiteboard, auf dem verschiedene Mitglieder des Teams rumschreiben wollen, ohne sich gegenseitig in die Quere zu kommen.
man braucht einen Allokator
meist in Form einer Programmbibliothek, die auf die jeweilige Programmiersprache und/oder Laufzeitumgebung abgestimmt ist
klassischerweise zwei Funktionen: "malloc" ("memory allocate"; ich brauche ein Stück Speicher der Größe X) und "free" (das gegebene Stück Speicher brauche ich nicht mehr)
Allokationen mittels malloc sind meist sehr viel kleiner als die Speicherseiten, die das Betriebssystem rausgibt (min. 4 KB) -> Allokator holt sich ganze Speicherseiten und zerteilt die in mundgerechte Stücke
damit "free" funktioniert, muss der Allokator irgendwo über diese Zerstückelung Buch führen -> gewisser Mehraufwand an Speicher für die Buchführung
verschiedene Anwendungen machen ihre Speicherallokationen in unterschiedlichen Mustern (häufig z.B. ein gewisser Bodensatz an großen Allokationen, die für die ganze Lebensdauer des Programms erhalten bleiben, und dazu sehr viele kleine und kurzlebige Allokationen für bestimmte Einzeloperationen) -> interessantes Arbeits- und Forschungsfeld für Leute, die sich gern in Algorithmen eingraben
Speicherverwaltung im Heap ist sicherheitskritisch -> mögliche Fehlerquellen
Speicherleck: Speicher wird allokiert, aber dann nicht wieder freigegeben; da der Allokator nicht wissen kann, ob der Speicher noch verwendet wird, muss er brachliegen
Pufferüberlauf: Allokation war für X Bytes, aber dann wird über das Ende (Basisadresse + X) hinausgeschrieben; dies zerstört dann Daten in anderen Allokationen oder Buchführungsdaten des Allokators
Use after free: Allokation wird mit "free" zurückgegeben, aber danach noch vom Programm verwendet, obwohl der Allokator dieses Stück Speicher vielleicht schon wieder anderweitig allokiert hat
Das klingt alles anstrengend. Kann man das nicht den Computer machen lassen? -> automatische Speicherverwaltung
einfachste praktikable Idee: Referenzen zählen
Ansatz: bei allokiertem Speicher nicht die lose Speicheradresse herumreichen, sondern noch einen Zähler mitführen
Zähler beginnt bei 1, da man am Anfang eine Referenz hat
bei jedem Kopieren der Referenz wird der Zähler um 1 erhöht, bei jedem Löschen einer Referenz um 1 verringert
die Allokation wird freigegeben, wenn der Zähler auf 0 fällt
Vorteil: sehr schnell, sehr zuverlässig, eliminiert bei konsequenter Anwendung das Risiko von "Use after free"
Nachteil: garantierte Speicherlecks bei zyklischen Referenzen (z.B. A verweist auf B verweist auf C verweist auf A, aber nichts anderes verweist auf A/B/C)
komplexere Formen von automatische Speicherverwaltung mit Zykluserkennung heißen meist Garbage Collector (GC, "Müllsammler"); strenggenommen sind Referenzzähler "konservative GC"
Beispiel für einen GC-Algorithmus: Mark and Sweep
aktives Aufräumen zu bestimmten Gelegenheiten, z.B. wenn bei malloc kein Speicher mehr frei ist und weiterer Speicher vom Betriebssystem angefordert werden müsste
Algorithmus:
Allokationen, deren Adressen im Stack liegen, werden als "erreichbar" markiert
alle anderen Allokationen werden initial als "nicht erreichbar" markiert
ausgehend von den erreichbaren Allokationen wird sukzessive nach Verweisen auf andere Allokationen gesucht und diese ebenfalls als "erreichbar" markiert
nachdem alles durchsucht wurde, werden alle Allokationen freigegeben, die immer noch als "nicht erreichbar" markiert sind
GC braucht meist eine enge Integration mit dem Allokator und mit der Programmiersprache oder der Laufzeitumgebung (z.B. insb. um die Frage "welche Allokationen sind im Stack referenziert" zu beantworten)
Nachteil: fast jeder GC muss zumindest für einen Teil der Aufräumphase "die Welt anhalten", was für den Nutzer wie Motorstottern aussieht
Optimierung der Heap-Nutzung: Anzahl der Allokationen verringern (es gilt die Faustregel "der einzige Weg, zu optimieren, ist, weniger zu tun")
zusammenhängende Datenstrukturen möglichst in eine einzelne Allokation ablegen anstatt in mehrere Teilstücke ("Arena-Allokation", "Small Object Allocation")
kleine Daten bevorzugt im Stack halten und nicht auf den Heap legen (Xyrill hat eine Anekdote zu Minecraft)
noch eine Idee: GC zu opportunen Momenten explizit anstarten (z.B. bei Spielen während des VSync, d.h. wenn ein Einzelbild gerade fertig ist und es auf den Bildschirm kopiert wird)
zum Schluss ein Blick auf ein Teilgebiet der Heap-Algorithmen: Zwischenspeicher (Cache)
Grundproblem: bestimmte Operationen sind teuer (z.B. Netzwerkabfragen, Einlesen von Dateien von der Festplatte, komplexe Berechnungen), aber reproduzierbar; wir würden die Ergebnisse gerne wiederverwenden, aber können nicht alle im Speicher halten
Speicherstück mit einer festen Größe wird als Cache designiert
idealerweise würde man genau die Ergebnisse dort ablegen, die in der Zukunft am häufigsten wieder nachgefragt werden
Problem: "Vorhersagen sind schwierig, insbesondere, wenn sie die Zukunft betreffen" -> Cache-Replacement-Algorithmen sind ein Forschungsfeld
Beispiel LRU ("Least Recently Used"): wenn ein neues Element abgelegt wird, wird dasjenige existierende Element überschrieben, das am längsten ungenutzt ist
Lesestoff: www.memorymanagement.org (englisch)
1 hr 9 min
November 09, 2023STP046: Bram Moolenaar und vim
Obwohl dies ein Technikpodcast ist, kommen wir um politische Themen oft nicht ganz herum. In dieser Folge jedoch stellen wir uns nun direkt ins Feuer. Und all das nur, weil Xyrill unbedingt seinen Lieblingseditor unters Volk bringen will.
ShownotesAus aktuellem Anlass: Anfang August 2023 ist Bram Moolenaar gestorben.
Bram Moolenaar
Jahrgang 1961, bis 1985 Studium der Elektrotechnik in Delft mit Abschlussarbeit zu Multiprozessor-Unix-Architektur
seit 1988 Entwicklung eines Klons des Texteditors vi mit dem Namen vim (erst "vi imitation", später "vi improved"; "vim" kann aber auch "Elan" bedeuten)
bis kurz vor seinem Tod (d.h. 35 Jahre) Leitung des vim-Projektes in seiner Freizeit (neben der Arbeit u.a. bei Google)
außerdem Engagement für die NGO ICCF Holland, die Waisenkinder in Uganda unterstützt
in diesem Zusammenhang: Was ist eigentlich vim? Und warum verbringt Xyrill sein halbes Leben darin? (Spoiler: man kann alle intellektuelle Arbeit als Texteditieren darstellen; siehe auch STP006)
frühe 1970er-Jahre: ed – der erste Unix-Texteditor; damals hatten Unix-Computer noch keinen Bildschirm, sondern nur Tastatur und Drucker
1976: ex – eine von vielen Weiterentwicklungen von ed mit zusätzlichen Funktionen
darin enthalten: ein neuartiger "visual mode", der 1979 der Standard wurde – vi ist geboren
1989 dann vim als Weiterentwicklung von Brams Portierung von vi auf Atari-Computer
sprich: im Großen und Ganzen eine 50 Jahre lang ungebrochene Evolutionslinie von Texteditoren, analog und parallel zu Unix
Kernidee von vi-artigen Texteditoren: modales Editieren
in herkömmlichen Texteditoren: jeder Tastendruck hat immer die gleiche Bedeutung (z.B. "u" fügt ein kleines U ein; z.B. "Strg+Z" macht die letzte Operation rückgängig)
Nachteil: komplexe Operationen sind begrenzt darin, wieviele Tastenkombinationen man sich merken kann
in vi-artigen Editoren: Bedeutung eines Tastendrucks hängt vom aktuellen Modus ab (z.B. "u" im Eingabemodus fügt ein kleines U ein, jedoch "u" im Befehlsmodus macht die letzte Operation rückgängig)
erster Vorteil: mehr Befehle sind durch einfache Tastendrücke erreichbar, die sich einfacher tippen lassen als Akkorde wie "Strg+Umschalt+R"
zweite Besonderheit: Aktionsgrammatik
in herkömmlichen Texteditoren: viele Aktionen, die alle ziemlich ähnlich sind (z.B. ein Zeichen nach links löschen, ein Wort nach links löschen, ein Zeichen nach links auswählen, ein Wort nach links auswählen, etc.)
Befehlsmodus in vi: Befehle werden wie mit einer Grammatik zusammengesetzt
Substantive = Bewegungen (z.B. "w" = ein Wort nach rechts, "b" = ein Wort nach links, "j" = eine Zeile nach unten)
Zahlen = Vervielfältigungen (z.b. "3w" = drei Worte nach rechts, "5j" = fünf Zeilen nach unten)
Verben = Aktionen (z.B. "d" = löschen, "c" = ändern)
ganzer Befehl: nur eine Bewegung (bewegt den Cursor, z.B. "3w") oder eine Aktion und eine Bewegung (z.B. "d5j")
damit zweiter Vorteil: eine große Menge an komplexen Aktionen ist mit sehr kompakten Befehlen auszudrücken (z.B. "Ich möchte den Inhalt des Klammerpaars löschen, in dem mein Cursor steht" = "di(", "ich möchte diesen Absatz und die nächsten drei Absätze automatisch formattieren" = "ga4p")
weitere coole Funktionen in vim
Makrofunktion: Folgen von Tastendrücken können aufgezeichnet und dann automatisiert abgespielt werden (gibt's auch in anderen Editoren, aber paart sich mit vi's Befehlssprache besser als mit denen der meisten anderen Texteditoren)
man kann damit Hacker Jeopardy gewinnen :3
Kann man das lernen?
Ja, auf jeden Fall. Was man da an Zeit aufwendet, zahlt sich dann über Jahrzehnte aus.
Xyrill empfiehlt: Erstmal nur mit den Basics anfangen (Dateien öffnen und schließen, zwischen Modi wechseln). Dann schrittweise Befehle lernen, wann immer man das Gefühl hat, dass man was von Hand macht, was auch einfacher gehen sollte.
vim hat ein eingebautes Tutorial: vimtutor auf der Kommandozeile ausführen
vim-Cheatsheet auf dem Schreibtisch bereitlegen (Beispiel (deutsch), Beispiel (englisch))
im Gespräch erwähnt
Perl-Programm mit Spracherkennung schreiben
Pentaradio zu Git (Versionsverwaltungssystem)
1 hr 5 min
October 19, 2023STP045: Speicherstruktur aus Programmsicht
In dieser Ausgabe greifen wir ein altes Thema erneut auf, bei dem ttimeless trotzdem stellenweise nur schwer folgen kann. Denn durch Wiederholung lernt man. Denn durch Wiederholung lernt man.
Shownotes
Rückblick: wir hatten schon einige Folgen zu Speicherverwaltung
STP007: Speicherhierarchie (Festplatte und SSD, Arbeitsspeicher/RAM, Prozessor-Cache, Registerbank)
STP019: Speicherschutz (virtueller Speicher, Auslagerungsspeicher/Swap, Direct Memory Access)
Nachtrag/Linktipp: https://www.linuxatemyram.com
das war alles aus Sicht des Betriebssystems; diesmal Abläufe innerhalb des Prozesses
Was stellt uns das Betriebssystem bereit? -> Virtueller Speicher
nominale Größe: entsprechend der Adressbreite des Prozessors (für 32 Bit sind das 2^32 Bytes = 4 GiB, für 64 Bit sind es 2^64 Bytes = 16 EiB = 16.777.216 TiB)
nutzbar aber nur dort, wo das Betriebssystem für uns eine tatsächlich existierende Speicherseite einblendet
initiale Belegung (siehe Beispiel unten): hauptsächlich Programmdatei und benötigte Programmbibliotheken mit ihren entsprechenden Segmenten
Belegung (und Rückgabe) weiterer Speichersegmente mittels Syscalls (siehe STP019)
klassische Struktur des virtuellen Speichers: oben der Stapel, unten ein Haufen
vorher einige Bemerkungen zu klassischen Schutzmaßnahmen, die man im untenstehenden Beispiel sehen kann
die untersten paar KiB des Adressbereiches werden nie vergeben
dies verhindert versehentlichen Zugriff auf Nullzeiger mit hoher Wahrscheinlichkeit
Address Space Layout Randomization (ASLR): Programmdateien und Programmbibliotheken werden an zufällig gewählten Speicheradressen eingeblendet, um es Angreifern zu erschweren, das Programm so zu manipulieren, dass es ungeplant in deren Code hineinspringt
klingt nach einer einfach umsetzbaren Schutzmaßnahme
war aber lange nicht weit verbreitet, weil der benötigte Position Independent Code (PIC) mit einem kleinen Geschwindigkeitsverlust (1-3%) einhergeht
oberer Teil (d.h. bei hohen Adressen): Stack (Stapelspeicher)
Programme sind meist als ineinander verschachtelte Unterprogramme (Subroutinen) aufgebaut (siehe STP011)
Daten, die nur für die Dauer des jeweiligen Unterprogramms gebraucht werden, können im Stack aufgestapelt werden
Idee: Hauptroutine kriegt den ganzen Stack und knapst sich oben soviel ab, wie es selber braucht
nächste Unterroutine kriegt den Rest des Stacks und verfährt in derselben Weise
wenn die Unterroutine zurückkehrt, kann der von ihr benutzte Stack an die nächste Unterroutine weitergereicht werden -> keine aufwändige Speicherverwaltung nötig
bei Prozessen mit mehreren Threads (parallel lauffähigen Teilprozessen) teilen sich alle Threads grundsätzlich denselben virtuellen Speicher, aber kriegen jeweils eigene Stacks
Stack ist vom Betriebssystem in einer festen Größe angelegt (im Beispiel unten 132 KiB) – bei zu vielen verschachtelten Subroutinen-Aufrufen kommt es zum berüchtigten Stack Overflow
unterer Teil (d.h. bei tiefen Adressen): Heap (Haufenspeicher)
keine Strukturvorgaben durch das Betriebssystem oder die Prozessorarchitektur
notwendig für Daten, deren Lebenszeit nicht der Struktur von Unterprogrammen folgt, oder deren Größe die 132 KiB des Stacks übersteigt
neue Frage: Wie kann man diesen unstrukturierten Haufen sinnvoll verwalten? -> Teil 2 folgt in STP047
Randnotiz zu unserem Beispiel unten: Was sind vvar, vdso und vsyscall?
Syscalls sind zeitaufwändig (in der Größenordnung von dutzenden Mikrosekunden), da man vom Prozess in den Kernel umschalten muss und wieder zurück
Idee: manche Syscalls kann der Kernel mit geschickter Planung im Prozess selbst beantworten, ohne Kontextwechsel
Beispiel: gettimeofday (Abfrage der aktuellen Uhrzeit) kann man aus einem vorhergehenden Datenpunkt des Kernels anhand des Taktzählers des Prozessors fortschreiben (z.B. TSC auf x86)
vsyscall: erste derartige Implementation, mit zwei großen Problemen (Platzbegrenzung, kein PIC = kein ASLR); nur aus Kompatibilitätsgründen angeboten
vDSO ("virtual dynamic shared object"): die aktuelle Implementation, verhält sich wie eine dynamisch nachgeladene Programmbibliothek
vvar: Datensegment für das vDSO
$ sleep 30 &
[1] 4970
$ cat /proc/$(pidof sleep)/maps
# address perms offset dev inode pathname
556ac29f4000-556ac29f6000 r--p 00000000 fe:00 10234368 /usr/bin/sleep
556ac29f6000-556ac29f9000 r-xp 00002000 fe:00 10234368 /usr/bin/sleep
556ac29f9000-556ac29fa000 r--p 00005000 fe:00 10234368 /usr/bin/sleep
556ac29fa000-556ac29fb000 r--p 00006000 fe:00 10234368 /usr/bin/sleep
556ac29fb000-556ac29fc000 rw-p 00007000 fe:00 10234368 /usr/bin/sleep
556ac2f81000-556ac2fa2000 rw-p 00000000 00:00 0 [heap]
7fe4dea00000-7fe4ded42000 r--p 00000000 fe:00 10321904 /usr/lib/locale/locale-archive
7fe4deefc000-7fe4deeff000 rw-p 00000000 00:00 0
7fe4deeff000-7fe4def21000 r--p 00000000 fe:00 10226583 /usr/lib/libc.so.6
7fe4def21000-7fe4df07e000 r-xp 00022000 fe:00 10226583 /usr/lib/libc.so.6
7fe4df07e000-7fe4df0d6000 r--p 0017f000 fe:00 10226583 /usr/lib/libc.so.6
7fe4df0d6000-7fe4df0da000 r--p 001d6000 fe:00 10226583 /usr/lib/libc.so.6
7fe4df0da000-7fe4df0dc000 rw-p 001da000 fe:00 10226583 /usr/lib/libc.so.6
7fe4df0dc000-7fe4df0eb000 rw-p 00000000 00:00 0
7fe4df11e000-7fe4df11f000 r--p 00000000 fe:00 10226556 /usr/lib/ld-linux-x86-64.so.2
7fe4df11f000-7fe4df145000 r-xp 00001000 fe:00 10226556 /usr/lib/ld-linux-x86-64.so.2
7fe4df145000-7fe4df14f000 r--p 00027000 fe:00 10226556 /usr/lib/ld-linux-x86-64.so.2
7fe4df14f000-7fe4df151000 r--p 00031000 fe:00 10226556 /usr/lib/ld-linux-x86-64.so.2
7fe4df151000-7fe4df153000 rw-p 00033000 fe:00 10226556 /usr/lib/ld-linux-x86-64.so.2
7ffe3da15000-7ffe3da36000 rw-p 00000000 00:00 0 [stack]
7ffe3da73000-7ffe3da77000 r--p 00000000 00:00 0 [vvar]
7ffe3da77000-7ffe3da79000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Randbemerkungen: Sofern ich die Ausgabe von strace sleep 30 richtig lese, wurde [heap] hier mit brk verwaltet. Die beiden anonymen Segmente gehen höchstwahrscheinlich auf das Konto des Laufzeit-Linkers (hier ld-linux-x86-64.so.2), der die Programmbibliotheken (hier nur libc.so.6) in den Prozess lädt.
Um das zu bestätigen, habe ich dann mal schnell ein minimales Programm gebaut, dass ausschließlich sleep gefolgt von exit macht, und definitiv gar nichts anderes. Ich war in der Tat erfolgreich:
$ strace ./target/release/minimal-memory-maps
execve("./target/release/minimal-memory-maps", ["./target/release/minimal-memory-"...], 0x7ffd0c104b00 /* 67 vars */) = 0
nanosleep({tv_sec=10, tv_nsec=0}, 0x7ffdaa084800) = 0
exit(0) = ?
+++ exited with 0 +++
Und dieses Programm hat nicht mal einen Heap, sondern nur den Stack und die Kernel-Schnittstellen:
$ cat /proc/$(pidof minimal-memory-maps)/maps
# address perms offset dev inode pathname
00400000-00401000 rwxp 00000000 fe:00 9309336 .../target/release/minimal-memory-maps
7ffdaa066000-7ffdaa087000 rw-p 00000000 00:00 0 [stack]
7ffdaa0ea000-7ffdaa0ee000 r--p 00000000 00:00 0 [vvar]
7ffdaa0ee000-7ffdaa0f0000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Hier sieht man übrigens schön, dass ich mein Programm nicht mit PIC kompiliert habe, sodass für die Programmdatei selber keine ASLR vorgenommen werden konnte.
Der Vollständigkeit halber dokumentiere ich hier noch den Code, um mein Testprogramm zu reproduzieren. Der Code funktioniert nur auf Linux und x86-64. Und selbst da habe ich irgendwas nicht ganz richtig gemacht: Das Programm funktioniert nur, wenn man dem Compiler Optimierungen verbietet (?!?). Trotzdem ein Shoutout an diesen Blogartikel und diesen anderen Blogartikel, mit deren Hilfe ich das Kompilieren ohne libc und main zumindest hinreichend weit ans Laufen bekommen habe.
$ cat Makefile
build:
RUSTFLAGS="-Copt-level=0 -Ctarget-cpu=native -Clink-args=-nostartfiles -Clink-args=-Wl,-n,-N,--no-dynamic-linker" cargo build --release
$ cat Cargo.toml
[package]
name = "minimal-memory-maps"
version = "0.1.0"
edition = "2021"
[profile.dev]
panic = "abort"
[profile.release]
panic = "abort"
$ cat src/main.rs
#![no_std]
#![no_main]
use core::arch::asm;
#[repr(C)]
struct Timespec {
pub tv_sec: i64,
pub tv_nsec: i64,
}
const NR_NANOSLEEP: usize = 35;
const NR_EXIT: usize = 60;
#[no_mangle]
pub extern "C" fn _start() -> ! {
let req = Timespec { tv_sec: 10, tv_nsec: 0 };
let mut resp = Timespec { tv_sec: 0, tv_nsec: 0 };
unsafe {
// nanosleep(&req, &mut resp)
let req_ptr = (&req as *const Timespec) as usize;
let resp_ptr = (&mut resp as *mut Timespec) as usize;
let ret: usize;
asm!(
"syscall",
inout("rax") NR_NANOSLEEP => ret,
in("rdi") req_ptr,
in("rsi") resp_ptr,
out("rcx") _,
out("r11") _,
);
let exit_code = if ret == 0 { 0 } else { 1 };
// exit(0)
asm!(
"syscall",
in("rax") NR_EXIT,
in("rdi") exit_code,
options(noreturn)
)
}
}
#[panic_handler]
fn my_panic(_info: &core::panic::PanicInfo) -> ! {
loop {}
}
1 hr 11 min
September 28, 2023STP044: Zufall
Wir befassen uns unter anderem mit der Erstellung, Bewertung und dem Verbrauch von Zufall.
Außerdem in dieser Folge: Quantenmechanik, wildes Tastendrücken und Schiffe versenken.
ShownotesWir haben ein Errata zu STP019. Alex schreibt:
DMA kenne ich anders, nicht das der Prozess direkt über die MMU auf ein Peripheriegerät durchgreift, sondern dass ein Peripheriegerät ohne Beteiligung der CPU Daten vom/zum Hauptspeicher übertragen kann.
Man muss dem Kernel allerdings beim Reservieren von Speicher für DMA
sagen, dass das ein DMA Buffer sein soll, weil DMA selbst nicht über die MMU läuft sondern vom Peripheriegerät direkt von/zur physikalischen Adresse.
Den eigentlichen Transfer zwischen Buffer und Peripherie muss
man dann aber per Software entsprechend aktivieren.
Xyrill antwortet: Ja, stimmt. Nun zur eigentlichen Folge:
Intro-Intro: in Referenz auf den klassischen Dilbert-Cartoon, den man zum Beispiel hier sieht
Warum sind hochwertige Zufallszahlen wichtig?
siehe STP043: Erzeugung eines RSA-Schlüsselpaars benötigt zwei große und geheime Primzahlen
geheim = niemand anders kann es raten = zufällig
oder zumindest von Zufall nicht zu unterscheiden (Pseudozufall)
Was ist "guter" Zufall?
erstaunlich schwer zu definieren
vielleicht Periodenlänge (Dauer, bis sich die Zahlenfolge wiederholt)
vielleicht Gleichverteilung der Auftrittshäufigkeit von Teilfolgen (jede einstellige/zweistellige/dreistellige/etc. Zahl sollte gleich oft in der Folge vorkommen)
Problem: die Folge "2236067977499789805051478..." ist nach all diesen Maßstäben guter Zufall – bis man bemerkt, dass das die Dezimalstellen der Quadratwurzel von 5 sind
guter (aber unpraktikabler) Test: hohe Kolmogorow-Komplexität (siehe STP025)
Errata: Beim Nachhören ist mir aufgefallen, dass die Kolmogorow-Komplexität eines Pseudozufallszahlengenerators nie besonders groß sein kann, da der Zufallszahlengenerator ja gerade ein Programm ist, was die entsprechende Zahlenfolge erzeugen kann. Das ist kein praktisches Problem, da das Programm im Kolmogorow-Sinne auch die Startwerte des Zufallszahlengenerators umfassen müsste, die aber gerade geheim sind.
"echter" Zufall kommt aus physikalischen Zufallszahlengeneratoren (Hardware-RNG)
z.B. thermisches Rauschen eines elektrischen Widerstandes
z.B. radioaktive Zerfallsvorgänge
z.B. atmosphärisches Rauschen (Empfang auf einem Frequenzband, auf dem keiner sendet)
z.B. Abfilmen eines Aquariums :)
siehe auch: Würfeln, Lottozahlen
Probleme: nicht in jedem Computer verfügbar, pro Zeiteinheit begrenzte Menge von Zufall
Idee: Erzeugung beliebiger Mengen von Pseudozufall aus einem festen Algorithmus
Beispiel: Linearer Kongruenzgenerator
Parameter: geheime Ganzzahlen a, b, m; Startwert y
Erzeugung einer Folge von Pseudozufallszahlen durch die Formel y' = (a * y + b) mod m
Problem: bereits aus wenigen aufeinander folgenden y-Werten kann man auf die geheimen Zahlen zurückschließen (Ansatz vergleichbar mit Kryptoanalyse)
in besseren Pseudozufallszahlengeneratoren wird nach jedem Schritt nur ein kleiner Teil des Zustands herausgegeben, um Analyse zu erschweren
Anwendungsbereich für einfache Pseudozufallszahlengeneratoren: nicht sicherheitsrelevanter Pseudozufall, z.B. Ereignisse in Computerspielen oder Randomisierung von automatisierten Tests (hier kann Reproduzierbarkeit aus einem Startwert für spätere Nachvollziehung hilfreich sein)
für sicherheitsrelevante Anwendungen: Kryptografisch sichere Zufallszahlengeneratoren
Beispielidee: mit einem Hardware-RNG ein paar Bytes als Startwerte erzeugen, wiederholt mit AES-CTR (siehe STP043) verschlüsseln und die verschlüsselten Bits (oder Teile davon) als Ausgabe nehmen
wenn man keinen Hardware-RNG hat, kann man Zufallsbits auch aus Beobachtung des normalen Betriebs extrahieren (z.B. Mikrosekundenbruchteile der Zeitstempel von Ereignissen wie Tastaturdrücken oder dem Empfang von Datenpaketen übers Netzwerk)
unter Unix: /dev/random vs. /dev/urandom ; ist aber unter Linux mittlerweile so gut wie synonym (siehe auch); Probleme nur beim Systemstart, wenn noch nicht genug Entropie vorliegt (siehe auch: haveged, VirtIO RNG, systemd-random-seed.service)
im Gespräch erwähnt:
Video: "How we solved the worst minigame in Zelda's history" (Errata: Xyrill hatte im Gespräch behauptet, dass das Video von Lowest Percent sei. Es ist aber von Linkus7.)
57 min
September 07, 2023STP043: Kryptografische Primitiven
Im zweiten Teil unserer Reihe über Kryptografie besehen wir uns einzelne Klassen von Bausteinen, welche dann zu Verschlüsselungsprotokollen zusammengesetzt werden können.
Shownotes
Rückblick zu STP041
Kryptografische Systeme dienen dem Erreichen der vier Schutzziele (Vertraulichkeit, Integrität, Authentizität, Verbindlichkeit)
Implementierung vollständiger Kryptosysteme braucht Primitiven (Grundbausteine)
heute: Vorstellung grundlegender Klassen von Primitiven
Symmetrische Verschlüsselung
Schritt 1: Klartext (Plaintext) + Schlüssel (Key) -> Geheimtext (Ciphertext)
Schritt 2: Geheimtext + selber Schlüssel -> Klartext
üblicherweise als Blockchiffre mit Beschränkung des Klartexts auf eine Blockgröße von z.B. 128 oder 256 Bits, übliche Schlüsselgrößen ähnlich groß
zwei Probleme:
Wie verschlüsselt man mehr als einen Block?
Wie einigt man sich auf einen gemeinsamen Schlüssel, ohne dass Beobachter den Schlüssel abgreifen können?
zu Problem 1: Erweiterung der Blockchiffre zu einem Stromchiffre mittels eines geeigneten Betriebsmodus
Datenstrom wird in einzelne Blöcke der gewünschten Größe zerteilt; Betriebsmodus beschreibt dann die Anwendung des Blockchiffre auf die Folge von Blöcken
einfachster Betriebsmodus ist ECB (Electronic Codebook): der Blockchiffre wird auf jeden Block komplett separat angewendet -> offensichtliche Probleme (siehe Bild im verlinkten Abschnitt)
bei den meisten modernen Betriebsmodi werden meist Daten aus dem aktuellen Blockchiffre in den nächsten Block übertragen, um die Analyse des Geheimtextes zu erschweren -> Problem: schwer parallelisierbar, Lesezugriff nur sequentiell
CTR-Betriebsmodus (Counter): jeder Block wird beim Verschlüsseln mit einem Zähler kombiniert, damit sich keine wiederkehrenden Muster wie bei ECB ergeben -> Vorteil: wahlfreier Schreib- und Lesezugriff möglich (interessant für Festplattenverschlüsselung)
siehe unten: Beispiel für die Geschwindigkeit moderner Stromchiffern insb. mit Hardwareunterstützung
$ cryptsetup benchmark
...
# Algorithm | Key | Encryption | Decryption
...
aes-xts 512b 3547,4 MiB/s 3540,4 MiB/s
serpent-xts 512b 742,7 MiB/s 729,4 MiB/s
twofish-xts 512b 398,9 MiB/s 404,8 MiB/s
zu Problem 2 (Einigung auf einen gemeinsamen Schlüssel) zwei Ansätze:
Schlüsselaustausch-Protokolle wie Diffie-Hellman
asymmetrische Verschlüsselung
Asymmetrische Verschlüsselung
statt einem einzelnen Schlüssel ein Schlüsselpaar
wir haben keine gute Bildmetapher dazu; Xyrills Vorschlag: zwei Ratschen; eine dreht nur nach rechts und eine nur nach links
Schritt 1: Klartext + öffentlicher Schlüssel -> Geheimtext
Schritt 2: Geheimtext + privater Schlüssel -> Klartext
Beispiel RSA:
Grundgeheimnis sind zwei sehr große Primzahlen (p und q, jeweils z.B. 500 Dezimalstellen)
aus dem Produkt dieser Primzahlen (N = p * q) werden zwei weitere Zahlen (d und e) mittels günstiger Rechenoperationen abgeleitet
dann ist der öffentliche Schlüssel das Zahlenpaar d,N und der private Schlüssel das Zahlenpaar e,N
Ableitung des privaten aus dem öffentlichen Schlüssel erfordert Primzahlfaktorisierung von N, was extrem teuer ist (siehe Beispiel unten)
Problem 1 teilweise gelöst: Empfänger muss nur seinen öffentlichen Schlüssel offenbaren, der kein Geheimnis enthält
Problem 2 ungelöst: auch asymmetrische Verschlüsselung arbeitet nur pro Block
$ time factor 1350918345091284620469824069824602946802496824562049682046982406982406980
1350918345091284620469824069824602946802496824562049682046982406982406980: 2 2 3 5 7 193 941 5077 3488395463852632669275489205712092360621005476304268749586169
factor 1,92s user 0,00s system 99% cpu 1,926 total
$ time factor 1350918345091284620469824069824602946802496824562049682046982406982406981
1350918345091284620469824069824602946802496824562049682046982406982406981: 11 3931 5242879872157046321 5958863859256362497309559371496021100634736129421
factor 462,19s user 0,01s system 99% cpu 7:43,24 total
neues Problem: asymmetrische Verfahren sind sehr viel rechenaufwändiger als symmetrische Verfahren -> hybrides Kryptosystem
asymmetrische Verschlüsselung wird nur zum Austausch eines symmetrischen Schlüssels verwendet
Beispiel "verschlüsselte E-Mail": Alice hat den öffentlichen Schlüssel O, Bob hat den privaten Schlüssel P dazu
Alice erstellt die Nachricht N im Klartext
Alice erzeugt einen zufälligen symmetrischen Schlüssel S
Alice verschlüsselt N mit S und einem Stromchiffre zu N'
Alice verschlüsselt S mit O zu S'
Alice schickt N' und S' an Bob
Bob entschlüsselt S' mit P zu S
Bob entschlüsselt N' mit S zu N
zweite Anwendung von asymmetrischer Kryptografie: Signaturen
Verschlüsselung: vorwärts mit dem öffentlichen Schlüssel, rückwärts mit dem privaten Schlüssel
bei Signierung umgekehrt: vorwärts mit dem privaten Schlüssel (Erzeugung), rückwärts mit dem öffentlichen Schlüssel (Überprüfung)
im Detail: erst Komprimierung der zu signierenden Daten auf eine feste Größe mittels einer Hashfunktion (siehe STP004), dann Verschlüsselung dieses Hash-Wertes mit dem privaten Schlüssel
Überprüfung: Berechnung des Hashes auf dieselbe Weise, Vergleich mit entschlüsselter Signatur
noch eine Primitive zum Schluss: Geheimnisteilung
Problem: Ein Geheimnis soll in N Teile so aufgeteilt werden, dass M beliebige Teile zum Entschlüsseln genutzt werden können.
Beispiel: Backup des Passwortspeichers in 5 Fragmente aufteilen und bei 5 Freunden so einlagern, dass man später nur 3 beliebige Fragmente zum Wiederherstellen braucht
Illustrationen: Visuelle Kryptografie, Blakley-Schema
im Gespräch erwähnt
Anerzählt Podcast zu AES
Whitfield Diffie und Moxie Marlinspike und eine Flasche Whiskey auf der Bühne
1 hr 13 min
August 17, 2023STP042: Cursed Computer Iceberg Meme
In der Episode mit dieser Nummer werden wir aus Günden vom normalen Programm abweichen. Während diese Gründe für den durchschnittlichen {Nerd|Geek} gut verständlich sein dürften, werden diese für alle Anderen ausführlich erklärt. Xyrill greift zu diesem Anlass völlig wahllos einige lustige und/oder deprimirende Aspekte aus dem Eisberg der Computerei heraus.
Shownotes
Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen.
– Douglas Adams, Das Restaurant am Ende des Universums. Ullstein, 1994. ISBN 3-548-22492-X. Deutsche Übersetzung von Benjamin Schwarz. Seite 11.
Vorbemerkung: Die Zahl 42
Per Anhalter durch die Galaxis von Douglas Adams
in der Nerdkultur einflussreich durch eine Kombination aus klassisch britischem schwarzem Humor und einprägsam idiosynkratischen Vignetten
42 = die Antwort auf die endgültige Frage nach dem Leben, dem Universum und dem ganzen Rest
mehr zu Douglas Adams in der Freak Show, Folge 266 (siehe Kapitelmarke "Douglas Adams")
Was könnte dieser Referenz passen? Vielleicht das Cursed Computer Iceberg Meme
Eisberg-Meme: möglicherweise inspiriert von Freuds Vorstellung des Bewusstseins als ein Eisberg, von dem der größte Teil (das Unterbewusstsein) unter Wasser liegt und nicht sichtbar ist
Xyrill findet die Kategorieneinteilung etwas merkwürdig; wir werden auf fast allen Ebenen Sachen finden, die schon in vergangenen Folgen besprochen wurden
aus Zeitgründen nur eine kleine Auswahl, analog zu STP035
"Above the Iceberg" - Oberhalb des Eisberges
bereits besprochen:
Y2K, Jahr-2038-Bug: siehe STP016 bzw. STP037
Brainfuck: siehe STP033
TCP/IP über Brieftaube: siehe STP035
Heisenbugs: siehe STP038
Bogosort: der beste Sortieralgorithmus (siehe auch STP029)
Sleepsort: der parallelste Sortieralgorithmus
DOOM auf einem Toaster: eine wichtige Erinnerung, dass diese ganzen "smarten" Geräte vollwertige Computer sind
siehe auch: Wahlcomputer-Debatte (dazu passend Pentacast 55 und CRE039 der NEDAP-Hack)
"All web browsers pretend to be each other"
Beispiel: aktueller Edge meldet sich als User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 Edg/113.0.1774.50
"On the Iceberg" - Auf dem Eisberg
bereits besprochen:
Gene wurden umbenannt wegen Excel: siehe STP012
Fast Inverse Square Root: siehe STP037
aus Versehen turingvollständig
Turing-Vollständigkeit heißt, dass ein System alle berechenbaren Funktionen berechnen kann (gegeben genug Zeit und Speicherplatz)
überraschend wenig Voraussetzungen (siehe Brainfuck), im wesentlichen reicht musterbasierte Textersetzung und echte Rekursion
Implikationen für den Erfolg von Sicherheitsmaßnahmen wie Sandboxing (siehe STP023)
Self-Hosting Languages
nicht das gleiche Bootstrapping wie in STP020
siehe auch "Trusting Trust" weiter unten
"Wir können keine E-Mail weiter als 500 Meilen schicken"
Techniker macht ein Serverupdate, bei dem aus Versehen der Mailserver durch eine ältere Version ersetzt wird
alter Mailserver versteht Teile der Konfigurationsdatei nicht, nimmt für alle unbekannten Sachen Null an
Null erlaubte Wartezeit beim Verbindungsaufbau ergibt ein reales Zeitfenster von etwa 3ms; in Lichtgeschwindigkeit etwas über 500 Meilen
"Below the Water" - Unter der Wasserlinie
bereits besprochen:
FDIV-Bug: siehe STP037
CAP-Theorem: siehe STP027
Reflections on Trusting Trust
Malbolge: die frustrierendste Programmiersprache der Welt
Null Island: ein Insider-Witz unter Geografen
Die 0,0-Boje bei OpenStreetMap
Wir haben's trotz stark beschränkter Auswahl nicht mal bis zur Hälfte des Eisbergs geschafft... wir brauchen wohl mal einen zweiten Teil hiervon. :) Aber Xyrill sah noch etwas Bekanntes an der unteren Spitze des Eisbergs:
if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking
not to oversimplify: first you have to flatten the rock and put lightning inside it
– @daisyowl auf Twitter
1 hr 24 min
July 27, 2023STP041: Grundlagen der Kryptografie
Diesmal gibt es den Einstieg in ein Thema, vor dem wir uns schon eine Weile gedrückt haben.
Dieses heutzutage essenzielle und gleichzeitug subtile Gebiet werden wir auch aufgrund seiner Tiefe über mehrere Episoden aufteilen.
ShownotesDefinition laut Wiktionary:
"Kryptografie", aus griechisch κρυπτός (kryptos) „verborgen“ und -γραφία (graphia), zum Verb γράφειν (graphein) „schreiben“ gebildet
Informatik, Mathematik: Wissenschaft der Verschlüsselung von Informationen
Psychologie: absichtslos entstandene Kritzelzeichnung eines Erwachsenen
Warum Verschlüsselung? Vier Schutzziele
Vertraulichkeit: Eine Nachricht soll nur von berechtigten Personen oder Maschinen gelesen werden dürfen.
Integrität: Nachrichten sollen nachweislich vollständig und unverändert sein.
Authentizität: Die Nachricht soll ihrem tatsächlichen Absender zugeordnet werden können.
Verbindlichkeit: Der Absender einer Nachricht soll seine Urheberschaft nicht abstreiten können.
Beispiele aus der analogen Welt: Verträge, Geheimnisträger:innen (Anwält:innen, Geistliche, Mediziner:innen, etc.)
"Ich hab doch nichts zu verbergen" -> Unterschied zwischen "privat" und "geheim"
Verschlüsselung im engeren Sinne: Übertragung eines Klartext (Plaintext) in einen Geheimtext (Ciphertext) und später wieder zurück
Beispiel für (historisch signifikanten) Ciphertext: Zimmermann-Depesche
die Relation zwischen Klartext und Ciphertext wird vermittelt durch einen Schlüssel, also eine Folge von Bits fester Länge (je nach Verfahren zwischen 128 Bits bis zu 4096 Bits)
Grundbausteine eines Kryptosystems: Primitiven
Beispiel für eine Klasse von Primitiven: symmetrische Verschlüsselung (Funktionsprinzip: Klartext + Schlüssel -> Geheimtext, Geheimtext + selber Schlüssel -> Klartext)
Qualitätsmaßstab: Angreifer mit Zugriff auf den Geheimtext soll nicht auf den Klartext schließen können
immer möglich: Angriff nach Brute-Force-Methode, also Durchprobieren aller möglichen Schlüssel (Beispiel: Zahlenschloss mit vierstelliger PIN)
praktischer Maßstab: Brechen einer Verschlüsselung soll nicht weniger als 2^100 Rechenoperationen erfordern (2^100 = 1.267... * 10^30)
Rechenbeispiel: Xyrills Grafikkarte kann im Idealfall etwa 64 TFLOPS liefern, also 64 Trillionen Rechenoperationen pro Sekunde; bei dieser Geschwindigkeit benötigen 2^100 Rechenoperationen etwa 627 Millionen Jahre
Seitenleiste: Quantencomputer sind nicht automatisch Game Over, aber es gibt aktive Forschung an Post-Quanten-Kryptografie
Primitiven alleine machen noch kein vollständiges Kryptosystem
die tollste Festplattenverschlüsselung hilft nicht, wenn ich das Passwort am Monitor kleben habe :)
besonders spannend: Seitenkanal-Angriffe
Beispiel: je nach Bitfolge im Schlüssel dauert das Entschlüsseln unterschiedlich lang oder braucht unterschiedlich viel Energie oder erzeugt unterschiedlich viel Strahlung
Beispiel: Login mit Benutzername und Passwort sollte sich bei falschem Passwort genauso verhalten wie bei nicht vorhandenem Benutzerkonto
Vorschau
nächstes Mal (STP042) was ganz anderes... aber dann!
STP043: Überblick über Klassen von Primitiven (Fokus auf das allgemeine Verhalten anstatt auf konkrete mathematische Konstruktion)
STP044: Starke Kryptografie ist kein Zufall... oder doch?
im Gespräch erwähnt
Schlüsseltechnologie Live: Das Diffie-Hellman-Protokoll
Kerckhoffs' Prinzip
XKCD 538: Security
crypto/subtle
1 hr 8 min
July 06, 2023STP040: Urheberrecht bei Programmen
In dieser Episode soll es darum gehen, wer, wann, wie ein Urheberrecht erhält und es nutzen kann. Im Zweifel sogar postmortal. Oder eben nicht. Auch geht es darum, wie lange ein Urheberrecht aus wissenschaftlicher Sicht sinnvoll ist. Und sogar Hitler hat es in die Sendung geschafft.
Shownotes
Programmcode ist ein immaterielles Wirtschaftsgut -> jeder Programmierer sollte ein Grundverständnis für Immaterialgüterrecht haben (neben Urheberrecht auch Patentrecht, Markenrecht, etc.)
obligatorische Vorbemerkungen
Wir sind keine Rechtsanwälte. Das hier ist keine Rechtsberatung.
Fokus auf das deutsche Recht (insbesondere nicht auf das Copyright der englischen Rechtstradition)
insbesondere Fokus auf das UrhG, daneben noch zum Beispiel das KunstUrhG (Recht am eigenen Bild) oder das ArbnErfG (Arbeitnehmererfindungen)
erste Facette: Urheberpersönlichkeitsrecht
§ 12 UrhG: "Der Urheber hat das Recht zu bestimmen, ob und wie sein Werk zu veröffentlichen ist."
§ 13 UrhG: "Der Urheber hat das Recht auf Anerkennung seiner Urheberschaft am Werk." (aber keine Pflicht)
§ 14 UrhG: "Der Urheber hat das Recht, eine Entstellung oder eine andere Beeinträchtigung seines Werkes zu verbieten, die geeignet ist, seine berechtigten geistigen oder persönlichen Interessen am Werk zu gefährden."
im Allgemeinen nicht übertragbar, aber insb. für Computerprogramme § 69b UrhG: "Wird ein Computerprogramm von einem Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers geschaffen, so ist ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse an dem Computerprogramm berechtigt, sofern nichts anderes vereinbart ist."
zweite Facette: Verwertungsrecht in §§ 15 ff. UrhG
Recht auf Vervielfältigung, Verbreitung, Ausstellung, Vortrag/Aufführung/Vorführung, Sendung, Bearbeitung/Umgestaltung, Verfilmung, etc.
meistens Übertragung dieser Rechte, zum Beispiel bei Büchern auf Verlage oder bei Filmen auf Verleiher
Schranken des Urheberrechts: §§ 44a ff. UrhG
Rechtspflege, Barrierefreiheit, Gebrauch bei religiösen Feierlichkeiten, Schulfunksendungen, Verbreitung öffentlicher Reden, Berichterstattung über Tagesereignisse, Zitate, Karikaturen/Parodien, Privatkopien
insb. für Programme § 69e UrhG: "Die Zustimmung des Rechtsinhabers ist nicht erforderlich, wenn die Vervielfältigung des Codes oder die Übersetzung der Codeform [...] unerläßlich [sic] ist, um die erforderlichen Informationen zur Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen zu erhalten, sofern folgende Bedingungen erfüllt sind: [...]"
Freie Software, Open-Source-Bewegung
Urkonzept im englischsprachigen Copyright: Public Domain (willentliche Abtretung der Urheberrechte, im deutschen Urheberrecht nicht möglich)
ab Beginn der Informatik: in der Forschung Behandlung von Programmcode wie wissenschaftliche Erkenntnisse, ohne Anwendung des Urheberrechts
ab 1980er Jahre: Freie-Software-Bewegung -> subversive Nutzung des Copyright nicht zur Beschränkung, sondern zur Maximierung von Nutzbarkeit
"Vier Grundfreiheiten": Use, Study, Share, Modify -> Copyleft-Modell (Urheber zwingt alle Nutzer, auch bei Folgenutzungen die vier Grundfreiheiten zu berücksichtigen)
Gegenbewegung: "Open Source" -> schwächere Definition, quelloffene Software ohne Copyleft kann auch in unfreier Software verwendet werden
Randbemerkung: diese Open-Source-Gemeinde hat bis auf den Namen nichts mit der OSINT-Community zu tun
praktischer Hinweis für Programmierer: Schaut auf eure SBOM!
BOM = Bill of Material (zu deutsch: Stückliste/Materialliste)
SBOM = Stückliste für Software (Welche Programme oder Programmbibliotheken werden als Teil meines Programms mit ausgeliefert?), Symbolbild
Teil der SBOM sind die Lizenzinformationen der verwendeten Programme und Bibliotheken
SBOM ist auch sonst eine gute Idee; kann man auch zum automatisierten Suchen nach Sicherheitslücken verwenden
netzpolitische Aspekte
§ 95a UrhG: der Kopierschutzparagraf, "Wirksame technische Maßnahmen zum Schutz eines [...] Werkes [...] dürfen ohne Zustimmung des Rechtsinhabers nicht umgangen werden, soweit [...] die Umgehung erfolgt, um den Zugang zu einem solchen Werk [oder dessen] Nutzung zu ermöglichen."
§ 64 UrhG: "Das Urheberrecht erlischt [im Allgemeinen] siebzig Jahre nach dem Tode des Urhebers."
Studie: Optimale Dauer des Urheberrechtsschutzes wäre 14 Jahre; Link zur Originalstudie
§ 44b UrhG: der Data-Mining-Paragraf, "Zulässig sind Vervielfältigungen von rechtmäßig zugänglichen Werken für das Text und Data Mining. Die Vervielfältigungen sind zu löschen, wenn sie für das Text und Data Mining nicht mehr erforderlich sind. [...] Ein Nutzungsvorbehalt bei online zugänglichen Werken ist nur dann wirksam, wenn er in maschinenlesbarer Form erfolgt."; siehe dazu auch Pentaradio vom August 2022
im Gespräch erwähnt
GNU-Projekt
Postmortales Persönlichkeitsrecht
1 hr 21 min
June 15, 2023STP039: Authentifizierung und Autorisierung
Die Frage, wer wir sind, beschäftigt nicht nur uns selbst, sondern auch alle Anbieter von Diensten aller Art, wenn sie mit Computern zu tun haben. Heute sprechen wir über die Mechanismen, die zur Feststellung einer Person oder ihrer Berechtigungen besonders im Netz verwendet werden.
Shownotes
grundsätzliche Begriffsklärung
Authentifizierung: Nachweis einer behaupteten Eigenschaft einer Entität; hier: der Nachweis der Identität einer Person, eines Gerätes oder eines Prozesses ("Wer ist dieser Benutzer?")
Autorisierung: die Einräumung von Rechten gegenüber einem interessierten Subjekt; hier: das initiale Zuweisen und das wiederholt einleitende Überprüfen von Zugriffsrechten ("Darf dieser Benutzer auf dieses Dokument zugreifen?")
im englischen Sprachgebrauch "authentication" (AuthN) und "authorization" (AuthZ)
AuthN durch einen oder mehrere von drei wesentlichen Arten von Identitätsmerkmalen
Wissen: etwas, dass ich weiß (Passwörter, PINs, etc.)
Besitz: etwas, dass ich habe (Chipkarte, Lichtbildausweis, Mobiltelefon, PC, etc.)
Inhärenz: etwas, dass ich bin (Fingerabdruck, Iris-Abbild, etc.) -> Achtung: Problematisch, weil nicht änderbar!
Multifaktor-Authentifizierung: Wer eines der drei Merkmale gut angreifen kann, kann selten eins der anderen Merkmale gut angreifen.
schlechte Arten von Merkmalen
Magnetstreifenkarte (Besitz-Merkmal): trivial kopierbar -> deswegen heute meist Chipkarten
Chipkarten sind kleine Computer, die sich per Challenge-Response authentisieren können
siehe zum Beispiel ChipTAN
Code per SMS (Besitzfaktor): auf Telefonebene angreifbar durch Malware mit erschlichener SMS-Berechtigung, auf Netzwerkebene angreifbar durch Umleitung der SMS
als Besitzfaktor buchstäblich "besser als nichts"
besser ist eine Authentisierungs-App mit TOTP
zu kreativen Angriffen auf Besitzmerkmale und Biometrie siehe die Vorträge von Starbug
Autorisierungs-Schemata
früher meist Access Control Lists (ACL): jedes Datenobjekt hat eine Liste mit zugriffsberechtigten Benutzerkonten und Gruppen
Beispiel ACL in Unix: Dateisystemeinträge haben rwx-Bits (Lesezugriff, Schreibzugriff, Ausführzugriff) jeweils für das besitzende Benutzerkonto, die besitzende Gruppe und alle Benutzerkonten
heute meist Role-Based Access Control (RBAC) auf der Ebene von semantischen Operationen
Beispiel RBAC in OpenStack: Benutzerkonten oder Benutzergruppen können Rollenzuweisungen erhalten; die Menge der zugewiesenen Rollen bestimmt, welche Aktionen ein Benutzer ausführen kann
Authentisierung im Webkontext: Single Sign-On (SSO) via SAML, OIDC
Idee: Authentisierung bei einem zentralen Identitätsanbieter, dann Verwendung dieser festgestellten Identität in einem Zielsystem
SSO könnte man auch mit LDAP haben, aber SAML/OIDC erlaubt eine Einschränkung, welche Identitätsdaten der autorisierende Dienst vom authentifizierenden Dienst erhält
1 hr 5 min

About Schlüsseltechnologie

From the publisher's feed

Die IT hat unser Leben in den letzten Jahrzehnten von Grund auf verändert. Aber wie funktioniert sie wirklich? Das möchte ttimeless mal erklärt bekommen. Zum Glück hat Xyrill Antworten.

Share Schlüsseltechnologie

Sign up to save your podcasts

Schlüsseltechnologie

Schlüsseltechnologie episodes

About Schlüsseltechnologie

More shows like Schlüsseltechnologie

Freak Show

Lage der Nation - der Politik-Podcast aus Berlin

Logbuch:Netzpolitik