Skip to content
Snippets Groups Projects
Commit ddf2f60e authored by Peter Gerwinski's avatar Peter Gerwinski
Browse files

Notizen 20.6.2022

parent 8b778f0f
Branches 2022ss
No related tags found
No related merge requests found
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.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment