Notizen 20.6.2022

20220620/nit-20220620.txt

+GNU-Taler, 13.06.2022, 14:37:43
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Quelle: https://nlnet.nl/project/GNUTaler/
+ - anonym wie Bargeld
+ - erschwert Geldwäsche
+
+Quelle: https://www.heise.de/news/Projekt-GNU-Taler-Das-quelloffene-Bargeld-4892826.html
+ - zentrale Instanzen: Exchange
+ - Nutzer anonym
+ - Händler nachverfolgbar
+
+Funktionsweise:
+
+ - Bei der Nutzung signiert man die "Überweisung" mit einem privaten Schlüssel
+   und schickt sie an die Exchange.
+ - Dieser prüft die Gültigkeit der Überweisung und führt sie aus.
+ - Peer-to-Peer-Zahlungen: noch nicht möglich, aber geplant
+
+Behauptung: Zahlung kann anonym erfolgen; Umtausch in klassische Währung ist nachvollziehbar
+
+ - Umtausch in klassische Währung:
+   geregelt durch die Exchange, typischerweise eine klassische Bank
+
+ - Anonyme Zahlung?
+
+Verfahren: blinde Signaturen
+
+ - Quelle: https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
+   "fundamentally new kind of cryptography"
+
+ - Jede Münze hat ein Schlüsselpaar.
+ - Die Exchange kennt diese Schlüsselpaare nicht.
+
+ - Grundidee: Die Exchange unterschreibt etwas, ohne zu wissen, was sie da unterschreibt.
+
+ - Analogie: Unterschrift auf unbekanntem Dokument
+   mittels Durchschlagpapier in verschlossenem Briefumschlag
+
+ - Anwendung auf eine geheime Wahl auf Entfernung,
+   bei der sichergestellt wird, daß jede Stimme gezählt wird
+   --> Trustee (Wahlleiter*in) darf Stimmen zählen,
+       aber nicht wissen, von wem diese jeweils sind.
+ 
+ - Stimmzettel in anonymem, inneren Umschlag, den man blind unterschreiben kann
+   --> Man kann per Blind-Unterschrift bestätigen,
+       daß der Inhalt des Umschlags für die Wahl zulässig ist.
+       "In diesem Umschlag befindet sich ein gültiger Stimmzettel."
+
+ - Der anonyme, innere Umschlag wird in einem nicht-anonymen, äußeren Umschlag
+   an Trustee versendet.
+   Trustee unterschreibt den inneren Umschlag (und damit blind den Stimmzettel)
+   und sendet diesen in einem neuen äußeren Umschlag zurück.
+   --> Der innere Umschlag wurde nicht geöffnet,
+       dessen Inhalt aber von Trustee unterschrieben.
+       Damit bestätigt Trustee den Willen von Elector, ohne diesen zu kennen.
+ 
+ - Elector kann den von Trustee unterschriebenen Stimmzettel nun anonym einreichen.
+   --> Sinn der Aktion: Nur Elector darf den inneren Umschlag öffnen.
+ 
+ - Trustee kann die - anonymen und unterschriebenen - Stimmzettel nun veröffentlichen.
+
+Funktionsweise:
+
+ * Wir haben:
+
+    - ein Schlüsselpaar s (öffentlich), s' (geheim),
+
+    - eine "kommutierende Funktion" c mit Inversem c', die sich "mit der Signatur verträgt",
+      d.h. c'(s'(c(x))) = s'(x) für ein bestimmtes, aber unbekanntes x.
+      --> Wir wählen ein x und und lassen es mit s' signieren.
+          Wir ordnen dem x ein c(x) zu und lassen dieses ebenfalls mit s' signieren.
+          Dann ordnet c' diesem s'(c(x)) wieder die Signatur s'(x) zuordnen.
+
+ * Vorgehensweise
+
+    - Provider (= Elector = Payer) wählt ein zufälliges x
+      und übergibt c(x) an Signer (= Trustee = Bank).
+
+    - Signer unterschreibt c(x) --> s'(c(x)).
+
+    - Provider erzeugt daraus s'(x) = c'(c(s'(x)))
+      --> Damit hat Provider eine Signatur von Signer für x, ohne daß Provider x kennt.
+
+Quelle: https://en.wikipedia.org/wiki/Blind_signature
+
+ * Vermutung: Spezialfall von homomorpher Verschlüsselung
+
+    - Sei c eine Verschlüsselung und c' eine Entschlüsselung.
+
+    - Wir haben mathematische Botschaften a und b.
+
+    - verschlüsselt: c(a) bzw. c(b)
+
+    - Homomorphe Verschlüsselung bedeutet: c(a+b) = c(a) + c(b)
+      (und/oder entsprechend für andere Rechenarten)
+
+ * Hier: Verschlüsselung ist homomorph zu RSA
+
+    - Nachricht m, RSA-verschlüsselt r(m), wieder entschlüsselt r'(r(m))
+
+    - dazu homomorphe Verschlüsselung c: c'(r(c(m))) = r(m)
+      --> Dies ist nichttrivial!
+
+    - Wie dies für RSA funktioniert:
+      https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures
+
+    - Wir ermitteln eine Zufallszahl r
+      und verschlüsseln sie mit dem öffentlichen Schlüssel: r^e
+
+    - Die Bank signiert das Produkt m' = m · r^e unserer Überweisung m mit r^e.
+
+    - Mit unserem geheimen Schlüssel d und der geheimen Zufallszahl r
+      können wir daraus eine gültige Signatur für unsere Überweisung m extrahieren.
+
+ * Anwendung auf Zahlungssystem
+
+    - "(3) Bank signs note ... and debits payer's account."
+      --> Die Bank (= Signer = Trustee) kennt x also doch???
+
+   Vermutung:
+
+     - Payer nennt Betrag
+       und erzeugt eine Banknote über diesen Betrag.
+
+     - Die Bank belastet das Konto mit dem gewünschten Betrag
+       und bestätigt, daß die Banknote für diesen Betrag gültig ist.
+
+     - Payer gibt die Banknote an Payee weiter.
+
+     - Payee gibt die Banknote der eigenen Bank.
+       Diese prüft die Signatur der anderen Bank,
+       prüft, ob diese Banknote evtl. bereits anderweitig eingelöst wurde,
+       und schreibt, sofern alles in Ordnung ist, Payee den Betrag gut.
+
+    --> Damit findet eine Überweisung von Payer an Payee statt,
+        ohne daß die beteiligten Banken die Transaktion kennen.
+
+   Nachteile:
+
+     - Man benötigt eine immer länger werdende Liste von bereits verbrauchten Banknoten.
+
+     - Peer-to-Peer-Zahlungen sind auf diese Weise (noch) nicht möglich.
+
+     - evtl. Deanonymisierung möglich durch Analyse der Metadaten
+       --> Problem evtl. lösbar durch Banknoten mit festen Beträgen (wie Geldscheine)
+
+Themen für heute
+~~~~~~~~~~~~~~~~
+Begrenzte Ressourcen sparen durch Software
+ - Wie muß man programmieren, damit die Software
+   möglichst wenig Strom verbraucht?
+ - Wie kann man die in Rechenzentren vorhandene Rechenleistung
+   möglichst effizient nutzen?
+ - Beispiel: virtuelle Rechner, Container, Cloud
+
+--> "Hardware-Nachhaltigkeit", durch Software realisiert
+
+Smartphones: Bestandsaufnahme
+ - Wie hoch kann der Anteil an freier Software sein
+   (auf Standard-Smartphones bzw. auf speziellen, freien Smartphones)?
+ - Wieviel digitale Souveränität kann man gewinnen?
+
+Bitte schon mal recherchieren!
+
+Ressourcen sparen durch Software: Virtualisierung, 20.06.2022, 15:34:52
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+       .---------------.
+       |  Anwendungen  |
+     .-------------------.
+     | virtuelle Rechner |
+   .-----------------------.
+   |     Hypervisor-OS     |
+ .---------------------------.
+ |   physikalische Hardware  |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Auslastung der vorhandenen Hardware verbessern:
+ - physikalische Hardware nicht immer voll ausgelastet
+ - insgesamt am effizientesten: immer voll ausgelastet
+   (Ansonsten verbraucht der nicht ausgelastete Teil unnötigen Strom.)
+ - durch Verteilung auf virtuelle Rechner ist volle Auslastung erreichbar
+ - Dadurch kann man die Anzahl der benötigten Rechner minimieren.
+
+Beispiel: Proxmox
+ - einheitliche Verwaltung für Container (z.B. Docker)
+   und virtuelle Maschinen (z.B. KVM, QEMU)
+ - Container: Gastsystem verwendet den Kernel des Gastgebersystems mit
+   (nicht immer möglich)
+ - Virtuelle Maschine: Gastgebersystem emuliert Hardware für Gastsystem
+   (langsamer)
+
+Wie hilft dies bei der Optimierung der Auslastung?
+
+Beispiel: BigBlueButton
+ - BigBlueButton hatte früher einen einzelnen zentralen Thread, hatte also
+   1 CPU als "Nadelöhr". In dem Fall war es effizienter, mehrere BBB-Instanzen
+   in virtuellen Umgebungen laufen zu lassen, z.B. in Xen.
+   --> Virtualisierung erlaubt es, den Server effizienter auszulasten.
+ - Ein Load-Balancer kann die Last automatisch zwischen diesen verschiedenen
+   virtuellen Umgebungen verteilen. (Z.B. verteilt Bochum seine BBB-Instanzen
+   zwischen Bochum und Heiligenhaus.)
+ - Durch effizientere Programmierung verbraucht BBB inzwischen weniger Ressourcen
+   als früher.
+
+LXC und Docker sind zwei verschiedene Oberflächen (Sammlung von Kommandos,
+ggf. GUI), um unter einem Linux-Kernel Container zu realisieren.
+Proxmox unterstützt Docker nicht nativ, aber man kann Docker innerhalb von
+LXC und innerhalb von virtuellen Maschinen nutzen.
+Dies ist z.B. dann sinnvoll, wenn Software in Gestalt von Docker-Containern
+zur Verfügung steht.
+Diese Schachtelung von Containern verbraucht zusätzlichen Speicherplatz,
+aber vermutlich keine zusätzliche Rechenleistung.
+
+Schnittstelle für Backups
+ermöglicht, virtuelle "Hardware" in einem Backup zu speichern
+Siehe: https://g-n-u.de/images/G-N-U-Karikatur-Virtualisierung.png
+--> Unabhängigkeit von konkreter Hardware (einschließlich evtl. nicht mehr
+    erhältlicher Ersatzteile)
+
+Cloud, 20.06.2022, 16:28:24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Cloud: Landschaft für Virtualisierung, von einem speziellen Anbieter
+(extern oder intern) betrieben
+ - kann helfen, Ressourcen zu sparen (siehe oben)
+ - mögliches Problem: Verlust der Datenautonomie
+   --> Dasselbe Problem läßt sich auch für Root-Server nicht ausschließen.
+
+Cloud-Nutzung mit Smartphones?
+ - Je nach Benutzung des Smartphones liegen viele Daten nicht auf dem
+   Smartphone selbst, sondern in der Cloud. Entsprechendes gilt für
+   Office 365 auf "normalen" Rechnern.
+ - Bei Installation von Apps aus dem Google-App-Store erfährt Google,
+   wer sich was installiert hat und evtl noch mehr.
+ - Push-Nachrichten: Dienstebetreiber registrieren sich bei Google bzw. Apple.
+   Je nach App erfährt Google/Apple nur, daß eine Nachricht vorliegt
+   oder auch Metadaten und evtl. den Inhalt.
+   --> Man hängt trotzdem immer an der "Nabelschnur" von Google/Apple.
+ - Unified Push: https://unifiedpush.org/
+   dezentraler Dienst für den Empfang von Push-Nachrichten,
+   nur von speziellen Apps unterstützt
+
+Push-Nachrichten: Dauerhafte Verbindung mit dem Push-Server
+ - Wenn jeder Diensteanbieter einen eigenen Push-Server betreibt,
+   muß jede App eine eigene Verbindung aufbauen.
+--> Zentraler Push-Server ist sinnvoll.
+
+Smartphones: Bestandsaufnahme, 20.06.2022, 16:47:07
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ * Wie hoch kann der Anteil an freier Software sein
+   (auf Standard-Smartphones bzw. auf speziellen, freien Smartphones)?
+
+    - Betriebssystem: Android
+      (Linux-Distribution für Smartphones)
+       - Android-Entwickler versuchen, die Differenz zwischen Android und dem
+         offiziellen Linux-Kernel, möglichst gering zu halten.
+       - Jede App bekommt eine eigene User-ID.
+       - Zertifiziertes installiertes Android:
+          - keine root-Shell
+          - grafische Oberfläche ("Launcher"?), keine Text-Shell
+          - bestimmte, proprietäre Google-Apps vorinstalliert, z.B. PlayStore
+          - Text-Shell nachinstallieren: kein privilegierter Prozeß,
+            kann nur auf öffentliche Daten zugreifen
+          - "secure boot" ist aktiv --> Man kann keinen eigenen Kernel starten,
+            um evtl. doch auf private App-Daten zuzugreifen.
+            Man kann dies deaktivieren, dann werden jedoch alle Benutzerdaten
+            gelöscht.
+       - Bootloader: 3 Modi
+          - fest installierter Bootloader, kann Android neu installieren
+          - Recovery Mode: kann Android reparieren oder neu installieren,
+            nicht fest installiert, sondern auf Flash, daher austauschbar,
+            kann dann auch root-Shell enthalten
+          - Standard-Modus: Android startet
+       - Ge"root"etes Android:
+          - root-Shell vorhanden
+          - Apps können auch root-Rechte haben.
+
+    - AOSP - Android Open Source Project
+       - liegt grundsätzlich offen: https://source.android.com/
+       - Chipsatz-Hersteller ergänzen hier ihre Treiber.
+         Diese sind meistens proprietär, zumindest der User-Space-Teil.
+         (Der Kernel-Space-Teil müßte eigentlich immer offenliegen,
+         tut dies aber nicht immer.)
+      --> Ein handelsübliches Smartphone enthält eigentlich immer
+          proprietäre Treiber.
+          Je nach Gerät gibt es bestimmte Hardware-Treiber
+          nur als unfreie Software.
+       - Zusätzlich insallieren die Smartphone-Hersteller ihre eigenen
+         proprietären Apps vor.
+
+    - Betriebssystem: LineageOS
+      (Nachfolger von CyanogenMod, Projekt von Freiwilligen)
+       - Anpassung von AOSP an aktuelle Smartphone-Modelle
+       - verwendet proprietäre Treiber
+       - weitgehend kompatibel zu Android
+       - keine Apps vorinstalliert
+       - Updates unabhängig vom Hersteller
+
+    - Freie Smartpones: Librem 5, Pinephone
+       - Übersicht: https://en.wikipedia.org/wiki/Comparison_of_open-source_mobile_phones
+          - Die Haupt-CPU führt keinen proprietären Code aus.
+          - Pinephone: proprietäre Firmware für WiFi/Bluetooth
+            liegt in /lib/firmware, wird von Modem ausgeführt
+          - Librem 5: proprietäre Firmware für DRAM-Initialisierung
+            liegt in separatem Speicher, wird von separatem µC ausgeführt
+          - Auf dem Modem läuft proprietäre Software.
+            Dies ist rechtlich auch nicht anders möglich.
+       - Auf beiden Systemen läuft Standard-Linux,
+         normalerweise mit einer Oberfläche, die für den Gebrauch
+         als Smartphone angepaßt ist (z.B. Phosh).
+       - Es existiert ein Android-basiertes System für das Pinephone,
+         direkt auf AOSP basierend, ohne LineageOS:
+         https://github.com/GloDroid/glodroid_manifest
+       - Es existiert ein Android-Emulator für Linux mit Wayland: waydroid
+         Damit könnte man Android-Apps auf freien Smartphones unter Linux ausführen.
+         (Laufendes Projekt: Corona-Warn-App unter Linux)
+       - Die Treiber enthalten weiterhin proprietäre BLOBs:
+         Laut https://www.pine64.org/2020/01/24/setting-the-record-straight-pinephone-misconceptions/
+         folgendes: WiFi+Bluetooth firmware, optionale Autofokus-Firmware für
+         die rückseitige Kamera und das Betriebssystem auf dem Quectel EG25-G
+         LTE Modem ist auch unfrei. Wifi benutzt SDIO, Bluetooth UART zur
+         Kommunikation.
+         Für das Modem gibt es inzwischen eine Firmware, die in großen Teilen frei ist:
+         https://gnulinux.ch/hacker-entwickeln-open-source-firmware-fuer-das-pinephone-modem
+         (der Teil, der auf dessen CPU läuft, die Software für den DSP, der
+         direkt mit dem Mobilfunknetz spricht, ist aber unfrei). Laut gerade
+         genanntem Artikel ist es aber rechtlich nicht zulässig, diese Firmware
+         vorzuinstallieren, im Zweifel geschieht also das Einstecken einer
+         SIM-Karte danach auf eigene Gefahr.
+       - Kein DMA-artiger Zugriff der proprietären Module auf den Hauptspeicher möglich.
+         (Bei Android: Modem spricht direkt mit Lautsprecher und Mikrofon.)
+      --> enormer Gewinn an Kontrolle über die Hardware
+
+ * Wieviel digitale Souveränität kann man gewinnen?
+    - Auf Push-Server achten!
+    - Auf proprietäre Treiber achten!
+    - Auf vorinstallierte Apps achten!
+    - Freie Smartphones nutzen.