XR232USB - echter Zufallsgenerator für USB

Der XR232USB ist eine kompakte und leistungsfähige Alternative zum klassischen XR232. Der neue Zufallsgenerator profitiert von den Segnungen des USB-Ports, verliert aber zu keinem Zeitpunkt die Bodenhaftung: Unabhängige Rauschquelle, Sicherheit statt Schnickschnack, Transparenz in Hardware und Software, kompatibel zum XR232-Protokoll.


XR232USB XR232USB V1.1:
  • USB-2.0-Anbindung

  • Virtueller COM-Port

  • Elektronisches Rauschen
    als Entropie-Quelle

  • Mikrocontroller besorgt
    Random-Sampling,
    Balancierung, Störschutz
    und XR232-Protokoll

  • Bewährte und verbesserte
    Firmware

  • Vollständig XR232-kompatibel

  • Hervorragende Qualität der Zufallsdaten

  • Kommandozeilentool und Bibliothek
    zur plattformübergreifenden Nutzung

  • Sichere Funktion
    bis über 230.400 Baud




Konzept


Das Projekt XR232 steht für unabhängige Zufallszahlenerzeugung mit einer transparenten Hard- und Softwarelösung; für ein robustes Schutzkonzept; für Zugriffe nach RS232-Standard ohne obskure Treiber; für plattformübergreifende Nutzbarkeit.

Nun werden echte und brauchbare RS232-Schnittstellen leider immer seltener, dafür verfügt heute jeder aktuelle PC oder Laptop über mehrere USB-Ports. Als "Universalschnittstelle" bietet USB faszinierende Möglichkeiten; flotte Geschwindigkeiten, Hot-Plug-Fähigkeit, flexible Treibereinbindung... und das mit der Stromversorgung über den USB-Port ist ja nun wirklich praktisch!

Einige dieser Features wünschte man sich auch von einem modernen externen Zufallsgenerator. Und was sagt der 'freie' Markt dazu? Die üblichen Verdächtigen kommen mit kostbaren Kästchen oder stylishen Sticks daher, wo auch ganz bestimmt die allerletzte Technologie aus der Weltraumforschung eingebaut ist. Im Komplettpaket mit geheimnisvollen Treibern, Klickibunti-Software und frei erfundenen Zertifizierungen bekommt der unkritische und zahlungskräftige Kunde die perfekte Illusion professioneller Zufallszahlenerzeugung.

Wer nun aber ernsthaft eine vertrauenswürdige, quelloffene und bezahlbare Lösung sucht, der landet am Ende doch wieder bei einem der wenigen nichtkommerziellen und offen dokumentierten Projekte - und wird möglicherweise selbst zum Lötkolben greifen müssen.

Aufgrund des positiven Feedbacks zum klassischen XR232 war von Anfang an klar: Die USB-Variante musste so einfach und transparent aufgebaut sein, wie nur möglich, wenn sie als Zufallsgenerator für Krypto-Anwendungen infrage kommen soll. Technisch gesehen ist der XR232USB im Vergleich zum XR232 praktisch eine Neuentwicklung und um einiges komplexer. Was wir aber bestimmt nicht brauchen, ist eine weitere "Black-Box" mit Hintertürchen für diverse Dienste. Der XR232USB gliedert sich daher in drei Hauptkomponenten mit klar voneinander abgrenzbaren und einzeln nachvollziehbaren Funktionen:

XR232USB - Blockschema

  1. USB-COM-Wandler. Wir sparen uns die wackelige Implementierung von USB-Funktionalität in einem Mikrocontroller und die Frickelei mit selbstgeklöppelten Treibern. Die wohl vernünftigste Methode, ein RS232-Konzept auf USB zu übertragen, geht über einen dafür optimierten Interface-Chip. Der FT232 von FTDI stellt, zusammen mit sehr zuverlässigen Treibern für Windows- und Linuxplattformen, einen sogenannten virtuellen COM-Port zur Verfügung. Jahrelang wurde diese Technik mit unwichtigen Anwendungen getestet, mittlerweile hat sie die notwendige Reife für den XR232-Einsatz erlangt ;-)

  2. Mikrocontroller. Ein AVR-Käfer vom Typ ATtiny85 ist mit den FT232-Datenleitungen TXD/RXD verbunden und liefert über den vom FT232 bereitgestellten virtuellen seriellen Port Zufallsdaten nach XR232-Protokoll. Seine nicht unerhebliche Rechenpower bei immerhin 16 MHz Taktrate wird hauptsächlich für das Zufalls-Bitsampling, die Selbstdiagnose und Sicherheitsfunktionen und für eine aufwendige Balancierung der gewonnenen Zufallsbits genutzt. Wie beim klassischen XR232 kommt die Entropie aus einer separaten elektronischen Rauschquelle. Das Programm im Mikrocontroller (Firmware) erreicht eine sehr gleichmäßige Ausnutzung der im Rauschen enthaltenen Entropie, indem es die mit höchster Abtastrate gewonnenen Zufallsbits ständig in einem rotierenden Pufferspeicher ("Random-Pool") mit alten Zufallswerten XOR-verknüpft. Das passiert immer um ein Vielfaches schneller, als Zufallsdaten angefordert werden. Es geschieht auch im "Leerlauf", wenn nur mit sehr geringer Baudrate oder gar keine weiteren Daten angefordert werden. Das Ergebnis sind hervorragend balancierte Zufallsdaten von hoher Entropie. Die Firmware kann Störungen der Rauschquelle erkennen und kurzzeitige Aussetzer (z.B. durch Mobiltelefon-Einstrahlung aus unmittelbarer Nähe) mit gepufferten Daten überbrücken. Bei schwerwiegenden Störungen (z.B. dauerhafte HF-Einstrahlung, starke USB-Spannungsschwankungen) wird eine laufende Übertragung auch mal nach dem regulären RTS/CTS-Handshake unterbrochen. Wichtig ist, dass bei alledem zu keinem Zeitpunkt die ausgelieferten Zufallsdaten auf algorithmische Weise "geschönt" sind - solche Methoden mögen bei kommerziellen Geräten üblich sein, stehen aber zu Recht unter dem Verdacht, mögliche Hintertürchen offenzuhalten.

  3. Rauschquelle. Die hier eingesetzte Schaltung nutzt chaotische Schwingungen in einem überkritisch gekoppelten Komparator als Entropie-Quelle. Wie beim klassischen XR232 sorgt auch hier eine Pufferstufe für die Entkopplung und Vordigitalisierung, sodass der Mikrocontroller mit einem reinen Digitalsignal ("Digital Noise") weiterarbeitet.

Die Aufbauvariante mit einem SSOP-Chip  und miniaturisierten Bauteilen ("Hybridtechnik"!) passt auf eine Platine von weniger als 25 x 50 mm - also schon ein passables Stick-Format. Auch eine Edelversion im robusten Metallgehäuse wurde bereits erfolgreich getestet.

Das Projekt ist und bleibt freie Hardware und freie Software. Alle Materialien für den Nachbau (Layout, Bestückungsplan, Stückliste, Firmware, Quellcodes) stehen in einem Paket zum Download bereit. Bitte beachten Sie die rechtlichen Hinweise am Schluss dieses Artikels.

Im Paket enthalten ist auch mein neu erstelltes Kommandozeilentool, das die DOS-Anwendung für den klassischen XR232 ablösen soll und selbstverständlich genauso gut mit dem XR232 wie mit dem XR232USB zusammenspielt.

Nach oben |  Index


Hardware

XR232USB - Schaltung

USB-Anbindung (IC1)

Das Projekt nutzt den FT232RL von FTDI in seiner Standardfunktion als USB-COM-Wandler. Die FT232-Serie ist nun schon einige Jahre am Markt. Ich selbst konnte seit 2008 konkrete Erfahrungen mit den FT232-Chips sammeln. Ein vorsichtiges Grundvertrauen in diese Technik erscheint mir gerechtfertigt. Außerdem ist offensichtlich keine andere Hardware- und Treiberlösung zur Bereitstellung virtueller COM-Ports technisch so ausgereift, systemübergreifend verfügbar und zuverlässig. (Beispielsweise ist der PL2303 von Prolific keine ernsthafte Alternative; schwer zu beschaffen, seltsame Treiber, alberne EULA - alles überhaupt nicht "XR232-like"!)

Prinzip der FT232-Chips: Auf der einen Seite geht USB rein, auf der anderen Seite kommen RS232-Signale mit invertierten Logikpegeln heraus. Diese Leitungen können direkt mit einem MAX232 oder mit den Ports eines Mikrocontrollers zusammenarbeiten. Auf dem Host-System stellen die dazugehörigen FT232-Treiber einen sogenannten "virtuellen COM-Port" (VCP) bereit. Alle Programme, die standardgemäß und von Gnaden des Betriebssystems auf eine serielle Schnittstelle zugreifen wollen, können den virtuellen Port genauso nutzen, wie einen gewöhnlichen COM-Port.

FT232 im XR232USB: Die FT232-Leitungen TXD, RXD, RTS und CTS arbeiten in dieser Anwendung mit einem kleinen Mikrocontroller zusammen, der die eigentliche XR232-Funktionalität bereitstellt.

Vorteile: Der FT232RL ist das am höchsten miniaturisierte Mitglied der FT232-Familie. Der FT232RL kommt praktisch ohne externe Bauelemente, insbesondere ohne voluminösen Schwingquarz aus; sein Flächenbedarf auf der Platine liegt unter einem Quadratzentimeter. Wie sich in anderen Projekten bestätigt hat, funktioniert das System aus FT232xx und VCP-Treibern auf verschiedenen Windows- und Linux-Umgebungen äußerst zuverlässig. Der (mittlerweile) bezahlbare Preis und die gute Verfügbarkeit dürften weitere Gründe sein, warum sich das FT232-System zu einem Quasi-Standard entwickelt hat.

Nachteile: Es ist ein proprietärer Baustein. Details zum inneren Aufbau der FT232-Chips und zur Implementierung der Treiber sind also nicht so ohne Weiteres verfügbar. Für den Praktiker dürfte aber vor allem das winzige SSOP28-Gehäuse mit nur 0,65 mm Pinabstand ein gewisser Stressfaktor sein. Die Anforderungen an das Platinenlayout sind auch vergleichsweise hoch. Zum Bestücken braucht man definitiv ein ruhiges Händchen. Von Kaffee oder Energydrinks rate ich im Vorfeld einer SMD-Lötaktion definitiv ab ...

Kein USB-Spaß ohne USB-Treiber: Die FT232-Treiber stehen auf der FTDI-Website zum kostenlosen Download bereit. Nach erfolgreicher Installation wird jedes neu angeschlossene FT232-Device in Sekundenschnelle erkannt und im Gerätemanager als "serielle USB-Schnittstelle" mit einer automatisch zugewiesenen COM-Portnummer gelistet. Der Witz dabei ist, dass die Zuordnung von bereits bekannten Devices auch später erhalten bleibt, wenn das Gerät an einen anderen USB-Port angeschlossen wird. (Die FT232-Chips haben eindeutige Seriennummern...)
Es ist möglich, die automatisch zugeteilten Portnummern und Standardeinstellungen für eine Schnittstelle nachträglich über Anschlusseinstellungen-Erweitert zu ändern (klar, nur mit Administratorrechten).
Unter Linux ab Kernel 2.6.x ist der Support für FT232-Chips bereits eingebaut. Ab Kernel 3.0.x sollen auch andere FTDI-Chips unterstützt werden.

Mikrocontroller (IC2)

Der hier eingesetzte  ATtiny85 von ATMEL ist ein kleiner AVR-Mikrocontroller mit 8 Anschlüssen und 5 regulär nutzbaren Portleitungen. Für diese Anwendung ist der ATtiny85 eine Idealbesetzung:

Die Portleitungen PB3/PB1 gehen auf die FT232-Leitungen TXD/RXD. Hierüber wickelt der Controller eine normgerechte RS232-Kommunikation nach XR232-Protokoll ab. (Details unter Firmware!)

Die Ports PB0/PB2 sind mit den FT232-Leitungen RTS/CTS (Sendeanfrage/Sendeerlaubnis) gekoppelt. Über diese Leitungen führt der Controller  ein aktives Hardware-Handshake durch. Er kann damit - konform zu RS232-Spezifikationen - eine Übertragung im Störfall vorübergehend anhalten.

Über den Eingang PB4 bekommt der ATtiny85 das "digitale Rauschen" zugeführt; hierbei handelt es sich um ein pulsweitenmoduliertes, breitbandiges Frequenzgemisch mit zufälligen Eigenschaften (ähnlich dem digitalisierten weißen Rauschen im klassischen XR232).
Das Signal wird bereits außerhalb des ATtiny vordigitalisiert und kann daher ohne weitere Wandlungsverluste vom Controller verarbeitet werden. (Der integrierte Analog-Digital-Wandler wird in dieser Anwendung nicht eingesetzt. Der ADC wäre relativ anfällig für hausgemachte Störungen direkt aus dem Prozessorkern oder aus benachbarten Strahlungsquellen.)
Die jetzige Lösung praktiziert eine logische und räumliche Trennung zwischen "Digital-Teil" (Mikrocontroller) und "Analog-Teil" (Rauschquelle und Quantisierer). Etwaige Störungen aus dem Controller werden weitgehend von der Rauschquelle ferngehalten. XR232-Philosophie!

Der Eingang RESET des Controllers ist indirekt mit dem Ausgang RTS vom FT232 verbunden. Wenn der Host-Rechner die serielle Schnittstelle regulär öffnet und Taktzeichen senden will, fällt erst einmal RTS auf Low-Pegel ab. Der kleine Keramikkondensator (C10) differenziert diese fallende Flanke zu einem kurzen negativen Reset-Impuls für den Controller.
Als nichtmaskierbarer Interrupt funktioniert der Hardware-Reset unabhängig davon, was der Controller gerade so treibt, oder ob er gar abgestürzt sein sollte. Dieser erzwungene Reset steht für höchste Betriebsbereitschaft; der Host-Rechner kann durch einfaches Schließen und erneutes Öffnen der Schnittstelle immer wieder einen Neustart der ATtiny85-Firmware erzwingen.

Eine LED ist über +5V und einen Vorwiderstand mit dem Portausgang PB2 verbunden. Sie leuchtet auf, wenn der Controller CTS auf Low zieht, also die RS232-Übertragung freigeschaltet ist. Sollte diese LED in der laufenden Übertragung flackern, dann hat die aktive "Störaustastung" eingegriffen (siehe Erläuterungen zur Firmware).


Rauschquelle (IC3)

Für einen Z-Dioden-Rauschgenerator werden mindestens 10 Volt Betriebsspannung benötigt, da sich der interessierende Effekt (Lawinendurchbruch, Avalanche) bei Z-Dioden erst ab ca. 8 Volt effektiv nutzen lässt. An USB stehen bekanntlich nur 5 Volt zur Verfügung. Ich habe eine ganze Reihe von Versuchen unternommen mit: Spannungswandlern, exotischen Bauteilen, Photodioden, Opamps, Widerstandsrauschen u.a. Das war sehr interessant, aber im Sinne der Aufgabenstellung leider weitgehend erfolglos geblieben. Die Schaltungen waren entweder zu aufwendig, zu unstabil, zu schmalbandig, zu störempfindlich... oder alles zusammen :(

Die von mir ausgetüftelte Lösung beruht nun auf einem Zweifach- Komparatorschaltkreis vom Typ LM393. Meine Schaltung nutzt einen längst bekannten aber normalerweise unerwünschten "Schmutzeffekt" aus: Betreibt man so einen Komparator entgegen allen Designregeln mit einer minimalen Gegenkopplung, dann entstehen infolge der extrem hohen Verstärkung und minimalen Hysterese sehr leicht Instabilitäten, die sich normalerweise zu "chaotischen Schwingungen" aufschaukeln können. Eine typische Komparatoranwendung wäre damit unbrauchbar und würde im Bereich der Umschaltschwellen zu großen Instabilitäten neigen. Mit einer besonderen Eingangsbeschaltung können wir diese überkritische Betriebsart jedoch zu höheren Frequenzen hin verschieben, dass der Quantenschaum nur so hervorquillt! Diese Komparatorschaltung schwingt nicht einfach, sie rauscht. Fast so gut, wie ein Z-Dioden-Generator. Schon erstaunlich, wenn man bedenkt, dass auch diese Schaltung nicht auf theoretischem Geschwurbel beruht, sondern durch Experimentieren, Modifizieren und Optimieren in der Realität entstanden ist.

Vorteile: Viel Entropie für wenig Geld! Der LM393 ist ein Wald-und-Wiesen-Komparator und wird bis heute in großen Stückzahlen produziert. Selbst mit Billigexemplaren aus irgendeiner China-Klitsche sollte es keine Probleme geben, sofern sich innen drin ein wirklicher Komparator befindet...
Diese Schaltung arbeitet schon ab etwa 4 Volt stabil und bleibt damit selbst an grenzwertigen USB-Ports noch funktionsfähig.
Mit miniaturisierten konventionellen Bauteilen lässt sich die Schaltung auf wenigen Quadratzentimetern sehr kompakt aufbauen. Das zweite Komparatorsystem wird als Verstärker zur "1-Bit-Quantisierung" eingesetzt. Ein angeschlossener Mikrocontroller bekommt echte Digitalpegel angeboten und ist schon weitgehend vom "Rauschsystem" entkoppelt. Die anfängliche Befürchtung, dass der zweite Verstärker eine zu starke Rückwirkung auf die erste Stufe haben könnte und letztlich deren Rauschspektrum einengt, hat sich messtechnisch nicht bestätigt. Damit die Pufferstufe nicht zu Eigenschwingungen neigt, wurde ihr Arbeitspunkt natürlich über einen Spannungsteiler R3/R4 festgelegt. Das Rauschspektrum ging bei vielen LM393 bis etwa 300 kHz, bei einem Betriebsstrom von weniger als 1 mA.

Nachteile: Hier sind Signale im Mikrovolt-Bereich im Spiel, sodass auf jeden Fall eine potenzielle Empfindlichkeit für HF-Einstrahlung besteht. Diesen Effekt konnte ich mit haushaltsüblichen Sendern ab VHF aufwärts (40-MHz-Fernsteuerung, 1800-MHz-GSM-Telefon, 2400-MHz-WLAN-Adapter) wieder direkt nachweisen. Das Rauschen setzt für die Dauer der HF-Einwirkung komplett aus. Synchronisationseffekte, wie bei einem klassischen Ringoszillator, treten oberhalb von einigen hundert kHz überhaupt nicht auf. Die Empfindlichkeit für HF-Einstrahlung (UHF, Mikrowellen) scheint übrigens noch etwas geringer zu sein, als bei der Rauschquelle im klassischen XR232 mit den zwei diskreten Transistoren. Gegen HF-Einstrahlung helfen kompaktes Layout und metallische Abschirmung. Des Weiteren können aber auch Schwankungen auf der Versorgungsspannung die Arbeitspunkte der Komparator-Rauschquelle kurzfristig verschieben und damit Aussetzer verursachen. Deshalb sollte die Komparator-Rauschquelle nicht direkt am USB-Strom betrieben werden. Eine übliche PC-Stromversorgung ist oft von Schaltspitzen und Spannungsschwankungen aus dem gesamten System verseucht. Zum Glück benötigt die Komparator-Rauschquelle nur sehr wenig Betriebsstrom (unter 1 mA), sodass zur Glättung des Betriebsstroms ein einfaches R-C-Siebglied (R7/C9) ausreicht.
Gegen beide Arten von Störungen hat der Mikrocontroller außerdem noch einen programmiertechnischen Trumpf im Ärmel, siehe "Störaustastung"!

Serientauglichkeit: Die funktionskritischen Grenzwerte des Komparator-IC werden problemlos eingehalten. Ich habe außerdem eine ganze Reihe von Exemplaren aus verschiedenen Chargen und von verschiedenen Herstellern in dieser Schaltung durchgetestet. Anscheinend funktioniert es mit allen Varianten des LM393, wobei leichte Variationen in der nutzbaren Bandbreite und "Weißheit" des Rauschspektrums auftreten. Ferner habe ich jetzt noch einmal das Verhalten unter Extremtemperaturen getestet. Das Spektrum scheint sich ab ca. 60 °C etwas abzuflachen, was auch zum Teil durch Arbeitspunktverschiebungen in der Pufferstufe verursacht wird. Unter üblichen Bedingungen (Temperaturbereich ca. -10 bis +50 °C), dürfte der XR232USB mit jedem Exemplar des LM393 ausreichend sicher funktionieren.


ISP-Stecker (X2)

Beim direkten Einlöten braucht die PDIP-Version des ATtiny85 nur ca. 4 mm Bauhöhe. Das verträgt sich noch gut mit dem angestrebten "USB-Stick-Format". Das Konfigurieren, Flashen und Debuggen des Mikrocontrollers ist weiterhin über die 6-polige SIL-Sockelleiste X2 "in system" möglich (Bild).
Die Portleitungen des ATtiny85 habe ich so belegt, dass es zu keinen Kollisionen zwischen Ausgängen des FT232, des Controllers und einem Programmiergerät kommen kann, sofern der virtuelle COM-Port "geschlossen" bleibt.
Die Stromversorgung eines ISP-Programmiergerätes kann natürlich ebenfalls über X2 laufen, sofern das Gerät nicht zu viel Strom zieht. Der Maximalstrom an USB beträgt ca. 500 mA.
Da es für 6-polige einreihige ISP/SPI-Verbindungen keine "offizielle" Anschlussbelegung gibt, wurde X2 in diesem Projekt so beschaltet, wie es layouttechnisch am günstigsten war. Ich bitte um Verständnis für diese "proprietäre" Anwandlung. Siehe untenstehendes Diagramm!

Adapter von 10-Pol-Wannenstecker nach ATMEL-ISP-Spezifikationen auf 6 pol. XR232USB-Programmierstecker

Hinweis: Nach Installation eines Bootloaders wird der ISP-Stecker X2 normalerweise nicht mehr benötigt.

Nach oben | Index


Firmware

Die Firmware für den ATtiny85 ist komplett in Assembler geschrieben, denn hier geht es um Performance und um Transparenz.
Für diejenigen, die einen kommentierten Assemblertext nicht lesen können oder wollen, habe ich hier zu den wichtigsten Programmteilen ein paar Erläuterungen geschrieben.

Gewinnung der Zufallsdaten

Entropie-Quelle ist elektronisches Rauschen mit bandbegrenztem Frequenzspektrum. Es wird außerhalb des Mikrocontrollers über eine Verstärkerstufe in ein wertdiskretes Rechtecksignal mit variabler Pulslänge überführt (1-Bit-Quantisierung). Der Mikrocontroller "sieht" also auf seiner Portleitung bereits ein digitales Signal.
Die Entropie steckt in der unendlich feinen Zeitauflösung der Pegelwechsel. Da die Weiterverarbeitung rein digital im Mikrocontroller erfolgt, kann der Software-Algorithmus gezielt auf die Eigenarten der verwendeten Entropie-Quelle zugeschnitten werden.
Hier hat sich folgende Methode am besten bewährt: Man tastet das digitale Quellensignal mit der höchstmöglichen Geschwindigkeit ab (Oversampling), sodass selbst die höchsten Frequenzkomponenten noch in mehreren Prozessortakten erfasst werden. Diese Forderung ist hinsichtlich der infrage kommenden Frequenzen (Spektrum bis maximal 300 kHz) leicht zu erreichen, da wir mit Assemblerprogrammierung in einem RISC-Prozessor auf 16 MHz Taktrate durchaus eine Abtastschleife von mehreren Megasamples pro Sekunde realisieren können. Zur Gewinnung der Zufallsbits wird nicht der momentane Zustand des Eingangssignals herangezogen. Vielmehr misst das Programm die Periodendauer zwischen zwei Pegelwechseln und nimmt von diesem schnellen Zähler nur das niederwertigste Bit zur Weiterverarbeitung.
Bereits diese erste Transformation liefert Zufallsbits, die auf wenige 0,01 % ausbalanciert sind, während das Rohsignal der Rauschquelle noch um einige Prozent vom ideal ausgeglichenen Zustand abweichen kann.
Im Gegensatz zu Sample-and-Hold entstehen mit dieser Methode kaum störende Aliasing-Effekte, selbst dann nicht, wenn sich die Abtastrate schon in der Nähe der Grenzfrequenz des Rauschens oder einer vorherrschenden Spektrallinie (HF-Störungen) bewegt.
Jeweils 8 Bit werden zu einem Byte zusammengefasst und mit einem früher gespeicherten Byte aus einem im SRAM realisierten Pufferspeicher XOR-verknüpft. Dann wird der Adresszeiger für den Schreibzugriff erhöht und springt beim Erreichen der letzten Position des Random-Pools wieder an die erste Position.
Es wird also stets ein möglichst "alter" Wert mit einem ganz neuen Zufallsbyte verknüpft. Auf diese Weise werden etwaige Korrelationen von aufeinander folgenden Zufallsbytes vermutlich vollständig eliminiert.
Die Lesezugriffe auf den Random-Pool finden über einen separaten Adresszeiger statt. Damit ist auch eine etwaige Rückwirkung der Lesezugriffe auf das Zufalls-Bitsampling weitgehend ausgeschlossen.
Da die Periodendauer gemessen wird, kann das Programm eine Störung der Rauschquelle, die sich in einer unnatürlich langen Pulsweite äußern würde, sofort erkennen und entsprechende Gegenmaßnahmen einleiten. (Rückgriff auf Entropie-Reserven, Unterbrechung der Verbindung - siehe Abschnitt "Störaustastung".)

Rechenbeispiel: Mit einer aktuellen Firmware liegt die Abtastrate bei über 1 MHz. Der Zähler registriert je nach momentaner Pulsweite des digitalen Rauschens Periodenlängen zwischen etwa 2...14 Einheiten. Dies entspricht, zurückgerechnet über die dabei insgesamt verbrauchten Prozessortakte, Rausch-Frequenzen im Bereich von 38...220 kHz. Tatsächlich lässt sich diese Größenordnung mit einem Frequenzzähler am Digitalausgang der Rauschquelle auch direkt bestätigen: Hier kommen wir auf Mittelwerte um 140 kHz, was wiederum einer theoretischen Ausbeute von ca. 280 kBit/s (=35 kByte/s) an Zufallsdaten entspricht.
Die gegenwärtige Firmware kann den Random-Pool von 512 Byte ca. 70 Mal in der Sekunde komplett wieder auffrischen. Die Werte können je nach Auslegung der Rauschquelle und des Programms um etliche Prozent nach unten oder vielleicht auch nach oben abweichen, das ist klar. Sie geben aber eine Vorstellung davon, was mit diesem Schaltungskonzept und mit der zur Verfügung stehenden Rechenleistung auf dem ATtiny85 erreichbar ist.
Übrigens funktioniert der Lesevorgang nach XR232-Protokoll noch bis über 500.000 Baud problemlos, was die Bereitstellung gültiger serieller Zeichen angeht. Allerdings bewegt man sich dann schon lange nicht mehr im Bereich einer sicheren Unterabtastung. Die Qualität der Zufallsdaten wird dementsprechend nachlassen. Mit 230.400 Baud (entspr. 23,04 kByte/s), oder darunter, bewegen wir uns hingegen in einem noch recht unkritischen Bereich. Generell sollte die Baudrate immer nur so groß gewählt werden, wie es für die jeweilige Zufalls-Anwendung unbedingt erforderlich ist. Dann hat der XR232USB genügend Zeit, jedes Bit vor der Auslieferung mehrfach aufzufrischen.


XR232  vs  XR232USB :
Beim klassischen XR232 wäre eine Überabtastung der Rauschquelle sinnlos (und sie wird durch die eingeschränkte Bandbreite der Optokoppler normalerweise verhindert). Der XR232 tastet das digitalisierte und mittels Frequenzteiler vorbalancierte Rauschen direkt mit dem aus TXD regenerierten Taktsignal ab und fügt lediglich Start- und Stoppbits hinzu, um auf der Rückleitung RXD ein normgerechtes RS232-Signal darzustellen. Die Anforderung eines Zufallsbytes erfasst beim XR232 also immer den momentanen Zustand der Rauschquelle.
Beim XR232USB liefert die Periodendauer zwischen zwei Pegelwechseln das nächste Zufallsbit. Der Balancierungseffekt ist in seiner Effizienz vergleichbar mit der Von-Neumann-Methode. Der Controller bündelt die Zufallsbits zu Bytes und XOR-verknüpft diese mit früheren Zufallsdaten (Random-Pooling).
Der XR232USB bleibt nicht untätig, wenn nur wenig oder keine Zufallsdaten angefordert werden. Die "überschüssige" Entropie geht nicht verloren, sondern rotiert weiter im Random-Pool. Der Pool sorgt für gleichmäßig hohe Qualität der Zufallsdaten und kann kurzzeitige Störungen ausgleichen. Die Anforderung von Zufallsdaten ist von der Zufallsdatengewinnung weitgehend entkoppelt.


Abfrage der Zufallsdaten

Auf Anforderung durch den Host-Rechner soll der Mikrocontroller ein Datenbyte aus dem Random-Pool lesen und dieses als serielles Zeichen an die Schnittstelle senden. Nach XR232-Protokoll muss der Host zur Anforderung jedes einzelnen Zufallszeichens genau ein Taktzeichen mit der Bitfolge 1-01010101-0 senden.
Ein schneller Mikrocontroller kann nicht nur das Verhalten der ursprünglichen XR232-Logik nachbilden, sondern nebenbei noch andere nützliche Dinge erledigen.
Wie weiter oben erwähnt, ist das Programm so ausgestaltet, dass die Zufallsdaten-Gewinnung mit der höchstmöglichen Geschwindigkeit stattfindet. Das Bitsampling und die Verwaltung des Random-Pools haben oberste Priorität. Die Erkennung von Pegelwechseln auf der TXD-Leitung hat zweite Priorität. Dennoch kann der Controller bis zu einer seriellen Datenrate von mehreren hundert Kilobits pro Sekunde noch rechtzeitig auf Taktzeichen ("U") reagieren und entsprechende Zufallsbytes, versehen mit Start- und Stoppbits, zurückliefern.
Da die Erzeugung des seriellen Datenstroms im "Polling"-Vefahren stattfindet, hat die serielle Übertragung keinen Einfluss auf das Bitsampling und Random-Pooling. Vielmehr bewirkt die Sampling-Routine durch ihre zufälligen (von der Rauschquelle beeinflussten) Laufzeitschwankungen immer kleine Phasenverschiebungen bei den zurückgelieferten RXD-Zeichen.
Diese Schwankungen im Mikrosekundenbereich bewegen sich jedoch bis ca. 256.000 noch ganz innerhalb der zulässigen Toleranzen für serielle Übertragungen (einige Prozent). Im Übrigen können sich Timingfehler beim XR232-Protokoll nicht aufaddieren, wodurch die ganze Sache selbst bei höheren Baudraten noch erstaunlich rund läuft.


Reset

Ein Hardware-Reset des Controllers wird durch Einschalten der Betriebsspannung (Power-On Reset) oder durch einen Reset-Impuls auf dem Eingang RESET des Controllers (Externer Reset) ausgelöst. Weitere interne Reset-Quellen wären der Watchdog-Timer oder der Brown-Out-Detektor (Unterspannungserkennung).

Wie in der Schaltungsbeschreibung erwähnt, bewirkt ein Pegelwechsel auf der vom FT232 kommenden RTS-Leitung von (1-0) ebenfalls einen Hardware-Reset des Controllers.
Damit ist sichergestellt, dass die Firmware jederzeit durch einfaches Schließen und erneutes Öffnen der Schnittstelle neugestartet werden kann. Da es sich jedoch um einen Warmstart handelt, bleiben Inhalte im SRAM bei diesem Reset auf jeden Fall erhalten. Damit eröffnet sich die Möglichkeit, die bisher angesammelten Zufallsdaten aus dem Random-Pool selbst nach einer Störung noch einmal zu "recyclen". (Genau genommen beginnt die Zufallszahlengenerierung nicht erst mit dem Öffnen der Schnittstelle, sondern bereits mit dem Anschluss des XR232USB an einen USB-Port.)
Die RTS-Leitung ("Request To Send" = Sendeanforderung) geht sofort Low-Pegel, nachdem der Host-PC die Schnittstelle geöffnet hat. Vorausgesetzt, dass die RS232-Schnittstelle im Host-PC für Hardware-Handshake (RTS-CTS) konfiguriert ist, kann der PC jedoch erst dann Zeichen senden, wenn das angesprochene Gerät über die Leitung CTS ("Clear To Send" = Sendegenehmigung) signalisiert hat, dass es empfangsbereit ist. Das bedeutet, der Zufallsgenerator kann den Beginn der Übertragung ganz legal hinauszögern.
Natürlich hat der Zufallsgenerator unmittelbar nach einem Reset seine Leitung CTS zunächst deaktiviert, damit keine Zufallszeichen-Anforderungen reinkommen, auf die er zu diesem Zeitpunkt noch nicht reagieren könnte. Erst muss die Reset-Routine ein paar Register und die Portleitungen neu initialisieren, die Rauschquelle prüfen und den Random-Pool in ein paar Tausend Runden neu auffrischen. Dabei geht vorhandene "Alt-Entropie" nicht verloren, da der SRAM zwischenzeitlich nicht gelöscht wird. Wenn all das erledigt ist, aktiviert der Controller seine Meldeleitung CTS. Jetzt kann er Taktzeichen nach dem XR232-Protokoll entgegennehmen und  Zufallsdaten zurückliefern.



XR232USB Zugriffs-Zeitablauf, Reset, Normalbetrieb, Störung

Timing und Störaustastung beim Zugriff auf XR232USB (nicht maßstabsgetreu)
tRES = Zeitdauer Hardware-Reset, nur Initialisierung (wenige ms)
tdis1 = Kurze Störung < < 2 ms (über Random-Pool gepuffert)
tdis2 = Lange Störung > > 2 ms (löst Unterbrechung und Neustart aus)
tR1 = Erkennungszeit für "lange" Störung, ca. 20ms
tR2 = Totzeit (Wartezeit bis Rauschquelle wieder bereit)
tR3 = Regenerationszeit (Wiederauffrischen des Random-Pools)


Störaustastung

Ein Hardware-Zufallsgenerator soll als eigenständiges Subsystem bis zu einem gewissen Grad sicherstellen, dass die gelieferten Daten durch Störereignisse nicht korrumpierbar sind. Falls aber doch eine ernsthafte Störung vorliegt, dann muss der Anwender darüber informiert werden, um Gegenmaßnahmen treffen zu können.
Allein auf physikalische Schutzmaßnahmen, wie metallische Abschirmung und Filterung der Betriebsspannung, sollte sich der mikrocontrollerbasierte TRNG natürlich nicht verlassen.

Die hier verwendete elektronische Rauschquelle ist, wie die meisten Analogschaltungen, durch Einwirkung von Hochfrequenzenergie oder niederfrequente Schwankungen auf der Betriebsspannung beeinflussbar. Normalerweise liefert sie innerhalb einer gewissen Bandbreite ein "weißes" Rauschen. Im Störfall treten jedoch deutlich niederfrequentere Komponenten bis hin zu kompletten "Aussetzern" im Rauschsignal auf.

Bei kurzen Störungen (Millisekunden), auch wenn sie zyklisch aber mit niedrigem Tastverhältnis auftreten, muss der Mikrocontroller nichts weiter unternehmen; die Zufallszahlengewinnung gerät nur vorübergehend ins Stocken, da weniger auswertbare Pegelwechsel vorliegen. So lange die RS232-Leseanforderungen noch deutlich langsamer sind, als das Wiederauffrischen des Random-Pools, besteht auch keine Gefahr, dass sich die Zufallsdaten drastisch verschlechtern oder Störmuster eingeprägt werden.
Wenn eine externe Störung länger andauert (Hundertstel- oder Zehntelsekunden), lässt sich der Pool eventuell nicht mehr schnell genug oder gar nicht mehr auffrischen. Hier gibt es nur eine ehrliche Maßnahme, wie die Situation zu handhaben ist: Unterbrechung der Übertragung, bis die Rauschquelle wieder ordnungsgemäß funktioniert und das Gerät wieder zweifelsfreie Zufallsdaten liefern kann! Pseudo-Lösungen mit Pseudozufallsalgorithmen und Pseudo-Entropie überlassen wir den pseudoprofessionellen von Kommerz und NSA korrumpierten Anbietern!

Die zweite im Diagramm angedeutete Störung dauert insgesamt ca. 5 ms (tdis2). Nach wenigen ms (tR1) hat die Firmware eine Unregelmäßigkeit erkannt. Jetzt wird CTS deaktiviert, damit keine weiteren Anfragen mehr reinkommen. Der Zufallsgenerator wartet nun einfach ab, bis die Rauschquelle wieder funktioniert (tR2). Nach Abwarten einer "Totzeit" von 3 ms (tR2) funktioniert die Rauschquelle in diesem Beispiel auch schon wieder. Jetzt führt die Firmware sicherheitshalber einen kompletten Reset mit gründlicher Wiederauffrischung des Pools durch (tR3). Danach wird CTS wieder aktiviert. Der Zufallsgenerator kann jetzt wieder Daten von hoher Qualität liefern.

Anmerkung: Die Zeiten für Störungen/Störungserkennung sind allein durch die Firmware definiert. Ich habe sie aufgrund von Erfahrungswerten noch einmal drastisch verschärft. Lieber ab und zu einen "Fehlalarm", als möglicherweise korrumpierte Zufallsdaten!

Auswirkungen auf der Host-Seite:
Falls auf dem Host-PC ein sehr langer Timeout für RTS-CTS-Handshake eingestellt ist, kann die Software im Störfall sekundenlang abwarten, bis die Störung wieder vorüber ist, ohne dass eine Fehlerbedingung eintritt. Das bedeutet, die Schnittstelle muss zum Fortsetzen der Übertragung nicht einmal neu initialisiert werden. Diese Option ist sinnvoll für Anwendungen, die "unbeaufsichtigt" über einen längeren Zeitraum große Mengen Zufallsdaten benötigen.
Falls auf dem Host-PC ein kurzer Timeout für RTS-CTS-Handshake eingestellt ist, wird eine darüber hinausgehende Störung auch einen Schnittstellenfehler auslösen. Die Software muss den Port dann schließen und den XR232USB nach einer gewissen Wartezeit durch erneutes Öffnen neu initialisieren und/oder eine entsprechende Warnmeldung für den Nutzer ausgeben, falls er XR232USB auch beim nächsten Versuch nicht mehr reagiert.
Hervorzuheben ist, dass sich die Fehlerbehandlung in beiden Fällen ganz im Rahmen der RS232-Norm bewegt!


Identifikation

Die Firmware erkennt an der Länge der Startbits die ungefähre Baudrate der ankommenden Taktzeichen. Liegt diese unter ca. 2400 Baud, so schaltet die Firmware in einen "Identifikationsmodus" um: Statt Zufallszahlen wird für jedes Taktzeichen ein Zeichen aus einem insgesamt 32 Byte langen ASCII-String ausgegeben, der das Gerät und die Versionsnummer der Firmware anzeigt. Der String wiederholt sich zyklisch, solange neue Taktzeichen empfangen werden. Übrigens findet im Hintergrund weiterhin Random-Pooling statt.
Durch den Identifikationsstring kann eine Software über den ohnehin vorhandenen RS232-Kanal einen XR232 von einem XR232USB unterscheiden. Sie könnte also zum Beispiel für den klassischen XR232 niedrigere Übertragungsraten ansetzen, als beim Zusammenspiel mit einem XR232USB. Auch wären Firmware-Spezialversionen auf diese Weise automatisch erkennbar.
Der "Identifikationsmodus" wird erst durch einen Reset des Controllers beendet, also durch das Schließen der Schnittstelle und anschließendes Öffnen mit einer höheren Baudrate.
Der ASCII-String für die Kennung ist zusammen mit dem Programmcode im Flash untergebracht.


Bootloader

Ein ATtiny-Bootloader, der das Wechseln der Firmware ohne ISP-Infrastruktur ermöglicht, und der den besonderen Anforderungen dieses Projektes gerecht wird, steht zur Verfügung. Siehe Anmerkungen weiter unten.

Nach oben | Index


Software

Neues XR232-Kommandozeilentool

Das Programm "XR232NT" ist eine Konsolenanwendung und steht für Win32- und Linux-Systeme zur Verfügung. Im Download-Paket ist selbstverständlich der vollständige Quellcode enthalten. Das Tool stellt einige nützliche Funktionen für den Test von XR232/XR232USB und für die Generierung von Zufallsdateien bereit:

Programmbibliothek für XR232-Zugriffe

Mit dem aktuellen Paket stelle ich nun erstmals eine kleine Library mit den XR232-Grundfunktionen zur Verfügung, die mögliche Hemmungen abbauen soll. Damit ist es nun möglich, den Zufallsgenerator in eigenen Programmierprojekten zu nutzen, ohne sich mit den RS232-Zugriffen, Puffern und Parametern herumzuschlagen. Das Kommandozeilentool verwendet schon seit Längerem dieselben Routinen (statisch gelinkt), sodass ich von einer soliden Funktion ausgehe.
Buntes mit Knöpfen ist von meiner Seite nicht geplant. Wer sich nun ermutigt sieht, eine echte "Killeranwendung" für XR232/XR232USB zu schreiben, möge sich doch einfach mal mit mir in Verbindung setzen. Bei ernsthaften Anfragen stelle ich Musterexemplare als "Dauerleihgabe" zur Verfügung!


Nach oben | Index


Nachbauhinweise

Das Platinenlayout der aktuellen Hardware (Version 1.0) ist im Paket als hochauflösende Pixelgrafik mit exakter Skalierung enthalten.

Schon die Mischbestückung aus FT232RL und bedrahteten miniaturisierten Bauteilen ermöglicht einen recht kompakten Aufbau im "Stick"-Format. (Natürlich ginge es noch kompakter - aber ein reiner SMD-Aufbau wäre wohl für die meisten Interessenten noch abschreckender...)

Leider sind die Anforderungen an das Belichten und Ätzen schon wegen des einen SSOP-Bausteins relativ hoch. Gerade die feinen Leiterbahnen müssen präzise abgebildet werden. Man erspart sich viel Ärger beim Auflöten des kostbaren FT232RL, wenn die Toleranzbereiche hier nicht unnötig gedehnt wurden...

Auch für Gelegenheits-SMD-Löter sinnvoll: Lupenbrille (um beide Hände frei zu haben), Lichttisch und eine ultrafeine Lötnadel (auch improvisiert). Bei solchen Hightech-Viechern, wie den FTDI-Chips bitte immer auch Antistatik-Maßnahmen beachten! Das ist ausdrücklich kein Projekt mehr für Elektronik-Anfänger!

Allgemeine Aufbaustrategie: Erst FT232RL auflöten, dann das Minimum an Außenbeschaltung, welches für den Test am USB-Port erforderlich ist (d.h. Drosselspule, erster Elko, ein paar Kondensatoren, USB-Stecker - siehe Schaltplan/Bestückungsplan).  Wenn sich der Baustein nach dem Anschluss als FTDI-Device oder ähnlich meldet und kurze Zeit später ein neuer COM-Port im Gerätemanager auftaucht, ist das Schlimmste eigentlich schon überstanden. Danach bestückt sich der Rest viel entspannter.

Ein Arbeitsblatt (Bestückungsplan und Stückliste als PDF zum Ausdrucken) ist im aktuellen Paket enthalten. Dort finden sich auch Hinweise zu den wichtigen Fusebit-Einstellungen.


Deluxe-Aufbauvariante

Natürlich muss es kein Stick sein, wenn es kein Stick sein muss! Das untenstehende Bild zeigt die leicht modifizierte XR232USB-Platine im edlen Metallgehäuse. Sieht nicht nur geil aus, sondern schützt auch gegen Angriffe durch HF-Einstrahlung.
Die Platine hat eigentlich dasselbe Layout, wie die Stick-Version. Sie wurde lediglich um einen ca. 5 mm verbreiterten Rand zur Schraubmontage im Alu-Druckgussgehäuse (TEKO AL2) erweitert. Die Schaltung selbst blieb weitgehend unverändert. Lediglich der Glättungskondensator (C9) fürs Komparatorsystem wurde vorsorglich auf 470µF erhöht, genügend Platz ist ja vorhanden. Anders, als bei der Stickvariante können die Chips in hochwertigen (!) Fassungen gesockelt werden, was neue Experimentiermöglichkeiten eröffnet. Die ISP-Steckverbindung bleibt problemlos erreichbar.


XR232USB deluxe


Nach oben | Index


Screenshots



 Der olle Hex-Modus
rauscht vorbei...



Direkte Darstellung der Zufallsbits
in einer Bitmap.




 
Testfunktion zur Kontrolle der Gleichverteilung (DSV = Digital Sum Value)



Grafische Darstellung
der Byte-Häufigkeiten ("Frequencies")
 


WICHTIGER HINWEIS: Die integrierten Testmöglichkeiten von XR232NT.EXE können nur die allgemeine Funktionstüchtigkeit der XR232/XR232USB-Hardware sicherstellen. Einen tieferen Einblick liefert die Analyse mit einschlägigen Testverfahren, wie sie die DIEHARD-Suite zur Verfügung stellt. Zur Verdeutlichung werde ich von Zeit zu Zeit eine oder mehrere Zufallsdateien und die dazugehörigen Ergebnisse zum Download anbieten.


Nach oben | Index


Anmerkungen


Reine Assemblerprogrammierung

Keinesfalls möchte ich den hardwarefremden, hochsprachenverwöhnten Snobs das Vergnügen absprechen, sich mit klobigen Compilern, dutzenden Direktiven, sachfremder Syntax, abartiger Abstraktion und labilen Libraries herumzuschlagen!
Fast könnte man meinen, dass manchem "Embedded"-Entwickler das Trugbild von Professionalität und Portierbarkeit wichtiger ist, als technisch saubere und ressourcenschonende Lösungen vorzulegen. Wen juckt's schon, wenn der primitive LED-Blinker gerade noch so in einen ATmega reinpasst... Dennoch möchte ich diesen Fehlgeleiteten zurufen:

Wenn der Speicherplatz schon wieder knapp geworden und die ganze Performance bei der Übersetzung in Blähcode versackt ist, dann werdet ihr sehen, dass man nicht jeden Unsinn aus der PC-Welt auf einen Mikrocontroller übertragen kann ...!

Die Firmware zum XR232USB ist natürlich nicht nur aus Performancegründen in Assembler geschrieben. Assembler wird bekanntlich 1-zu-1 in Prozessorbefehle umgesetzt. Damit ist die Gefahr gebannt, dass durch Compilereigenarten und Importfunktionen mit jeder Software-Revision neue Unwägbarkeiten und Sicherheitsrisiken entstehen. Assembler garantiert nicht nur den effizientesten Code, sondern auch maximale Transparenz. Ein Vorteil, der im Hinblick auf mögliche Sicherheits-Anwendungen gar nicht hoch genug eingeschätzt werden kann!


Ein Bootloader für XR232USB

Als Bootloader bezeichnet man im Zusammenhang mit Mikrocontrollern üblicherweise ein kleines Programm, das bereits auf dem Mikrocontroller installiert ist und unter bestimmten Voraussetzungen aufgerufen wird. Dann ermöglicht es einen Programmiervorgang des internen Speichers, ohne dabei auf die speziellen Programmierleitungen und entsprechende ISP-Adapter zurückgreifen zu müssen.
Stattdessen erfolgt der Zugriff über eine bereits vorhandene Normschnittstelle. In vielen Mikrocontroller-Anwendungen wird dies eine RS232-Anbindung sein. Das bedeutet, wenn der Bootloader auf eine bereits vorhandene Schnittstelle zurückgreifen kann, brauchen wir keine zusätzliche Hardware, um ein Firmware-Update durchzuführen.
Die meisten AVR-Bootloader sind auch leider nur auf ATmegas zugeschnitten. Sie wurden in "C" oder gar "Bascom" zusammengepfuscht und verschwenden trotz bescheidener Funktionalität auch gleich mehrere Kilobytes an wertvollem Flash-Speicher. Auf einem ATtiny kann man sich das nicht wirklich leisten. Die wenigen brauchbaren ATtiny-Bootloader sind daher in Assembler geschrieben, müssen aber oftmals noch von Hand an die Gegebenheiten des jeweiligen Zielcontrollers angepasst werden. Diese Misere habe ich schon vor Jahren konstruktiv kritisiert, indem ich den inzwischen legendären AVR-Bootloader TinySafeBoot vorstellte. Sein Nachfolgeprojekt ist noch einmal wesentlich ausgereifter und erlaubt verschlüsselte Firmware-Updates auf hohem Sicherheitsniveau. Sein Name: One-Way-Loader

Rechtliche Hinweise


Alle Komponenten des Projektes "XR232" und "XR232USB" (Schaltung; Platinenlayout; Firmware; sonstige Programmierung) wurden von Julien Thomas mit Herz und Hand entwickelt.

In der Überzeugung, dass dieser transparent dokumentierte nichtdeterministische Zufallsgenerator für verschiedene Anwendungen einen großen Nutzen haben kann, gebe ich alle Informationen zu diesem Projekt für private, schulische und wissenschaftliche Zwecke nach den Bedingungen eines offenen Lizenzmodells frei.

Wenn Sie meine Arbeit unterstützen wollen, dann können Sie dies mit Fragen, Anregungen und Programmierbeiträgen, aber selbstverständlich auch mit Sach- oder Geldspenden tun. Ich freue mich auf Ihre E-Mail !


Nach oben | Index



Downloads



Links


Nach oben | Hauptseite

Letzte Änderung: 08/2011, 02/2012, 07/2012, 12/2012, 07/2013, 01/2014, 07/2014, 04/2015, 11/2016, 12/2019, 09/2020, 03/2023