Timing-Angriff auf einen Post-Quanten-Kryptoalgorithmus

Artikel von am

Hier eine weitere Arbeit aus meinem Studium. Ein relevantes Forschungsgebiet in der Kryptografie ist gegenwärtig die Entwicklung von Algorithmen, die auch in Gegenwart eines Quantencomputers sicher sind. Aktuell läuft ein Standardisierungsverfahren beim NIST (National Institute of Standards and Technology) der USA. In diesem Verfahren wurden über 60 Vorschläge solcher Algorithmen, bestehend aus einer theoretischen Beschreibung und einer Referenzimplementierung, eingereicht. Die Einreichungen stammen aus Forschungsgruppen aus aller Welt.

Ich habe die Referenzimplementierung eines Kandidaten ausgewählt und diese daraufhin untersucht, ob sie anfällig gegen implementierungsspezifische Angriffe ist. Dabei habe ich einen theoretischen Ansatzpunkt für einen Timing-Angriff entdeckt. Alles weitere hier:

timing-post-quantum.pdfHerunterladen

Sicherheitsmechanismen von Bluetooth Low Energy

Artikel von am

Dieser Beitrag ist mal wieder eine Zweitverwertung. Im Rahmen meines Studiums habe ich einen Text über die Sicherheitsmechanismen von Bluetooth Low Energy geschrieben. Warum muss man eigentlich sechsstellige Zifferncodes abtippen oder miteinander vergleichen? Und was bedeutet es für die Sicherheit, wenn man das (nicht) machen muss?

Die Arbeit gibt einen Überblick über den Protocol Stack, die Sicherheitsmechanismen und einige Schwächen. Weil ich es immer ein bisschen schade finde, wenn solche Texte nach der Abgabe in der Schublade verschwinden, veröffentliche ich den Text hier für alle Interessierten. Viel Spaß beim Lesen!

„Sicherheitsmechanismen von Bluetooth Low Energy“ weiterlesen »

Backups mit Tarsnap

Artikel von am

Vor einiger Zeit kam es bei meinem (inzwischen ehemaligen) Hoster zu einem Problem mit dem RAID des Storage, auf dem die virtuelle Festplatte meines vServers lag. Das Resultat war ein korruptes Dateisystem in meiner VM; ich konnte es zwar teilweise wieder reparieren, allerdings blieben einige Schäden, einige Dateien blieben verschollen oder wurden beim Reparaturvorgang falschen Dateinamen zugeordnet. Kurzum, ein Großteil des Dateisystems war zwar noch da, es reichte aber nicht aus, um mein Ubuntu-Server-System zu booten – und mein Vertrauen in die auf den ersten Blick intakten Überreste hielt sich ebenfalls in Grenzen.

Also war es an der Zeit, das Backup aus der Schublade zu holen. Ich hatte erst zwei Wochen zuvor mein altes Konzept, gpg-verschlüsselte Files per rsync auf einen externen Speicher zu schieben, durch den Service Tarsnap ersetzt. Tarsnap verschlüsselt die Daten lokal auf dem Server und schiebt sie dann in den gleichnamigen Onlinespeicher, der auf Amazon S3 basiert. Dabei kommt eine Deduplikation zum Einsatz, was es recht günstig macht, viele Versionen des Datenbestands aufzubewahren. Das dazugehörige Kommandozeilentool tarsnap ist – dank der guten Dokumentation auf der Website und der Manpage – recht einfach zu bedienen. Per Cronjob mache ich jeden Morgen ein neues, automatisches Backup meines vServers, und von Zeit zu Zeit lösche ich manuell mal die alten Snapshots weg.

Die letzte Version meines Tarsnap-Backups enthielt daher den Stand ein paar Stunden vor dem Crash. Also habe ich mir einen neuen vServer geklickt, die Basiseinrichtung durchgeführt, Tarsnap installiert, meinen Tarsnap-Key auf den neuen Server übertragen und die Wiederherstellung angestoßen.

Ich hatte nicht das gesamte Filesystem des alten Servers gesichert, sondern nur die Dateien der Webapplikationen und jeweils zum Backupzeitpunkt generierte Dumps der zugehörigen Datenbanken. Das Zurückspielen hat hervorragend funktioniert.

Insofern ist mein Backupkonzept jetzt unfreiwilligerweise praxiserprobt, sodass ich sagen kann: Tarsnap hat mir mal den Kopf gerettet – kann ich empfehlen!

Entwürfe

Artikel von am

Hin und wieder – meistens recht spät abends – packt mich der Gedanke, dass ich ja mal wieder einen Blogpost schreiben müsste. Meistens habe ich dann auch schon eine konkrete Idee im Kopf. Ich logge mich ins Backend ein und beginne mit dem Schreiben. Es wird später und später und irgendwann ist der „Ach, kannste eigentlich auch morgen weitermachen“-Punkt erreicht – was dann gelegentlich nicht passiert.

So geschah es auch heute wieder. Eigentlich wollte ich einen neuen Blogpost erstellen. Auf dem Weg in den WordPress-Editor habe ich im Backend aber noch ein wenig unveröffentlichtes, exklusives Material entdeckt. Deshalb kommen jetzt erst mal die ollen Kamellen, der „neue“ Artikel folgt dann die Tage – den hätte ich ohnehin noch nicht veröffentlichen, sondern nur vorbereiten können.

Außerdem habe ich endlich den schon lange existierenden Twitter-Account @returnfalsede mithilfe von IFTTT mit dem Blog verknüpft, sodass neue Posts ab sofort auch dort erscheinen sollten. Dafür ist dieser Beitrag ein Testballon. Ich bin gespannt.

Mail-Backups mit Getmail

Artikel von am

Meine E-Mail-Konten rufe ich für gewöhnlich per IMAP ab. Das ist zwar einerseits komfortabel, weil auf all meinen Geräten derselbe Stand vorhanden ist, andererseits bin ich natürlich von der Verfügbarkeit des Mailservers und dem Ausbleiben technischer Pannen beim jeweiligen Provider abhängig. Hinzu kommt das Risiko versehentlich gelöschter E-Mails.

Aus diesem Grund habe ich mir mithilfe von Getmail 5.4 eine eine Archivierung auf meinem Homeserver gebastelt. Diese läuft alle paar Stunden, holt neue Mails aus den Postfächern ab und speichert sie in einem lokalen Maildir. Dabei werden ungelesene Mails nicht als gelesen markiert und es werden auch keine Mails auf dem Server gelöscht. Das einzige Problem, das ich noch nicht lösen konnte: Wenn ich eine Mail in einen anderen IMAP-Ordner verschiebe, lädt Getmail sie erneut herunter. Aber damit kann ich leben.

Ich habe dazu folgende Ordnerstruktur und einige Dateien angelegt:

/data/mail
├── getall.sh
├── getall.log
├── example@gmail.com
│   ├── conf
│   │   └── getmailrc
│   ├── log
│   │   └── getmail.log
│   └── maildir
│       ├── cur
│       ├── new
│       └── tmp
├── me@example.com
│   ├── conf
│   │   └── getmailrc
│   ├── log
│   │   └── getmail.log
│   └── maildir
│       ├── cur
│       ├── new
│       └── tmp
└── <weitere E-Mail-Adressen>
    └── …

getall.sh ruft Getmail mit den entsprechenden Konfigurationsdateien pro Unterverzeichnis auf:

#!/bin/bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
echo "Script run $(date)"
for i in ${DIR}/*/conf
do
    echo $i
    cd $i
    getmail -g./
done
echo "-------------------"

Ich rufe getall.sh einmal am Tag via cron auf.

0 3 * * * /bin/bash /data/mail/getall.sh >> /data/mail/getall.log 2>&1

Für die Gmail-Adresse sieht meine Getmail-Konfiguration getmailrc wie folgt aus:

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = example@gmail.com
password = PASSWORD1234
mailboxes = ALL
use_peek = true

[destination]
type = Maildir
path = /data/mail/example@gmail.com/maildir/

[options]
verbose = 1
message_log = /data/mail/example@gmail.com/log/getmail.log
read_all = false

Die heruntergeladenen Mails landen als einzelne Dateien in maildir/new. Die IMAP-Ordnerstruktur geht dabei zunächst verloren, ist in den Mail-Dateien aber in einem zusätzlichen Header-Feld X-getmail-retrieved-from-mailbox noch vermerkt, sodass man sie bei Bedarf schon rekonstruieren könnte.