Shared-Secrets: Geheimnisse über verschlüsselte Links austauschen

28.09.2016 yahe code legacy linux security

Im Internet gibt es inzwischen eine größere Anzahl an Diensten, über die es möglich ist, Texte auszutauschen, der bekannteste davon dürfte wohl Pastebin.com sein. Einige davon haben zudem begonnen, damit zu werben, dass man über sie Geheimnisse austauschen kann, die wahlweise verschlüsselt auf dem Server abgelegt werden oder nur einen einzigen Abruf des Geheimnisses ermöglichen, beispielsweise OneTimeSecret.com.

Auf Arbeit haben wir vor kurzem nach einer Möglichkeit gesucht, Informationen möglichst sicher an einen Empfänger zu übertragen, ohne, dass auf dessen Seite Software installiert werden oder eine spezifische Konfiguration vorgenommen werden muss. Dabei bot sich solch ein einfacher Webdienst regelrecht an. Allerdings sahen wir die vorhandenen Lösungen als eher kritisch an. Denn obwohl ein Passwortschutz besteht, werden die Informationen meistens unverschlüsselt auf dem Server abgelegt. Dadurch hat der entsprechende Betreiber die Möglichkeit, auf sie zuzugreifen und somit auch jeder Hacker, dem es gelingt, in den jeweiligen Dienst einzudringen. Eine zusätzliche Verschlüsselung wiederum würde die Hürde auf der Seite des Empfängers wieder erhöhen. Eine Alternative musste her.

Also begann ich damit, eine neue Lösung zu implementieren. Das Ergebnis der Entwicklung wurde als Shared-Secrets auf Github veröffentlicht. Zudem ist in unserem Firmenblog ein begleitender Artikel veröffentlicht worden.

Im Gegensatz zu den üblichen Lösungen im Netz haben wir dabei auf mehrere Faktoren Wert gelegt:

  1. Die Geheimnisse sollen nicht auf dem Server gespeichert werden.
  2. Die Geheimnisse sollen nur ein Mal abrufbar sein, um einen Vertraulichkeitsverlust erkennen zu können.
  3. Es muss möglich sein, ein Geheimnis zu teilen, ohne, dass der Server es lesen kann.
  4. Es muss möglich sein, ein Geheimnis zu teilen, ohne, dass der Server bei der Verteilung involviert ist.

Dabei herausgekommen ist folgende Lösung: Das zu teilende Geheimnis wird via GPG verschlüsselt und Base64-encodiert. Der Base64-encodierte String wird in eine URL überführt. Bei Aufruf der URL wird der Base64-encodierte String an einen Server übertragen, der ihn decodieren und entschlüsseln kann. Das entschlüsselte Ergebnis wird anschließend angezeigt. Die Prüfsumme des Base64-encodierten Strings wird in einer Datenbank abgelegt. Zudem besteht die Möglichkeit, das Geheimnis vor dem Versand an den Server symmetrisch zu verschlüsseln und nach dem Abruf vom Server wieder zu entschlüsseln.

Auf diese recht einfache Weise konnten alle Designziele erfüllt werden:

  1. Dadurch, dass das verschlüsselte Geheimnis direkt in der URL enthalten ist, muss es nicht auf dem Server gespeichert werden. Auch nach einem Abruf wird lediglich die Checksumme der URL und nicht das eigentliche Geheimnis gespeichert.
  2. Durch das Speichern der Checksummen von bereits abgerufenen URLs ist es möglich, zu erkennen, wenn ein Geheimnis mehrfach abgerufen werden soll. Dieser Abruf kann dann unterbunden werden.
  3. Mit der Möglichkeit, ein Geheimnis zusätzlich lokal zu ver- und entschlüsseln, besteht die Möglichkeit, ein Geheimnis auszutauschen, ohne, dass der Server dieses im Klartext lesen kann. Das verwendete Passwort kann bspw. über einen zweiten Kanal übertragen werden.
  4. Dadurch, dass für die Erstellung der URL Standardverfahren eingesetzt werden, können diese lokal mit Hilfe einer einzelnen Shell-Befehlszeile erzeugt werden. Das erspart zudem die Bereitstellung einer API.

Ein weiterer Vorteil der gewählten Lösung ist, dass der Speicherbedarf recht gering ausfällt. Es müssen im Grunde nur die Checksummen der tatsächlich abgerufenen Geheimnisses gespeichert werden. Geheimnisse, für die URLs erzeugt wurden, die aber nicht abgerufen werden, verbrauchen daher im Umkehrschluss auch keinen Speicherplatz.

Getestet werden kann die Anwendung unter secrets.syseleven.de, der Referenzinstallation der Anwendung. Über sie wird auch sichergestellt, dass es möglich ist, mit einem korrekten Setup ein A+ Rating im Mozilla Observatory zu erhalten.


CentOS 7 mit Two-Factor-Authentication absichern

11.08.2016 yahe administration legacy linux security

Nach meiner Migration zu CentOS 7 wollte ich Two-Factor-Authentication für SSH-Logins einrichten. Allerdings musste ich feststellen, dass es für CentOS 7 keine aktuellen Pakete des entsprechenden PAM (Pluggable Authentication Module) gibt. So musste ich wohl oder übel das ganze selbst kompilieren. Bevor man jedoch loslegen kann, benötigt man zuerst einmal ein paar zusätzliche Pakete:

sudo yum install autoconf automake libtool make pam-devel unzip wget zip

Nun können wir mit der eigentlichen Installation beginnen:

wget https://github.com/google/google-authenticator/archive/master.zip
unzip ./master.zip
cd ./google-authenticator-master/libpam
./bootstrap.sh
./configure

Bis hierhin sollte alles funktioniert haben. Leider enthält die erstellte Konfiguration einen kleinen Fehler. Deshalb müssen wir händisch an den Anfang der Datei "./Makefile" folgende Zeile einfügen:

LDFLAGS="-lpam"

Nun kann es mit dem Kompilieren weitergehen:

make
sudo make install
sudo cp /usr/local/lib/security/pam_google_authenticator.so /lib64/security
make clean
cd ../..
rm ./master.zip
rm -R ./google-authenticator-master

Um die Nutzer zu markieren, für die die Two-Factor-Authentication aktiviert werden soll, legen wir eine Gruppe "google-auth" an:

sudo groupadd google-auth

Zudem ändern wir in der Datei "/etc/ssh/sshd_conf" eine Einstellung:

ChallengeResponseAuthentication yes

Danach schreiben wir folgendes in die Datei "/etc/pam.d/sshd" (z.B. unter die restlichen "auth"-Einträge):

auth [success=1 default=ignore] pam_succeed_if.so user notingroup google-auth
auth required pam_google_authenticator.so

Mit einem Restart des SSH-Servers sind die Änderungen aktiv:

sudo systemctl restart sshd.service

Nun müssen die Nutzer, für die die Two-Factor-Authentication aktiviert werden soll, das Skript zur Einrichtung der Two-Factor-Authentication in ihrem Account aufrufen:

google-authenticator

Abschließend müssen diese Nutzer noch in die Gruppe "google-auth" aufgenommen werden:

sudo usermod -a -G google-auth <username>

Das war's! Mit diesen Schritten lässt sich unter CentOS 7 eine Two-Factor-Authentication einrichten.


PHP 7 unter CentOS 7 installieren

09.08.2016 yahe administration legacy linux

Ich bin inzwischen mit allen Servern zu CentOS migriert. Das Gute an CentOS ist, dass es eine recht stabile Distribution ist und jedes Major Release 10 Jahre lang Support erhält. Das Schlechte an CentOS ist, dass viele Pakete dadurch in einer recht alten Version vorliegen, die lediglich mit Bug- und Security-Fixes versorgt werden. Bei meinen Webserverinstallationen möchte ich hingegen lieber neue Versionen betreiben, um neue Features zu erhalten.

Bei der Installation einer neueren Version hat man mehrere Möglichkeiten. Entweder, man kompiliert PHP 7 selbst oder man setzt ein Dritt-Repository ein, in dem bereits vorkompilierte Pakete für PHP 7 enthalten sind. In diesem Fall habe ich mich für zweiteres entschieden. Mit ius.io gibt es für CentOS 7 ein Repository, in dem die wichtigsten Pakete enthalten sind und das aufgrund der Unterstützung durch den Hoster Rackspace lange erhalten bleiben sollte. Um das Repository von IUS verwenden zu können, muss man im ersten Schritt deren RPM-Paket installieren, das sich darum kümmert, das Repository im System einzukonfigurieren:

wget "https://centos7.iuscommunity.org/ius-release.rpm"
sudo rpm -i ./ius-release.rpm
rm ./ius-release.rpm

Zusätzlich muss noch der öffentliche Schlüssel importiert werden, mit dessen Hilfe die Signaturen der heruntergeladenen Pakete überprüft werden können:

sudo rpm --import /etc/pki/rpm-gpg/IUS-COMMUNITY-GPG-KEY

Wenn man es noch nicht getan hat, sollte man weiterhin das EPEL-Repository mit einbinden, das weitere hilfreiche und meist aktuellere Software enthält. Das lässt sich durch die Softwareverwaltung realisieren:

sudo yum install epel-release

In meinem Fall installiere ich neben PHP auch immer gleich MariaDB und NGINX. Das IUS-Repository enthält auch eine aktuellere Version von MariaDB. Damit man diese installieren kann, müssen jedoch vorher die bereits vorhandenen "mariadb-libs" entfernt werden. Im Zuge dessen wird auch Postfix deinstalliert. Wir werden es einfach im Anschluss erneut installieren:

sudo yum remove mariadb-libs

Nun können wir die gewünschte Software über die Softwareverwaltung installieren. Pakete, die über IUS installierten werden, enthalten immer den Suffix "u", um sie leichter erkennen zu können und Kollisionen mit Standardpaketen zu vermeiden:

sudo yum install mariadb101u-server nginx php70u-cli php70u-fpm php70u-gd php70u-imap php70u-intl php70u-json php70u-ldap php70u-mbstring php70u-mcrypt php70u-mysqlnd php70u-pdo php70u-pear php70u-pgsql php70u-process php70u-pspell php70u-recode php70u-soap php70u-xml php70u-xmlrpc postfix

Aktive Verteidigung gegen Krypto-Trojaner

29.02.2016 yahe code legacy security thoughts

Mit Locky sieht die IT-Welt derzeit einen der koordiniertesten Trojanerangriff der jüngeren Zeit. Während er sich Anfangs als Schläfer getarnt haben soll, findet er inzwischen auf unterschiedlichsten Wegen sein Ziel: als Word- oder Excel-Dokument mit schädlichem Makro; als JavaScript-Datei, die sich z.B. als angebliches Sipgate-Fax tarnt; oder gar als altmodische und als ausgestorben geglaubte Batch-Datei. Bei den Opfern des Verschlüsselungstrojaners handelt es sich auch um größere Organisationen wie Krankenhäuser und ein Fraunhofer-Institut. Man ging zeitweise von 5000 Neuinfektionen pro Stunde aus.

Die Vorschläge für Gegenmaßnahmen sehen derzeit noch eher mager aus. Die einen raten zur Symptombekämpfung durch Backups, deaktivierte Makros und Virenscannern. Andere wiederum versuchen, den Krypto-Trojaner anhand seiner Funktionsweise zu erkennen und so eine Anti-Malware-Software auf Heuristikbasis zu entwickeln.

Um sich erfolgreich gegen solch einen Trojanerangriff zur Wehr zu setzen, muss man jedoch an mehreren Baustellen aktiv werden und anstatt unterschiedlichste Teilmaßnahmen einzuführen, sollte man sich überlegen, welche Kombination von Maßnahmen zu einem ganzheitlichen Schutz führen kann. Die folgende Auflistung soll dabei eine kleine Hilfestellung für einen aktiven Umgang mit solch einem Infektionsrisiko bieten. Das folgende Dreiergespann aus Vermeidung, Erkennung und Behebung ist auch in der Medizin durchaus weit verbreitet.

Zuerst einmal sollte man natürlich das Thema Vermeidung betrachten. Hierzu zählen Dinge wie das Deaktivieren der Makrofunktion in Office-Anwendungen und die Aufklärung von Mailnutzern darüber, dass Office-Anhänge von außen nicht zu öffnen und ZIP-Dateien von außen nicht zu entpacken sind. Auch das Deaktivieren von JavaScript auf exponierten Arbeitsplätzen oder gar der Wechsel auf ein Betriebssystem mit konsequenter Trennung von Ausführungsrechten und Dateinamen kann eine Option darstellen.

Anschließend sollte man sich darum kümmern, eine Erkennung eines erfolgreichen Angriffs zu ermöglichen. Erst, wenn eine Infektion erkannt werden kann, kann sie im Anschluss auch behoben werden. Leider ist es noch häufig so, dass eine Erkennung lediglich durch Virenscanner erfolgt. Diese sind jedoch so spezifisch an einzelne Schädlinge und deren Verhalten angepasst, dass neue Generationen häufig für längere Zeit unentdeckt bleiben. Anstatt Verhaltensmuster der Schädlinge zu untersuchen, ist es daher sinnvoller, Standardverhaltensmuster seiner Mitarbeiter zu aggregieren und Abweichungen von diesem Standardverhalten in einem Sicherheitsmonitoring zu sammeln. So ist es möglich, auch neue Schädlinge anhand eines vom Durchschnitt abweichenden Verhaltens zu erkennen. Beispielsweise könnte zum Erkennen eines Krypto-Trojaners die durchschnittliche Anzahl an neu erstellten, bearbeiteten und gelöschten Dateien pro Tag herhalten. Während ein typischer Büroarbeiter eher selten viele Dateien gleichzeitig anlegt und gleichzeitig viele Dateien löscht, ist genau das das Hauptgeschäft von Krypto-Trojanern. Solch eine Erkennung von Abweichungen kann mit Canaries ergänzt werden. Dabei handelt es sich um Dateien, die extra als Opfer für einen Verschlüsselungstrojaner bereitgestellt werden und deren Bearbeitung als ein eindeutiges Indiz für das Vorhandensein eines Krypto-Trojaners dienen kann. Das Ziel der Erkennung ist es, von einem Problem zu erfahren, noch bevor der Nutzer etwa Ungewöhnliches feststellt.

Abschließend muss das Thema der Behebung betrachtet werden. Hierzu zählen an erster Stelle regelmäßige Backups. Das häufig kommunizierte Mantra, Dateien auf einem externen Datenträger zu sichern und diesen anschließend wieder vom Computer zu trennen, stellt in den meisten Umgebungen keinen ausreichenden Schutz dar. Denn während des Backups kann auch der externe Datenträger befallen und verschlüsselt werden. Der eigentliche Wunsch hinter solch einer Aussage ist vielmehr, eine Sicherung zu erstellen, die von einer eventuellen Infektion nicht beeinflusst werden kann. Sinnvolle Varianten können hierbei extern durchgeführte Backups sein, die nicht vom infizierten Nutzer angestoßen und demnach auch nicht vom infizierten Nutzer modifiziert werden können. Auch lokale Backups unter der Hoheit eines anderen Systemnutzers stellen eine Möglichkeit dar. Noch sinnvoller als ein einfaches Backup ist eine Versionierung, die zwar mehr Speicherplatz benötigt, dafür aber auch eine selektive Wiederherstellung von Dateiinhalten unterschiedlichster Zeitpunkte ermöglicht.

Die Implementierung eines entsprechenden Schutzes ist auch mit einfachen Tools möglich, wobei speziell entwickelte Werkzeuge wesentlich mehr Komfort bieten können. Im Folgenden soll eine Erkennung und Behandlung eines Krypto-Trojaner-Angriffs mit Hilfe von Mercurial dargestellt werden. Anbei folgt ein beispielhaftes Skript zur Erkennung von Abweichungen in der Bearbeitung von Dateien. Das Script ermittelt Abweichungen von der durchschnittlichen Menge an erstellten/gelöschten/bearbeiteten Dateien. Zudem prüft es separat die Veränderung eines Canaries. Das Script ist nur als Proof-of-Concept eines dateiorientierten, Host-basierten, sowie Anomalie-basierten Intrusion Detection Systems zu verstehen.

#!/usr/bin/php
<?php
  // user-defined values
  define("CHECKFOLDER", "/testpit/");
  define("CHECKCANARY", CHECKFOLDER . "data/do-not-edit.txt");
  define("STATUSFILE",  CHECKFOLDER . "status/status");

  // deviation of user behaviour from previously collected behaviour
  define("DEVIATIONVALUE", 0.5); // default deviation of 50% is allowed

  // generated values
  define("CHECKDATE", date("Ymd-His"));

  // concatenated actions
  define("ADDREMOVECMD", "hg addremove -R \"" . CHECKFOLDER . "\" -X \"" . CHECKCANARY . "\"");
  define("COMMITCMD",    "hg commit -R \"" . CHECKFOLDER . "\" -X \"" . CHECKCANARY . "\" -m \"" . CHECKDATE . "\"");
  define("STATUSCMD",    "hg status -R \"" . CHECKFOLDER . "\"");

  // static definitions
  define("ADDEDHINT",     "A");
  define("MISSINGHINT",   "!");
  define("MODIFIEDHINT",  "M");
  define("NOTTRACKEDHINT","?");
  define("REMOVEDHINT",   "R");

  define("HINTDELIMITER",       " ");
  define("STATISTICSDELIMITER", ":");

  function check_filename($line, $filename) {
    $result = false;

    $parts = explode(HINTDELIMITER, $line, 2);
    if ((false !== $parts) && (2 === count($parts))) {
      $result = (0 == strcasecmp(CHECKFOLDER . $parts[1], $filename));
    }

    return $result;
  }

  function check_hint($line, $hint) {
    $result = false;

    $parts = explode(HINTDELIMITER, $line, 2);
    if ((false !== $parts) && (2 === count($parts))) {
      $result = (0 == strcasecmp($parts[0], $hint));
    }

    return $result;
  }

  function get_statistics_text($additions, $deletions, $modifications) {
    return (CHECKDATE . STATISTICSDELIMITER . ADDEDHINT . STATISTICSDELIMITER . $additions .
                        STATISTICSDELIMITER . MODIFIEDHINT . STATISTICSDELIMITER . $modifications .
                        STATISTICSDELIMITER . REMOVEDHINT . STATISTICSDELIMITER . $deletions);
  }

  function check_statistics($additions, $deletions, $modifications) {
    $result = true;

    // with any modification there's nothing to check
    if (0 < ($additions + $deletions + $modifications)) {
      // read statistics and execute statistics checkvg_additions_count     = 0;
      $avg_additions_count     = 0;
      $avg_additions_value     = 0;
      $avg_deletions_count     = 0;
      $avg_deletions_value     = 0;
      $avg_modifications_count = 0;
      $avg_modifications_value = 0;

      if (is_file(STATUSFILE)) {
        $statistics = file(STATUSFILE, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
        if ((false !== $statistics) && (0 < count($statistics))) {
          // calculate average additions, deletions and modifications from statistics data
          foreach ($statistics as $line) {
            $parts = explode(STATISTICSDELIMITER, $line, 7);
            if ((false !== $parts) && (7 === count($parts))) {
              // check if value is integer and bigger than 0
              if (is_numeric($parts[2]) && (0 < $parts[2])) {
                $avg_additions_value += $parts[2];
                $avg_additions_count++;
              }
              if (is_numeric($parts[6]) && (0 < $parts[6])) {
                $avg_deletions_value += $parts[6];
                $avg_deletions_count++;
              }
              if (is_numeric($parts[4]) && (0 < $parts[4])) {
                $avg_modifications_value += $parts[4];
                $avg_modifications_count++;
              }
            }
          }
        }
      }

      // there's nothing wrong when nothing happened
      if (0 < $additions) {
        // when actions has never been seen then that's a deviation
        if (0 === $avg_additions_count) {
          $result = false;
        } else {
          // more additions than expected
          if (((1.0 + DEVIATIONVALUE) * ($avg_additions_value / $avg_additions_count)) < $additions) {
            $result = false;
          }
        }
      }

      // there's nothing wrong when nothing happened
      if (0 < $deletions) {
        // when actions has never been seen then that's a deviation
        if (0 === $avg_deletions_count) {
          $result = false;
        } else {
          // more deletions than expected
          if (((1 + DEVIATIONVALUE) * ($avg_deletions_value / $avg_deletions_count)) < $deletions) {
            $result = false;
          }
        }
      }

      // there's nothing wrong when nothing happened
      if (0 < $modifications) {
        // when actions has never been seen then that's a deviation
        if (0 === $avg_modifications_count) {
          $result = false;
        } else {
          // more modifications than expected
          if (((1 + DEVIATIONVALUE) * ($avg_modifications_value / $avg_modifications_count)) < $modifications) {
            $result = false;
          }
        }
      }
    }

    // add new result to statistics
    file_put_contents(STATUSFILE,
                      get_statistics_text($additions, $deletions, $modifications) . "\n",
                      FILE_APPEND | LOCK_EX);

    return $result;
  }

  function main() {
    $additions     = 0;
    $deletions     = 0;
    $modifications = 0;

    $canary_found = false;

    // retrieve information about file changes
    exec(STATUSCMD, $output);

    // accept file changes right away
    exec(ADDREMOVECMD);
    exec(COMMITCMD);

    // iterate through file changes
    foreach ($output as $line) {
      // check if the canary file is part of the modifications
      if (check_filename($line, CHECKCANARY)) {
        $canary_found = true;
      } else {
        // check if a file has been added
        if (check_hint($line, ADDEDHINT) || check_hint($line, NOTTRACKEDHINT)) {
          $additions++;
        } else {
          // check if a file has been deleted
          if (check_hint($line, MISSINGHINT) || check_hint($line, REMOVEDHINT)) {
            $deletions++;
          } else {
            // check if a file has been modified
            if (check_hint($line, MODIFIEDHINT)) {
              $modifications++;
            }
          }
        }
      }
    }

    if (0 < ($additions + $deletions + $modifications)) {
      // accept file changes
      exec(ADDREMOVECMD);
      exec(COMMITCMD);
    }

    // print result
    print(get_statistics_text($additions, $deletions, $modifications) . "\n");

    // the canary has been modified
    if ($canary_found) {
      //!!! do something
      print("ALERT! CANARY HAS BEEN MODIFIED!\n");
    }

    // check if the modifications do not match the statistics
    if (!check_statistics($additions, $deletions, $modifications)) {
      //!!! do something
      print("ALERT! BEHAVIOUR DOES NOT MATCH STATISTICS!\n");
    }
  }

  // execute application
  main();

?>

Bei jedem Aufruf ermittelt das Script mit Hilfe von Mercurial, welche Dateien in einem Repository/Ordner hinzugefügt, entfernt oder bearbeitet wurden. Sollte sich darunter die Canary-Datei befinden, wird Alarm geschlagen. Zudem wird eine statistische Analyse durchgeführt. In diesem einfachen Beispiel gilt als Abweichung, wenn mehr als 150% der durchschnittlichen Dateioperationen erkannt wurden. Wird solch eine Abweichung erkannt, wird ebenfalls Alarm geschlagen. Durch die Verwendung von Mercurial ließen sich zudem zu jeder Zeit alle bearbeiteten Dateien rekonstruieren.

In einem realen Umfeld könnte solch eine Analyse natürlich noch viel tiefergreifend sein. So könnten beispielsweise folgende Prüfungen mit einfließen, um Anomalien besser erkennen zu können:

  • Es könnte die Uhrzeit der Dateibearbeitung mit in die Analyse einfließen. In Kombination mit der Auswertung von Arbeitsplänen und/oder Anwesenheitszeiten ließen sich bessere Modelle erstellen. So sollte es seltener der Fall sein, dass Dateien eines Mitarbeiters bearbeitet werden, der gar nicht anwesend ist.
  • Es könnte die Relation der Dateibearbeitungen untereinander betrachtet werden. Beispielswiese werden Büromitarbeiter wesentlich mehr Dateien erstellen und bearbeiten als löschen, da Arbeitsergebnisse selten wieder vernichtet werden.
  • Es könnte das ursprüngliche Dateidatum mit berücksichtigt werden. Beispielsweise ist es eher unüblich, dass Dateien ab einem bestimmten Alter noch einmal bearbeitet werden. Stattdessen werden sie eher als Referenz vorgehalten, anstatt als aktives Arbeitsdokument zu fungieren.

Je besser das erstellte Modell ist, mit dem das Verhalten der Systemnutzer abgeglichen wird, desto schneller erkennt man in Ausnahmesituationen einen potentiellen Angreifer. Nicht immer müssen das externe Angreifer sein. Auch interne Mitarbeiter, die ein ungewöhnliches Verhalten an den Tag legen, können auf diese Weise unter Umständen identifiziert werden. Es muss nicht einmal zwingend eine böse Absicht hinter diesem Verhalten stecken, evtl. stellt ein Mitarbeiter einfach eine Ausnahme zur üblichen Regel dar.

Generell sollte man sich bei solch einer Angriffserkennung auf Basis von Abweichungsermittlungen daran gewöhnen, auch False Positives zu erhalten. Diese sind durchaus wünschenswert, da sie einerseits zeigen, dass die durchgeführten Analysen tatsächlich einen Effekt haben und einem andererseits Verbesserungspotentiale in den erstellten Anomaliemodellen aufzeigen.


3D-Barcodes mit Farbfiltern auslesen...

18.01.2016 yahe legacy thoughts

Bereits vor einer ganzen Weile hatte ich mal mit Licht und Farbfiltern herum experimentiert. Damals hatte ich mit Hilfe von Farbfiltern das Licht aufgespalten, das von einer RGB-LED emittiert wurde und dabei auch erwähnt, dass man auf Basis dieser Bündelung Daten übertragen könne.

Einige Zeit später war ich auf der Suche nach einer Möglichkeit, Binärdaten über ein Druckerzeugnis zu übertragen. Dabei denkt man heutzutage natürlich erst einmal an 2D-Barcodes (z.B. Aztec-Codes, Matrix-Codes oder die allseits bekannten QR-Codes). Leider reichte deren Datendichte nicht aus. In ähnlichen Fällen werden deshalb gelegentlich 3D-Barcodes (z.B. der "HCCB"-Code von Microsoft) eingesetzt. Diese funktionieren, indem zusätzlich zu den beiden Dimensionen Höhe und Breite noch die dritte Dimension der Farbe eingeführt wird. Allerdings benötigen solche 3D-Barcodes typischerweise mehrere Dinge:

  1. Eine Lizenz, um das Verfahren nutzen zu dürfen.
  2. Stark angepasste Lesegeräte und/oder Erkennungsalgorithmen.

In dem Moment dachte ich an das Experiment mit den Farbfiltern zurück. Wenn man es hinbekäme, die Komplexität des Barcode-Lesens und die Komplexität des gesteigerten Farbraums voneinander zu trennen, könnte man einfach reproduzierbare Barcodes erzeugen, die gleichzeitig mit vorhandenen Standardmitteln lesbar wären. Geboren war der kombinierte Farb-Barcode.

kombinierter Farb-Barcode

Herstellen lässt er sich recht einfach:

  1. Man nimmt sich zwei normale 2D-Barcodes und legt diese übereinander.
  2. Pixel, die in beiden Barcodes vorkommen, werden schwarz gefärbt.
  3. Pixel, die in keinem der beiden Barcodes vorkommen, werden weiß gefärbt.
  4. Pixel, die nur im ersten Barcode vorkommen, werden mit einer Farbe A eingefärbt.
  5. Pixel, die nur im zweiten Barcode vorkommen, werden mit einer Farbe B eingefärbt.

Gedanken machen muss man sich nun darum, wie man die Barcodes wieder getrennt bekommt. Dafür ist es wichtig, Farbe A und Farbe B richtig zu wählen. Diese beiden Farben müssen eine Beziehung zueinander haben, die sich wie folgt beschreiben lässt:

  1. Wenn Farbe A durch einen Farbfilter der Farbe B betrachtet wird, muss ein möglichst starker Farbkontrast entstehen.
  2. Wenn Farbe B durch einen Farbfilter der Farbe A betrachtet wird, muss ein möglichst starker Farbkontrast entstehen.

Glücklicherweise hatte ich Farbfilter zuhause, die diese beiden Bedingungen erfüllen, rote und blaue:

roter und blauer Farbfilter

Wichtig für einen produktiven Einsatz ist, dass die Farbfilter und die für den Druck verwendeten Farben aufeinander abgestimmt werden. Im Haushaltsgebrauch wird man das nicht unbedingt hinbekommen, weshalb das Auslesen des Barcodes im selbstgebastelten Umfeld wohl mehr Geduld erfordert, als es im professionellen Umfeld der Fall wäre.

gedruckter Farb-Barcode

Um nun den Inhalt der Barcodes auslesen zu können, platziert man einen Farbfilter vor der Kamera und scannt den Code. Anschließend tauscht man den Farbfilter vor der Kamera aus und scannt den Code erneut (sogenanntes "shuttern"). Eine Alternativmöglichkeit ist, zwei Kameras gleichzeitig zu verwenden, die jeweils einen der Farbfilter fest zugeordnet bekommen. So ist es möglich, trotz doppelter Datendichte die Lesegeschwindigkeit konstant zu halten.

Farb-Barcode mit Farbfilter Farb-Barcode mit Farbfilter

Wie man erkennt, geschehen beim Aufnehmen des Barcodes durch die Farbfilter nun mehrere Dinge:

  1. Schwarze Pixel bleiben unverändert und stellen die Kontrastfarbe dar.
  2. Weiße Pixel werden eingefärbt und stellen die Grundfarbe dar.
  3. Pixel in der Farbe des Filters werden herausgefiltert und stellen die Grundfarbe dar.
  4. Pixel in der Gegenfarbe des Filters werden verstärkt und stellen die Kontrastfarbe dar.

Durch Einsatz der Farbfilter und dem Effekt der Kontraständerung der Gegenfarbe entstehen zwei unterschiedliche Barcode-Abbildungen auf Basis eines einzigen Farb-Barcodes. Jeder QR-Code-Leser, der einen automatischen Kontrastabgleich vornimmt, kann diese Barcodes bereits lesen. Zur Verbesserung der Barcode-Erkennung können nach dem Einsatz des Filters noch zwei Schritte unternommen werden, um das Leseergebnis zu verbessern. Im ersten Schritt kann eine Überführung in ein Graustufenbild erfolgen, um den Bias des Farbsensors abzumildern. Denn wie man in den Ausgangsbildern erkennt, ist der Kontrast im Blaufilter-Bild wesentlich schlechter erkennbar als im Rotfilter-Bild.

Farb-Barcode mit Farbfilter als Graustufenbild Farb-Barcode mit Farbfilter als Graustufenbild

Im zweiten Schritt kann mit Hilfe eines Schwellwertabgleichs der tatsächlich benötigte Bildinhalt gut herausgefiltert werden. GIMP bietet hierfür beispielsweise ein einfach zu verwendendes Werkzeug, das einem eindeutig anzeigt, welche Schwellwerte von Interesse sind:

Schwellwertabgleich Schwellwertabgleich

Die daraus entstehenden Barcodes sollten nun wirklich von jedem Barcode-Scanner gelesen werden können:

Farb-Barcode mit Farbfilter als Graustufenbild nach Schwellwertfilter Farb-Barcode mit Farbfilter als Graustufenbild nach Schwellwertfilter

Um zu zeigen, dass das Auslesen auch mit Standardmitteln funktioniert, habe ich einen prototypischen Versuch unternommen und zuhause einen Farb-Barcode ausgedruckt, eine normale QR-Code-App auf meinem iPhone installiert und einen Farbfilter vor die Kamera gehalten. Den Versuch, die beiden Ebenen des 3D-Barcodes aufzunehmen habe ich als Video bei Youtube hochgeladen. Ja, es funktioniert nicht perfekt, aber weder Licht, Druckerfarbe, Farbfilter noch die verwendete App sind in irgendeiner Form aufeinander abgestimmt. Das sollte man beim Betrachten des Videos im Hinterkopf behalten.

Einsatz finden kann solch ein Verfahren in meinen Augen in zwei Situationen:

  1. In Situationen, in denen in einem Barcode mehr Daten gespeichert werden müssen, als in einen konventionellen Barcode passen.
  2. In Situationen, in denen in einem Barcode Daten für mehrere Empfänger gespeichert werden sollen. Möglich wäre beispielsweise das Szenario, dass zwei Verarbeitungsschritte Informationen aus einem Barcode lesen sollen. Der Barcode-Leser des ersten Verarbeitungsschritts erhält einen blauen Farbfilter, dessen zu lesende Daten werden in rot encodiert. Der Barcode-Leser des zweiten Verarbeitungsschritts erhält einen roten Farbfilter, dessen zu lesende Daten werden in blau encodiert. Bei gut abgestimmten Filtern und Druckfarben sind die Barcode-Leser nun optisch nicht mehr in der Lage, die falschen Daten vom Farb-Barcode auszulesen.

Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)