XR232 - Echter Zufallsgenerator für die RS232-Schnittstelle

Echter Zufall für alle

Wenn Sie, lieber Leser, "zufällig" auf dieser Seite gelandet sind und eigentlich eine Black-Box mit zweifelhaftem Innenleben, proprietärer Klickibunti-Software, sagenhaften Statistiken und fest eingebauten Hintertürchen für schlappe 500 Dollar gesucht haben, ja, dann muss ich Sie leider auf die Seiten einschlägiger Internetgeschäftemacher verweisen ... ! (Beispiele unter [4])

"XR232" ist ein solides Hardwarekonzept für einen kryptografischen Zufallsgenerator, der auf preiswerten Standardkomponenten beruht und selbstverständlich vollkommen offen dokumentiert ist. Der XR232 ist "unbezahlbar", da es ihn nicht als Fertiggerät zu kaufen gibt. Dafür kann sich jeder interessierte Elektronikamateur ein solches Gerät für etwa 20 Euro Materialkosten selbermachen.

Der XR232 liefert vorbalancierte Rohdaten von guter statistischer Qualität mit bis zu 57600 Baud an die serielle Schnittstelle. Die Datenübertragung findet zu jedem Zeitpunkt streng nach RS232-Protokoll statt - insbesondere werden für den Zugriff keine obskuren Treiberkonstrukte benötigt. Schon mit einem einfachen Terminalprogramm für die serielle Schnittstelle lässt sich die Funktionstüchtigkeit des Zufallsgenerators testen. Wenn eine Software den XR232 nutzen will, muss sie lediglich Standardzugriffe auf die serielle Schnittstelle beherrschen. Tatsächlich ist die Anwendung des XR232 und die Portierbarkeit seiner Software zwischen verschiedenen Rechnerplattformen nun offensichtlich kein Problem mehr. In der Linkliste sind die aktuellen XR232-Programmierprojekte aufgelistet.

Als Zufallsquelle mit hervorragendem Preis-Leistungs-Verhältnis nutzt der XR232 eine Z-Diode. Die Schaltungstechnik ist damit im Vergleich zu thermischen Rauschgeneratoren bereits relativ unempfindlich gegen elektromagnetische Störungen. Dennoch schien es angebracht, das gesamte System des Zufallsgenerators gewissermaßen "ganzheitlich" auf Robustheit zu trimmen.
Daher verwendet der XR232 selbstverständlich seine eigenen gefilterten Betriebsspannungen, eine Abschirmung für die Rauschquelle, eine optoelektronische Schnittstellenanbindung zum PC-System, und empfehlenswert ist darüber hinaus der Einbau in ein Vollmetallgehäuse, wie in Bild 1 zu sehen.

Mit diesem bodenständigen Hardwarekonzept werden also, keinen Tag zu früh, drei der wichtigsten Grundvoraussetzungen für vertrauenswürdige Zufallsanwendungen erfüllt:

Transparente Hardware - Transparentes Protokoll - Transparente Software!

Nach oben

Allgemeines zur Technik

Zufallsquelle

Der Rauscheffekt einer Z-Diode entsteht durch zwei subatomare Effekte, die sich in der Raumladungszone des Halbleiterkristalls abspielen: das sogenannte Schrotrauschen sowie den Avalanche-Effekt. Beide haben einen starken quantenphysikalischen Hintergrund und das Rauschen einer Z-Diode kann daher als analoges Zufallssignal betrachtet werden. Mit einer als Rauschquelle zweckentfremdeten Z-Diode kann man, je nach Typ und Betriebsstrom, ein Rauschsignal generieren, das bereits einen Pegel von mehreren Millivolt und eine Bandbreite von mehreren hundert Kilohertz aufweist. Das relativ starke Signal lässt sich mit unkritischen Verstärkerkonzepten anheben und dann sehr schnell in eine robuste digitale Signalform überführen.
In der vorliegenden Schaltung arbeitet eine handelsübliche 9,1V/0,25W Z-Diode in einer selbststabilisierenden und daher abgleichfreien Verstärkerschaltung. Das Konzept ist nicht auf maximale Ausbeute an Bandbreite, sondern auf maximale Betriebssicherheit ausgerichtet. Mit nur einer weiteren Transistorstufe kommt man bereits auf Digitalpegel. Dieses Signal wird mit Hilfe eines Teiler-Flipflops auf rein digitalem Wege ausbalanciert. Auf diese Weise erhält man einen asynchronen Bitstrom, der nur noch um wenige Promille von der idealen 50:50%-Verteilung abweicht, aber nach wie vor eine Bandbreite in der Größenordnung von mindestens 100 kHz aufweist. Aus diesem Zufalls-Bitstrom holt sich der angeschlossene Computer seine Zufallsdaten per Sample-and-Hold-Zugriff. Und jetzt kommt's:

Echter RS232-Zugriff

Das Bitsampling erfolgt beim XR232 nicht über zweckentfremdete Statusleitungen und spezielle Treiber, sondern ausschließlich im Rahmen des RS232-Protokolls, dessen Anforderungen man unter anderem bei [7] nachlesen kann.

Die vorliegende XR232-Hardware ist sofort einsatzbereit, nachdem die Schnittstelle standardgemäß initialisiert wurde. Nun kann der PC über die Leitung TxD ein bestimmtes Kommandozeichen an den XR232 senden. Der XR232 antwortet über die Leitung RxD mit einem Zufallszeichen, welches selbstverständlich ein gültiges serielles Zeichen ist. Die Funktion lässt sich sogar mit diversen Terminalprogrammen direkt testen.

Der technische Mehraufwand erscheint insbesondere deswegen gerechtfertigt, weil die echte RS232-Übertragung durch den UART und seine Betriebssystemtreiber abgesichert wird. Der UART übernimmt alle zeitkritischen Jobs, wie etwa das Timing für die Codierung und Decodierung der seriellen Übertragung auf den Leitungen TxD/RxD; Synchronisation auf Start- und Stoppbits; Fehlererkennung; Verwaltung der integrierten FIFO-Puffer; Einhaltung der Sequenzregeln (Signalspiel auf den Handshake-Leitungen).
Man kann sich in der Regel darauf verlassen, dass der UART selbst dort, wo er als Teil eines Multi-IO-Chips oder nur noch als USB-RS232-Adapter vorliegt, weitgehend autonom und vor allem ausgesprochen zuverlässig arbeitet. Einige Tests mit USB-Seriell-Adaptern scheinen diesen Optimismus zu bestätigen.

Jede vernünftige UART-Implementierung ist gegenüber Angriffen durch "feindliche Drittsoftware" ziemlich immun. Es ist zwar vorstellbar, dass man (mit direkten Zugriffsrechten auf Hardwareadressen) eine Datenübertragung sabotieren kann, aber die gezielte Beeinflussung von Zeichen, die sich bereits im primären Empfangspuffer des UART befinden, ist nachträglich kaum möglich. Der UART übernimmt ja bereits elementare Sicherungsfunktionen der Übertragung (ISO-Schichten 1 und 2).

Also nochmal im Vergleich:

Die bekannten Pfuschlösungen beaufschlagen permanent eine oder mehrere Statusleitungen mit asynchronem Rauschen, das dann in der Regel über proprietäre Treiber ausgewertet wird, die über Zeitschleifen ihr eigenes obskures Protokollsüppchen kochen. Miese Hardware soll hier durch übelste Programmierpraxis kaschiert werden.

XR232 realisiert zu jedem Zeitpunkt eine echte RS232-Übertragung mit wohldefiniertem Zeitverhalten und Signalformen. Diese Übertragung wird durch die Hardwarekomponente UART bereits zusätzlich abgesichert und von Betriebssystemen direkt unterstützt.

Vorteile für die Programmierung: Weil der UART also schon einen erheblichen Teil der "Drecksarbeit" übernimmt, ist die RS232-Kommunikation auf Hochspracheebene eine ziemlich bequeme Angelegenheit. Der UART wird über Standardtreiber des Betriebssystems bzw. Standardprozeduren der jeweiligen Entwicklungsumgebung angesprochen. Man muss sich insbesondere nicht mehr mit Hardware-Adressen, Interrupts und Realtime-Anforderungen herumschlagen. Meist lässt sich die serielle Schnittstelle über ein Kanal- oder Dateimodell ansprechen, und das funktioniert in der Regel auch dann noch, wenn der serielle Port in Wirklichkeit über einen USB-Adapter emuliert wird!

Nach oben

Bitte acht Bit !

Zur Darstellung eines normgerechten seriellen Datenstroms benötigt man auf der Seite der Peripherie nicht zwangsläufig einen UART oder gar einen Mikrocontroller - Für ein einfaches "Challenge-Response"-Protokoll tun's auch ein paar trickreich verschaltete Logikgatter. Diese Umsetzung bleibt schaltungstechnisch transparent, ist ausgesprochen manipulationssicher und sie kommt ohne eigenen Taktgeber aus.

Natürlich braucht man zur Generierung von seriellen Zeichen eine halbwegs genaue Taktfrequenz von mindestens der doppelten Baudrate. Das ist eine Herausforderung, denn die erforderliche Frequenzgenauigkeit für einen RS232-Baudratengenerator ließe sich nur über einen relativ hochfrequenten Oszillator mit vielfacher Taktteilung erreichen. Mit einem solchen Oszillatorbaustein "onboard" hätte man allerdings eine hochfrequente elektromagnetische Störquelle in unmittelbarer Nähe zur Rauschquelle; selbst mit aufwendigen Abblock- und Abschirmmaßnahmen ließe sich kaum verhindern, dass es zu einer unerwünschten Rückwirkung auf die Rauschquelle kommt.

Aber woher soll der Takt denn sonst kommen? Ganz einfach - vom UART der PC-Schnittstelle! Es gehört ja schließlich zu seinem Job, serielle Zeichen in genau festgelegten Baudraten zu senden! Und so funktioniert's:

Für jedes einzelne Zufallsbyte, das gelesen werden soll, sendet der UART über die Leitung TxD ein bestimmtes serielles Zeichen, nämlich das "U" (ASCII-Code, 55hex). Dieses Zeichen entspricht in der Übertragungsart 8-N-1 der binären Bitfolge 0-10101010-1. Hier bekommt man also mit jedem Taktschritt einen Pegelwechsel, einschließlich der Übergänge zu den Start- und Stoppbits. Damit steht dem Zufallsgenerator eine genaue "Takt-Schablone" zur Verfügung, mit der er nun seinerseits jedes beliebige serielle (Zufalls-)Zeichen generieren kann!
Es genügt allerdings nicht, die Zufallsbits einfach nur mit den zurückgewonnenen Taktimpulsen abzutasten und diesen Bitstrom auf RxD zu geben. Dort, wo die serielle Übertragung Start- und Stoppbits verlangt, darf man selbstverständlich nichts dem Zufall überlassen, anderenfalls würde der UART die meisten ankommenden "Zeichen" als ungültig verwerfen. Also müssen wir für die Übertragungsart 8-N-1 auch noch die Taktschritte mitzählen und jeden 1. und 10. Taktschritt feste Startbits und Stoppbits in den laufenden Datenstrom einprägen. Das lässt sich mit einem Dezimalzähler und ein paar logischen Verknüpfungen bewerkstelligen - und fertig ist das normgerechte serielle Datensignal - siehe Timingdiagramm!
Die über RxD zurückgelieferten seriellen Zeichen nimmt der UART dankbar entgegen und legt sie in seinem Empfangspuffer ab. Dort kann die steuernde Software diese Zufallszeichen nun in aller Ruhe auslesen und weiterverarbeiten.

Netter Nebeneffekt: Der Zufallsgenerator antwortet automatisch in derselben Geschwindigkeit, mit der der UART im PC seine Takt-Zeichen gesendet hat. Bis zu einer hardwarebedingten Maximalgeschwindigkeit von etwa 57600 Baud kann man den XR232 in jeder gültigen Baudrate ansprechen, ohne dass am Gerät irgendetwas neu konfiguriert werden müsste. (Welche Controllerlösung wäre so flexibel gewesen?)

Die Vorzüge dieser Lösung noch einmal im Überblick:

Der XR232-Zufallsgenerator benötigt keinen eigenen Taktgeber.
Kein hochfrequenter Taktgeber "onboard" bedeutet: Keine hausgemachte Störstrahlung, die das Rauschsystem beeinflussen könnte!

Die XR232-Software muss lediglich ein bestimmtes serielles Zeichen über die RS232-Schnittstelle senden.
Im Gegenzug bekommt sie dafür vom XR232 genau ein echtes serielles Zufallszeichen zurückgesendet.
Das sind einfache und unkritische Standardzugriffe, die von jeder Programmierumgebung unterstützt werden.

Bild 2: Zur Erzeugung des seriellen Datenstroms beim XR232

Nach oben

Das Blech

Harte Hardware, weicher Kern. Der sensibelste Teil jedes echten Zufallsgenerators verwendet notgedrungen Analogelektronik. Egal, ob man als Zufallsquelle Strahlen- oder Photodetektoren, rauschende Widerstände, überkritische Oszillatoren oder eben eine Z-Diode einsetzt, immer stellt sich das Problem, dass man ein relativ schwaches elektronisches Nutzsignal verstärken muss, bevor man es in eine robuste digitale Signalform überführen kann. Vielleicht werden die Computer des nächsten Jahrhunderts einmal komplett auf Lichtblitzen beruhen, aber bis auf Weiteres bleibt genau diese analogelektronische Seite die "Achillesferse" eines Zufallsgenerators: Jeder Messverstärker, der schwache Signale elektronisch verstärkt, ist mehr oder weniger angreifbar durch Einstrahlung von Hochfrequenz.

Wenn wir in jeder Hinsicht unabhängige Zufallszahlen produzieren wollen, dann darf sich die Hardware natürlich nicht durch ein ungünstiges Geräteumfeld oder einen gezielten Strahlenangriff beeinflussen lassen ... !

In der vorliegenden Schaltung wurden die grundlegenden "Design-Rules" zur Vermeidung unnötiger EM-Anfälligkeit berücksichtigt:
Separate und gefilterte Betriebsspannungen für Analog- und Digitalteil; kompakter und abgeschirmter Aufbau der Rauschquelle; Abblockkondensatoren für digitale Logikbausteine; Vermeidung oberwellenreicher Signalformen; keine unnötig hohen Taktfrequenzen onboard.

Durch diese Maßnahmen produziert die Schaltung einerseits wenig Eigenstörungen und wird andererseits relativ unempfindlich gegenüber externen Störsignalen, etwa durch Mobiltelefone oder WLAN-Adapter.

Und dennoch: Gegen einen gepulsten kleinen Mikrowellenstörsender in unmittelbarer Nähe (vulgus "Handy") sind die meisten elektronischen Geräte machtlos, sofern keine zusätzlichen Abschirmmaßnahmen getroffen werden. Dazu ein kleiner Test:

GSM-Mobiltelefon, Anmeldung an der Basisstation mit voller Sendeleistung (ca. 750mW ERP).
Das "Handy" wird in etwa 15 cm Abstand zur ungeschirmten Rauschquelle des XR232 (Version 2.0) platziert. Ergebnis unten rechts!


Bild 3a: Gut: Unverdächtiges Pixelmuster vom XR232 @ 38400 bps (Pixeldarstellung mit dem XR232-Tool; Ausschnitt 1/4 VGA-Schirm).	Bild 3b: Weniger gut: Sichtbare EM-Beeinflussung durch 1800MHz-Impulse aus einem GSM-Telefon (in ca. 15 cm Abstand zur nackten Rauschquelle)

Gegenmaßnahme

So dramatisch diese störende Beeinflussung auch wirkt, für den HF-Techniker war sie vorhersehbar... Aber schon ein Blechhäubchen für die Rauschquelle brachte die Störmuster wieder zum Verschwinden. Die Abschirmung dürfte für den gesamten VHF- , UHF- und Mikrowellenbereich wirksam sein. Dasselbe "Handy", mit dem vorher die im rechten Bild gezeigten Störungen provoziert wurden, musste nach Auflöten der Bleche (Oberseite und Unterseite der Platine) schon auf weniger als 2 cm an den XR232 herangebracht werden, damit überhaupt wieder ein messbarer Effekt auftrat. Im Platinenlayout habe ich daher Lötstützpunkte für die Befestigung einer solchen Abschirmhaube fest vorgesehen.

Aber es geht noch besser... In Bild 1 wurde bereits die Heavy-Metal-Version einer vernünftigen Geräteabschirmung gezeigt: Vollmetallgehäuse, gegebenenfalls eine Verdrosselung der Betriebsspannung, und natürlich die optoelektronische Trennung der RS232-Schnittstelle - das sieht nicht nur schick aus, es ist ein sinnvolles Maßnahmenpaket, mit dem sich der Zufallsgenerator schon sehr breitbandig von der Außenwelt abschirmen lässt.
Die Schutzwirkung dieser Variante geht bis hinunter in den VLF-Bereich (Schaltnetzteile, CRT-Monitore). Paranoid sicher wäre die Sache mit einer reinen Batteriespeisung, wenn man alle Komponenten in einem Metallkasten unterbringen würde. Dazu weiter unten noch einige Anmerkungen.

Nach oben

Schaltung

Bild 4:
Schaltplan XR232 Version 2.0 / 2.1 - Zum Vergrößern bitte anklicken!

Schaltungsdetails

Stromversorgung

Der TRNG wird aus einem konventionellen Netztrafo mit mindestens 9 VAC Sekundärspannung versorgt. Gut geeignet sind die robusten Steckernetzteile für analoge Modems und Anrufbeantworter (9 VAC / 500 - 1000mA), zumal deren Trafos in kapazitätsarmer Zweikammerbauweise ausgelegt sind, sodass wir uns keine Störungen aus dem Stromnetz einfangen. Das Wechselstromnetzteil sollte eine Nennspannung zwischen ca. 9-15 Volt haben.

Die Wechselspannung wird über eine diskret aufgebaute Graetz-Brücke, bestehend aus D1-D4 (1N400x) mit parallel geschalteten HF-Abblockkondensatoren C1-C4 (47nF) gleichgerichtet und im ersten Siebelko C5 (1000µF/25V) geglättet.
An dieser Stelle sollten bei Verwendung eines 9VAC-Netzteils ca. 12VDC (Sinus-Spitzenspannung abzüglich Schwellenspannung der Gr-Dioden!), bei Verwendung eines 12VAC-Netzteils etwa 16VDC anstehen. C5 ist somit ein erster wichtiger Messpunkt, falls sich garnichts tut und auch die LED nicht leuchtet.

Die gesiebte Gleichspannung gelangt auf einen konventionellen Festspannungsregler VR1 (7805), der den Digitalteil mit stabilen 5V versorgt. An dieser Stelle kommt selbstverständlich kein Schaltregler infrage, sondern nur ein Linearregler, der von sich aus keine hochfrequenten Störungen verursacht! Daher bitte auch den Abblockkondensator C7 nicht vergessen, dieser verhindert eine Selbsterregung des Spannungsreglers.
Der Strombedarf des Digitalteils beträgt nur maximal 60 mA. Bis ca. 12...16V Eingangsgleichspannung beträgt die Verlustleistung nur etwa 0,3 Watt, und der Linearregler braucht definitiv keinen zusätzlichen Kühlkörper. Wer sich damit unwohl fühlt oder ein Netzteil mit höherer Nennspannung anschließen will, sollte ein Kühlblech vorsehen.

An die Betriebsspannung der Rauschquelle sind andere Forderungen zu stellen. Die Rauschquelle stabilisiert sich in weitem Betriebsspannungsbereich von selbst, ihre Betriebsspannung muss also keineswegs auf einen Festwert stabilisiert sein. Sie sollte aber besonders sauber und frei von Lastschwankungen des Digitalteils sein. Und natürlich muss die Betriebsspannung für die Rauschquelle mindestens 1V über der Nennspannung der verwendeten Z-Diode liegen, damit der Rauscheffekt genutzt werden kann. Da die Rauschquelle nur etwa 1mA Betriebsstrom benötigt, reicht ein klassisches RC-Siebglied, bestehend aus R2 (2k2) und C6 (1000µF) vollkommen aus, um aus der eventuell noch leicht verbrummten Rohspannung an C5 eine hochreine Gleichspannung in Batteriequalität zu machen.

Radikale Idee - Batterie statt Netzteil?
Alles in einen Metallkasten verfrachten und diesen noch besser von der Außenwelt abschirmen, zum Beispiel mit Bleiplatten gegen die Röntgen- und Gamma-Hintergrundstrahlung? Kann man machen...
Meiner Meinung nach spricht erst einmal nichts dagegen, außer vielleicht der Strombedarf der LSTTL-Bausteine. Inzwischen hat sich leider heraus kristallisiert, dass 74HC-Bausteine in dieser Anwendung doch keine vollwertige Alternative zu LSTTL-Bausteinen sind. Man müsste also schon einen kleinen Bleiakku oder eine etwas größere Lithiumbatterie verwenden.
Und immer schön den Ladezustand im Auge behalten! Ich selbst habe mal mit einem 12V-Pack aus Alkali-Batterien experimentiert. Wichtigste Erkenntnis: Wenn man vergisst, das Gerät bei Nichtbenutzung auszuschalten, dann kann es vorkommen, dass man Stunden später immernoch Daten geliefert bekommt, die aber nur noch aus den Werten $00 oder $FF bestehen. Was war passiert - die Rauschquelle hatte ihren Dienst versagt, weil die Batteriespannung bereits die Zenerspannung unterschritten hatte, aber es war noch genügend Saft für den Logikteil, dessen Betriebsspannung ja zusätzlich stabilisiert ist.
Mein Vorschlag für einen Akkubetrieb inklusive ultrasimpler Ladeschaltung, ohne Layout-Änderungen:
Der Pfad vom Pluspol der Gleichrichterbrücke zu C5 und VR1 ist aufzutrennen und an dieser Stelle ein einpoliger Umschalter einzusetzen. Der Pluspol des Akku-Packs wird über diesen Umschalter entweder auf den Pluspol des Gleichrichters oder auf C5/VR1 geschaltet. (Minuspol mit GND verbunden). In den Wechselstrompfad X1 sollte noch ein für den gewünschten Ladestrom dimensionierter Vorwiderstand eingebaut werden. Man könnte dann mit einem Wechsel- oder Gleichspannungsnetzteil den Akku laden, ODER den XR232 mit absolut reinem Gleichstrom betreiben.

Rauschquelle

Die gegenwärtige Version der Rauschquelle (im Schaltbild mit "X" bezeichnete Komponenten) beruht auf einer Kleinleistungs-Z-Diode 9V1 (z.B. Standardtyp C9V1, Philips) und zwei bipolaren NPN-Transistoren (Standardtyp BC547B/C).
Die "Rauschdiode" XZD liegt gleichstrommäßig im Gegenkopplungszweig der konventionellen Emitterschaltung aus XVT1/XR1/XR2. Bei ausreichend hoher Betriebsspannung stabilisieren sich die Arbeitspunkte von Transistor und Diode automatisch im Bereich der Z-Spannung (genau genommen im Kennlinienknick derselben plus Spannungsabfall an der B-E-Strecke des Transistors). Dadurch stellt sich immer der optimale Arbeitspunkt für den "Rauschbetrieb" ein und die Schaltung wird vollkommen abgleichfrei. Nebenbei wird sie in gewissem Umfang gegen Spannungsschwankungen und Temperaturdrift unempfindlich.
Die Kathode von XZD liegt über XC1 wechselstrommäßig direkt auf Schaltungsmasse / Emitterpotenzial von XVT1.
Das dem Diodenstrom überlagerte Rauschen gelangt praktisch ungedämpft auf die Basis von XVT1 und wird von diesem, noch annähernd linear, um etwa den Faktor 250 verstärkt. Am Kollektor steht bereits ein Nutzsignal in der Größenordnung von 1V_SS.
Über XC2 wird der Wechselstromanteil dieses Signals ausgekoppelt und auf die zweite Stufe mit XVT2/XR3 gegeben. Sie hebt das Signal bis in die Begrenzung an. Der Kollektor von XVT2 liefert (über den externen Pullup-Widerstand R3) ein digitales Rauschen mit gut lesbaren TTL-Pegeln.

Balancierung

Das digitalisierte Rauschen geht auf den Takteingang des als Frequenzteiler arbeitenden ersten Flipflops von IC3a (74LS74, Pin 3).
Als digitales Balancierungsverfahren ist die Frequenzteilung in ihrer Effizienz vergleichbar mit der XOR- oder Von-Neumann-Verknüpfung aufeinander folgender Bits: Am Ausgang steht ein nahezu perfekt ausgeglichenes digitales Zufalls-Rauschen. Auch hierbei geht die Hälfte der ursprünglichen Bandbreite verloren, was wir uns in diesem Fall aber durchaus leisten können.
Aus dem balancierten aber nach wie vor asynchronen Roh-Datenstrom holt sich der angeschlossene Computer per digitalem Sample-and-Hold (D-Flipflop in IC3) seine Zufallsbits mit der jeweils benötigten seriellen Abtastrate.

Taktgewinnung

Zur Gewinnung des Sampling-Taktes und zur Steuerung der Logik für die Erzeugung von Start-/Stoppbits wird das vom Rechner kommende TxD-Signal (X2b) konsequent bipolar ausgewertet. So können die Flankenwechsel auch unter schwierigeren Bedingungen (lange Leitung, schwache Leitungstreiber) besonders sicher regeneriert werden. Voraussetzung ist natürlich, dass die Schnittstelle einigermaßen normgerechte und vor allem bipolare Spannungspegel liefert.
TxD steuert, je nach Polarität, entweder die Sende-LED in PC1 oder diejenige in PC2 durch. Die Phototransistoren auf TTL-Seite ziehen abwechselnd die Eingänge von zweien als R/S-Flipflop verschalteten NAND-Gatter in IC1c/d (74LS00) auf Massepotenzial. An den Ausgängen (Pins 8 und 11) dieser bistabilen Kippschaltung findet man ein sauber regeneriertes und flankensteiles TxD-Signal mit TTL-Pegeln.
Mit Hilfe eines Wired-AND (D5/D6, Pullup R5) werden beide Ausgänge des RS-FF kombiniert, um aus jedem Flankenwechsel einen kurzen positiven Impuls zu gewinnen. Sendet der Computer über TxD ein Taktzeichen (0-10101010-1), so liefert die Auswertung der Flankenwechsel genau 10 Impulse im Zeitraster der aktuell verwendeten Baudrate. Damit hat der Zufallsgenerator alles, was er braucht, um eigene serielle Zeichen zu generieren.

Anmerkung zu D5/D6 in Schaltungsversion 2.1: Inzwischen empfehle ich, an dieser Stelle keine Silizium-Dioden einzusetzen, sondern Schottky-Dioden vom Typ BAT42, die einen geringeren Spannungsabfall aufweisen. Auf diese Weise geht man sicher, dass selbst "grenzwertige" Exemplare des 74LS74 in dieser Schaltung das Taktsignal sauber auswerten können. (LOW-Pegelbedingung an Pin 11) Wichtig: Wer die Schaltung bisher mit einem HCMOS-Baustein (74HC74, 74HCT74) betrieben hat, kann die Si-Dioden beibehalten - hier liegt die Schaltschwelle etwa auf Höhe der halben Betriebsspannung.

Zufalls-Bitsampling

Die aus TxD abgeleiteten Taktimpulse gehen direkt auf den Takteingang des zweiten D-FF in IC3b (Pin 11). Es speichert den zum Abtastzeitpunkt vorliegenden Logikpegel bis zum nächsten Takt. An den Q-Ausgängen stehen nun serielle Bits, die bereits genau dem Zeitraster der aktuell eingestellten Baudrate entsprechen. Zum normgerechten RS232-Datenstrom fehlen allerdings noch zwei Kleinigkeiten...

Generierung der Start- und Stoppbits

Im fortlaufenden Zufalls-Bitstrom müssen an den richtigen Stellen Start- und Stoppbits vorliegen. Dazu müssen die über TxD gelieferten Taktimpulse abgezählt werden. Diese Aufgabe übernimmt IC2 (Dezimalzähler 74LS90). Er liefert im Abstand von 10 Takten an seinem Ausgang Qd (Pin 11) ein 2 Takte breites Zeitfenster, in dem je ein Stopp- und ein Startbit eingefügt werden. (Anmerkung: Nur die fallenden Flanken triggern den Zähler, daher muss man auch nur das Teilersystem "durch 5" für diesen Zweck benutzen.)
Durch Verknüpfung von TxD-TTL mit Qd und zeitnahes Setzen der R/S-Eingänge von IC3a/b über Verzögerungsglieder (R4/C9, R6/C10) erreicht man, dass das 1.Bit grundsätzlich LOW-Pegel ("Startbit") bekommt, während als 10.Bit immer ein HIGH-Pegel ("Stoppbit") gesetzt wird. Dieses Verfahren funktioniert unabhängig von der aktuellen Baudrate, da die Verzögerungsglieder lediglich ein paar unkritische Vorher-Nachher-Bedingung gewährleisten müssen. Die Zeitglieder haben auch praktisch keinen nennenswerten Einfluss auf die tatsächliche Bitdauer der Start- und Stoppbits; diese wird ausschließlich durch das aus TxD gewonnene Zeitraster (IC3, Pin 11) bestimmt. Mehr als tausend Worte sagt hoffentlich das Timingdiagramm!

Das beschriebene Verfahren zur Erzeugung serieller Zeichen funktioniert optimal, wenn der Bitzähler mit dem Sendetakt "synchronisiert" wurde, d.h. wenn Start- und Stoppbits der zurückgelieferten Zeichen immer deckungsgleich mit den vom UART gesendeten Zeichen sind. In diesem Fall wird jedes über RxD zurückgelieferte Zeichen ein gültiges serielles Zeichen sein, es können keine "Framing-Errors" entstehen. Dann ist es auch vollkommen egal, wie unregelmäßig die Zeichen über TxD ausgegeben werden, da der UART selbstverständlich immer nur vollständige Zeichen sendet.
Dass die Start- und Stoppbits immer deckungsgleich sind, kann man bei Verwendung eines Zählers sicherstellen, wenn der Zähler zu Beginn der Übertragung einen entsprechenden RESET erhält. Genau genommen ist es hier ein "SET", denn der Zähler soll, wie auch im Timingdiagramm zu sehen, am Beginn der Übertragung auf "5" stehen.
Dieses Setzen des Zählers wird in der vorliegenden Schaltungsversion durch einen weiteren Optokoppler bewerkstelligt. Er wird durch die Schnittstellenleitung DTR gesteuert (Anschlussvariante 1, siehe weiter unten), und zwar so, dass der Set-Eingang des Zählers erst mit dem regulären Öffnen der Schnittstelle freigegeben wird. Auf diese Weise ist sichergestellt, dass der XR232 keinen Mucks von sich gibt, solange die Schnittstelle nicht regulär geöffnet ist, weil der Zähler zu diesem Zeitpunkt an seinem Set-Eingang dauerhaft HIGH ist - erst wenn die RS232-konforme Übertragung beginnt, wird der Zähler freigegeben, indem der Optokoppler den Set-Eingang auf LOW zieht. Jetzt steht der Zähler richtig und ist bereit, Taktimpulse zu zählen, sodass der XR232 bereits für das erste über TxD reinkommende Taktzeichen ein gültiges Zufallszeichen zurückliefert. Eine relativ zeitaufwändige Synchronisationsprozedur ist mit der Schaltung ab Version 2.x also nicht mehr notwendig.

Schnittstellen-Ankopplung

Die Verbindung zur computerseitigen RS232-Schnittstelle erfolgt aus den bereits genannten Gründen der Störsicherheit über Optokoppler.
Wegen der hohen Anforderungen an die Integrität der Signale wird mit echten bipolaren RS232-Pegeln gearbeitet, sodass für TxD und RxD je zwei Optokoppler benötigt werden. Es kommt eine abgewandelte Form der "Potenzialfreien Pegelwandlung für die RS232-Schnittstelle" [6] zum Einsatz.
Über einen weiteren Optokopper wird der Pegelwechsel auf der Statusleitung DTR (oder RTS) auf die Logikseite übernommen und sorgt dort für einen definierten Stand des Taktzählers, sobald die Schnittstelle geöffnet wird. Da man bei DTR (oder RTS) keine sehr schnellen Pegelwechsel auswerten muss, reicht für PC5 ein billiger Standard-Optokoppler (z.B. PC817).
Wenn die Dioden D7-D10 als Schottky-Dioden ausgeführt werden, gewinnt man insgesamt fast 1 Volt mehr Spannungshub für die RS232-Signale. Diese Maßnahme könnte zur verbesserten Betriebssicherheit beitragen, wenn der Zufallsgenerator an einer eher schwachen Schnittstelle betrieben wird.

Nach oben

Stückliste

Platinenlayout

Tipps zum Aufbau

Platinenherstellung

Der neue Platinenentwurf (Bild 5a) enthält nicht nur die zusätzlichen Bauteile, ich habe auch darauf geachtet, etwas mehr Kupfer stehen zu lassen. Nach wie vor dürfte das Bestücken der Platine auch für weniger geübte Lötkünstler kein Problem sein. Mit ihrem "Formfaktor" von mind. 50x100mm passt die Platine in diverse Standard-Gehäuse. "Zufällig" gibt's Photopositiv-Material genau in diesem Zuschnitt... Andere Variante: Gleich drei Platinenlayouts mit ein paar Millimetern Abstand auf eine Europaplatte von 160x100 mm belichten; die kann man dann auch als Grobmotoriker noch verlustfrei durchsägen...

Sowohl für den Toner-Transfer, wie auch für den Ausdruck auf Folie oder Papier muss der XR232-Schriftzug auf dem Bogen zunächst seitenverkehrt zu lesen sein. Die bedruckte Seite soll ja wie üblich direkt auf dem Kupfer bzw. der Fotoschicht aufliegen. Dort muss der Schriftzug nach dem Belichten und Entwickeln also wieder seitenrichtig erscheinen, es sei denn, man hat Bock drauf, die ganze Platine seitenverkehrt zu bestücken und alle ICs auf links zu biegen... jetzt, wo ich's schreibe... hihi...

Bestückung

Siehe Layout/Bestückungsplan in Bild 5b! Zur Bestückung ist eigentlich nichts Besonderes zu sagen. Die vielleicht wichtigste Regel: Zuerst mit den Bauteilen anfangen, die man im weiteren Verlauf allzu leicht vergessen würde... Drahtbrücken und so.
Beim Einsetzen der ICs und Optokoppler bitte darauf achten: Die "Nasen" der Optokoppler PC1, PC2 und PC5 zeigen nach unten, die aller anderen ICs nach oben!

Das aktuelle Paket XR232N.ZIP enthält jetzt auch ein PDF-Arbeitsblatt mit Bestückungsplan und Stückliste auf einer Seite.

RS232-Anschluss

Ein RS232-Kabel darf auch an der schwächsten seriellen Schnittstelle normalerweise noch mehrere Meter lang sein. Das gilt auch für XR232-Kabel. Gut geeignet sind normale Telefonschnüre mit vier Adern (darauf achten, dass die Adern auch lötbar sind, nicht dieser "Faserkram").
Es muss kein geschirmtes Kabel sein. Falls doch, dann bitte das Geflecht nur auf PC-Seite mit dem Massekragen des Steckers verbinden!
Wenn Zufallsgenerator und PC-System hinreichend gut abgeschirmt sind (Metallgehäuse), muss der Zufallsgenerator seinerseits keinen besonderen großen Sicherheitsabstand zum PC-System haben. Am besten macht man das Kabel nur so lang, wie es für den praktischen Einsatz erforderlich ist. (Notfalls gibt's doch 1-zu-1-Verlängerungskabel.)

Für den RS232-XR232-Stecker gibt es zwei mögliche Anschlussbelegungen, die ungefähr gleich gut funktionieren.
Scheinbar hat jeder Programmierer seine eigenen Vorstellungen davon, wie die Handshake-Leitungen DTR/DSR und RTS/CTS im Rahmen eines Hardware-Protokolls "richtig" zu nutzen wären. Je mehr verschiedene Terminalprogramme und Compiler man kennt, umso uneinheitlicher wird das Bild. Beruhigend ist daran nur, dass man es anscheinend in jeder Programmierumgebung hinbekommt, einen XR232 anzusteuern, wenn man nur will. Ich gebe die Anschlussbelegungen und Argumente einmal im unten stehenden Kasten wieder, in der Hoffnung, dass mal jemand mit einem absoluten Knallerargument kommt, welches eindeutig für die eine oder andere Anschlussbelegung spricht:

Anschlussvariante 1

Leitung "c" ist eine Anzapfung der DTR-DSR-Brücke(Anschlüsse 4+6).
DTR geht zu Beginn einer traditionellen seriellen Kommunikation auf positiven Spannungspegel und verbleibt auch dort (weil der Rechner aufgrund der Brücke davon ausgeht, dass das Gerät permanent empfangsbereit ist). Erst nach dem Schließen der Schnittstelle geht DTR wieder auf negativen Spannungspegel zurück.
Auf diese Weise erhält der XR232 eine stabile positive Hilfsspannung für das Opto-Interface (also auch dann, wenn TxD gerade einmal nicht sendet) und der Bitzähler im XR232 wird automatisch initialisiert, sobald der Port geöffnet wird (siehe Erläuterungen zur Funktion der Schaltung und zum Protokoll).
Diese Variante funktioniert äußerst zuverlässig in einer reinen DOS-Umgebung und sehr zuverlässig auch in Terminalprogrammen und Programmierumgebungen, bei denen die RS232-Kommunikation einigermaßen konsequent implementiert worden ist.
Beim Umweg über Windows-API oder Standard-IO unter Linux kann es aber anscheinend vorkommen, dass DTR nicht sicher zurückgesetzt wird, obwohl das berechtigte Programm die Schnittstelle ordnungsgemäß geschlossen hat. Das Phänomen hängt offensichtlich von mehreren Faktoren ab (Betriebssystem, Treiber, "Vorgeschichte" der Schnittstelle, Interrupt-Zuteilung?). In einigen Fällen funktioniert dann die unten angegebene Anschussvariante 2 besser.

Anschlussvariante 2

Hier geht die Leitung "c" an die RTS-CTS-Brücke (Anschlüsse 7+8).
Auch dieses Leitungspaar liefert die positive Hilfsspannung, sobald die Schnittstelle geöffnet wird. Da RTS/CTS direkt gebrückt ist, wird auch hier der Pegel an RTS normalerweise für die gesamte Dauer der Übertragung auf +12V bleiben, da es keinen Grund gibt, den Datenfluss zeitweilig zu unterbrechen.
Eventuell muss man sich als Programmierer explizit darum kümmern, dass auch tatsächlich ein RTS/CTS-Handshake verwendet werden soll. Oft ist die Standardeinstellung, dass beides, also sowohl DTR/DSR wie auch RTS/CTS Handshake benutzt wird. Das macht die Entscheidung nicht gerade einfacher...
Gerade in den Fällen, wo eine Schnittstelle merkwürdigerweise kein ordnungsgemäßes DTR-DSR-Signalspiel mitmachen wollte, ging es dann doch mit der RTS-CTS-Variante.
In den eher seltenen Fällen, wo auch das nicht funktionierte, war keine eindeutige Ursache erkennbar (Betriebssystem, Treiber, "Vorgeschichte" der Schnittstelle, Interrupt-Zuteilung?), hier wären weitere und systematische Tests erforderlich.

Gehäuse

Die optoelektronische Trennung verhindert sehr effektiv, dass man sich Störsignale über das RS232-Schnittstellenkabel einfängt und dass Potenzialunterschiede zwischen PC und XR232 Einfluss auf das Rauschsystem bekommen könnten. Vor direkter Hochfrequenzeinstrahlung schützt diese Maßnahme nur bedingt. Gegen elektrische und magnetische Wechselfelder hilft weiterhin nur eine metallische Abschirmung, also etwa ein Vollmetallgehäuse. Dieses sichert die elektromagnetische Unabhängigkeit des Zufallsgenerators auch unter erschwerten Bedingungen (breitbandige Störstrahlung aus Computerkomponenten, Angriffe durch sogenanntes HF-Fluten).

Beim Einbau in ein HF-dichtes Metallgehäuse sollte Chassis auf direktem Weg mit Schaltungsmasse verbunden werden. Dafür ist der Erdungspin zwischen IC1/IC2 vorgesehen (siehe Bestückungsplan). Die Betriebsspannungsbuchse müsste dann allerdings isoliert eingebaut werden, oder man sieht auch auf dieser Seite eine isolierte Kabeldurchführung mit Gummitülle vor.

Nach oben

Test

Software

Anmerkungen

Neuzeitliche CPUs mit "Zufallsgenerator" on Chip ?

Echter Zufall lässt sich bekanntlich nicht mit Standardkomponenten eines gewöhnlichen PC-Systems erzeugen. Aber auch gegenüber Hardwarekomponenten, die vorgeben, speziell für Kryptoanwendungen eigene Zufallsgeneratoren vorzuhalten, ist sicher ein verstärktes Misstrauen angebracht. Vor allem, wenn die jeweilige "Lösung" nicht in allen technischen Details lückenlos offengelegt ist! So haben einige neuzeitliche CPUs angeblich einen "echten Zufallsgenerator" on-chip [4]. Wäre das nicht eine superelegante Methode zur Generierung von Zufallszahlen für allerlei sicherheitsrelevante (kryptografische) Anwendungen? Ja, das wäre es, aber nur, wenn man den Pressemitteilungen blind vertraut und einfach mal sämtliche physikalischen Gesetzmäßigkeiten außer Acht lässt. Wer dem Glaubensprinzip nicht so zugetan ist, der wundert sich schon allein über die Behauptung, dass diese P**lock Engine auf einer elektronischen Zufallsquelle beruhe, welche das thermische Rauschen ausnutze. Wohlgemerkt, dieser imaginäre Zufallsgenerator befindet sich direkt auf der CPU, und es wird ausdrücklich von einer elektronischen Rauschquelle gesprochen. Dennoch soll diese Zufallsquelle vollkommen unabhängig arbeiten. In direkter Nachbarschaft zu hochfrequenten und höchstfrequenten Taktsignalen... Also, ich finde ja, wenn sie von einer quantenoptischen Rauschquelle gesprochen hätten, dann wäre die Legende wenigstens ein Stück weit glaubwürdiger, aber soooo? Wenn das Teil in allen Tests unglaublich unabhängige Zufallszahlen von bester Qualität produziert, dann liegt doch die Schlussfolgerung nahe, dass es sich in Wirklichkeit um einen komplexen Pseudozufallsgenerator handelt. Nur Pseudozufallsgeneratoren können so designt werden, dass sie bestimmte Testverfahren bestehen. Eine solche Implementierung, deren Details nicht einmal offengelegt sind, hat sicher keine "Hintertürchen" - sie IST ein einziges Hintertürchen und somit für ernsthafte Anwendungen vollkommen indiskutabel.

Zukunftsperspektiven RS232 / USB

Eins vorweg: Nicht nur meiner Einschätzung nach wird RS232 auf industriellen, wissenschaftlichen und medizinisch genutzten Plattformen, also überall, wo Computer ernsthaft eingesetzt werden, vielleicht nicht "für immer", aber doch für sehr lange Zeit verfügbar bleiben. Ganz einfach, weil diese Schnittstelle dort noch immer massenweise benutzt wird, zum Beispiel für Messgeräte, Steuerungen, oder eben für hochwertige externe Zufallsgeneratoren ;-)

Dass die Situation auf dem "Consumer"-Sektor ganz anders aussieht, ist auch klar. Vor etwa zehn Jahren wurde USB eingeführt, und seitdem hört man von einigen Mainboardherstellern immer wieder die wüste Behauptung, RS232 sei "veraltet" / "am aussterben" / "zu teuer". Klar, dass man lieber USB und Firewire pushen will, denn kurzlebige Geräte, die ausschließlich mit noch kurzlebigeren Treibern zusammen funktionieren, bringen einfach mehr Kohle rein!
Dann sollte man aber auch so ehrlich sein, und diese rein marktpolitischen Überlegungen offen zugeben. Es ist nämlich kein zusätzlicher Aufwand und praktisch kein zusätzlicher Kostenfaktor, wenn man von einem Multi-I/O-Chip nicht nur die Ethernet/1394/USB-Leitungen herausführt, sondern auch gleich noch ein paar anspruchslose RS232-Leitungen auf das Board verlängert. Die fadenscheinige Begründung, ein RS232-Pinheader würde "zuviel Platz auf dem Board wegnehmen", will nicht so recht überzeugen. Mancher Hersteller, hier sei VIA einmal ausdrücklich lobend erwähnt, bringt es sogar fertig, auf einigen seiner ITX-Boards noch zwei RS232-Ports unterzubringen!

Für den Consumer, der nichtsahnend auf ein unvollständig ausgestattetes Board ohne RS232-Ports hereingefallen ist, gibt es immernoch die Alternative einer sündhaft teuren PCI-Erweiterungskarte - oder eines sogenannten USB-RS232-Adapters. Dafür braucht's dann wieder spezielle Treiber, aber das Problem der Weiterverwendung von RS232-Geräten auf sogenannten modernen Computern wäre damit im Grunde schon gelöst.
Nach meinen Erfahrungen halten sich selbst billige USB-Seriell-Adapter für EUR 9.95 überraschend gut an die Spezifikationen, zumindest was das Timing der Signale und die Nutzung der Handshake-Leitungen angeht.
Sofern man ein echtes RS232-Gerät über so einen Adapter anschließen will, dürfte es eigentlich keine Probleme geben. Der XR232 arbeitet problemlos mit solchen Adaptern zusammen, obwohl die Schnittstellenspannungen hier oft nur +/- 5V statt +/- 12V betragen. (Hauptsache bipolar!)

Nach oben

Mitmachen

Der "XR232" ist das Open-Source-Projekt eines unabhängigen Hardware-Zufallsgenerators für die serielle Schnittstelle, welcher auf bewährten Techniken, einem transparenten Protokoll und preiswerten Standardkomponenten beruht.

Der XR232 liefert in der jetzigen, gut erprobten Schaltungsversion vorbalancierte Zufallsdaten mit bis zu 57600 Baud an die serielle Schnittstelle. Alleinstellungsmerkmal ist die Tatsache, dass die Übertragung hier zu jedem Zeitpunkt in Übereinstimmung mit den RS232-Standards stattfindet. Daher ist die Nutzung des XR232 prinzipiell auf jeder Rechnerplattform möglich, ohne erst spezielle Hardware-Treiber zu benötigen.

Das äußerst simple Challenge-Response-Protokoll des XR232 ist mittlerweile als kleinster gemeinsamer Nenner für Zufallsgeneratoren an einem echten (oder virtuellen) seriellen Port anerkannt.

Inzwischen steht eine Reihe von Programmierbeispielen für DOS/Windows und Linux-Systeme zur Verfügung. Diese Projekte sind quelloffen über die URLs der jeweiligen Autoren verfügbar. Bitte haben Sie Verständnis, dass ich selbst mich vor allem auf die Hardwareseite konzentriere! Wenn's um die Hardware oder allgemeine Protokollfragen geht, stehe ich gern Rede und Antwort.

Wer die Idee eines Quasi-Standards für robuste und transparente TRNG-Hardware gut findet, den bitte ich herzlichst, das Projekt zu unterstützen und sich mit mir in Verbindung zu setzen!

Platinen oder Bausätze stelle ich zum Selbstkostenpreis zur Verfügung. Bei Interesse bitte mailen!

Nach oben

XR232 - Echter Zufall und echtes RS232-Protokoll

Echter Zufall für alle

Allgemeines zur Technik

Zufallsquelle

Echter RS232-Zugriff

Bitte acht Bit !

Das Blech

Schaltung

Schaltungsdetails

Stromversorgung

Rauschquelle

Balancierung

Taktgewinnung

Zufalls-Bitsampling

Generierung der Start- und Stoppbits

Schnittstellen-Ankopplung

Stückliste

Platinenlayout

Tipps zum Aufbau

Platinenherstellung

Bestückung

RS232-Anschluss

Gehäuse

Test

Elektrische Prüfungen:

Wenn o.k., dann:

... oder:

Software

Anmerkungen

Neuzeitliche CPUs mit "Zufallsgenerator" on Chip ?

Zukunftsperspektiven RS232 / USB

Mitmachen

Links