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 4:
Schaltplan XR232 Version 2.0 - Zum Vergrößern bitte anklicken!
Schaltungsdetails
Stromversorgung
Der TRNG wird aus einem konventionellen Netztrafo mit 9VAC Sekundärspannung und mindestens 100mA Belastbarkeit versorgt. Bestens geeignet sind die üblichen Steckernetzteile für analoge Modems und Anrufbeantworter (9V / 500-1000mA), weil solche Trafos gewöhnlich in kapazitätsarmer Zweikammerbauweise ausgelegt sind, sodass die kapazitive Kopplung ins Stromnetz nicht allzu stark ist. Auch ein konventionelles 12V-Gleichspannungsnetzteil kann verwendet werden. (Bitte kein Schaltnetzteil!)
Die Wechselspannung wird über eine diskret aufgebaute Graetz-Brücke, bestehend aus D1-D4 (1N4001) 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 etwa 12VDC (entsprechend der Sinus-Spitzenspannung), 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. Zwischen 12...16V Eingangsgleichspannung. Die Verlustleistung von maximal 0,3 Watt kann der Linearregler noch ohne zusätzlichen Kühlkörper abgeben. Wer sich damit unwohl fühlt oder ein Netzteil mit höherer Gleichspannung anschließen will, der kann ja ein Kühlblech anschrauben. (Schaden kann es jedenfalls nicht.)
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 BC547C).
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 1VSS.
Über XC2 wird der Wechselstromanteil dieses Signals augekoppelt und auf die zweite Stufe mit XVT2/XR3 gegeben. Sie hebt das Signal bis in die Begrenzung an. Das Ergebnis entspricht dem, was man mit einer Komparatorschaltung erzielt hätte (nur störsicherer): 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 Frequenzzeilung 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 seine Taktzeichen (0-10101010-1), dann 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.
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 des Bitstroms für die Dauer bis zum nächsten Takt. An den Q-Ausgängen erhält man fortlaufende serielle Bits, die bereits genau dem Zeitraster der aktuell eingestellten Baudrate entsprechen. Zum normgerechten seriellen 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 erst dann 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, und es ist egal, wie unregelmäßig TxD seine Taktzeichen ausgibt (der UART sendet selbstverständlich immer nur vollständige Zeichen.)
Dass die Start- und Stoppbits immer decklungsgleich 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. Die relativ zeitaufwändige Synchronisationsprozedur wie bei früheren Schaltungsversionen 1.x ist damit 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 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 keine sehr schnellen Pegelwechsel auswerten muss, reicht für PC5 ein kleiner und billiger Standard-Optokoppler (z.B. PC817).
Stückliste
Stückliste XR232 V2.0 ---------------------
Kondensatoren
C1-C4 47nF C5, C6 Elko 1000µF / 25V C7, C8 100nF keramisch C9, C10 1nF keramisch C11,C12 100µF/25V
Widerstände (alle 1/4W 5%)
R1 330 R2-R9 2k2 R10,R11 220 R12 560 R13,R14 330 R15 4k7 R16 1k0
Halbleiter
VR1 7805 IC1 74LS00 IC2 74LS90 IC3 74ALS74, 74LS74
PC1-PC4 CNY17-I/II PC5 PC817 / LTV817 D1-D4 1N4001 (4002-4007) D5-D10 1N4148 LED1 Farbe wurscht, "normal current"
|
Sonstiges
D-SUB-Buchse oder entsprechendes Anschlusskabel (Brücken im Stecker, siehe Stromlaufplan)
6 x 1 mm-Lötstifte für Anschlussleisten X1/X2
Platine 53 x 100 mm nach Layout
Gehäuse z.B. TEKO-AL4, BOPLA-E430
Betriebsspannungsbuchse (für Standard-9VAC-Steckernetzteile meist 2,5mm Hohlstiftbuchse)
LED-Fassung
Rauschquelle (Version 1.6 - 4/2006)
XR1 4k7 (5%) XR2 47k XR3 100k XC1,XC2 100nF (Folie, MKS) XVT1,XVT2 BC547B-C XZD 9V1 / 0.25 W Z-Diode
Zur Abschirmung des Rauschsystems onboard: Weißblech-Streifen 0,3mm 25x35mm und 20x15mm 4 x 1 mm Lötstifte |
Platinenlayout
Bild 5a/b:
Layout/Bestückungsplan zum XR232 V 2.0 (200dpi).
Nach oben
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 es 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 Transparentpapier (Photopositiv-Belichterfolie) muss der XR232-Schriftzug im Druck
seitenverkehrt zu lesen sein, denn die bedruckte Seite soll wie üblich direkt auf dem Kupfer aufliegen.
Auf der Kupferfläche soll der Schriftzug 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. Es ist auch durchaus möglich, alle Bauteile erstmal durchzustecken und durch Umbiegen der Anschlussdrähte zu fixieren. Die Anschlüsse von hochwertigen IC-Fassungen sollte man nur sehr vorsichtig biegen, da sie relativ leicht abbrechen. Oder einfach mit etwas Kleber die Fassungen provisorisch auf der Platine fixieren. Sieht man ja später nicht. Nach einer nochmaligen Sichtprüfung kann man dann in einem Rutsch loslöten.
Für Optokoppler im DIL-6-Gehäuse gibt es zwar auch hübsche DIL-6-Fassungen, aber weil hier eine ganze Armada von Optokopplern nebeneinander liegt, bietet es sich an, einfach aus zwei SIL-Sockelleisten (Gesamtbreite 18 Pins) eine einzige Riesen-Fassung zu basteln. Diese Variante ist auch in
Bild 1 zu erkennen.
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!
RS232-Anschluss
Ein XR232-Anschlusskabel darf mehrere Meter lang sein. Gut geeignet sind ganz normale Telefonschnüre (aber nur die mit lötbaren Adern, nicht dieser Faserkram...!). Es muss nicht zwangsläufig ein geschirmtes Kabel sein. Wenn 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 keinen besonderen 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 noch 1-zu-1-Verlängerungskabel zum dazwischenschalten.)
Für den RS232-Stecker (genau genommen ist es die Buchse) gibt es zwei mögliche Anschlussbelegungen, von denen ich aber nur die Anschlussvariante 1 ausdrücklich empfehlen kann:
Anschlussvariante 1
Nebenstehend die favorisierte Anschlussbelegung für den 9-poligen SUB-D-Stecker. Diese Variante funktioniert mit den allermeisten Terminalprogrammen auf Anhieb, da sie am ehesten dem normgemäßen Verhalten der Schnittstelle entgegenkommt. Leitung "c" ist die Anzapfung der DTR-DSR-Brücke (Anschlüsse 4+6). Sie liefert dem XR232 einerseits eine positive Hilfsspannung für das Opto-Interface, andererseits wird der Pegel von DTR auch zum kontrollierten Setzen des Bitzählers genutzt (siehe Erläuterungen zur Funktion der Schaltung und zum Protokoll).
Die Brücken zwischen Pin 7 und Pin 8 (RTS/CTS) sowie Pin 4 und Pin 6 (DTR/DSR) lötet man direkt an die 9-polige D-SUB-Buchse, dann muss das Verbindungskabel zum XR232 nur 4-adrig sein.
| 
|
Anschlussvariante 2
Diese alternative Anschlussmöglichkeit verwendet für Leitung "c" die RTS-CTS-Brücke (Anschlüsse 7+8) zur Gewinnung einer positiven Hilfsspannung und zum Setzen des Bitzählers. Allerdings bringt Anschlussvariante 2 keinen technischen Vorteil im Vergleich zu Anschlussvariante 1. Die meisten Terminalprogramme können zwar RTS gezielt hochsetzen, sobald man die Kommunikation eröffnet (Option "RTS/CTS-Handshake" einschalten!), aber dieses Verhalten entspricht nicht unbedingt der ursprünglichen Schnittstellendefinition, nach der RTS-CTS zur Steuerung des laufenden Datenflusses nach dem Zustandekommen einer Verbindung (also nach dem korrekten Abfragen der DTR-DSR-Bedingung) gedacht war. Im Gegensatz dazu berücksichtigen viele Programmierumgebungen die Leitungen RTS-CTS zunächst einmal garnicht, es sei denn, man hat vorher entsprechende Schalter konfiguriert. So gesehen erscheint Anschlussvariante 1 ganz allgemein "logischer". |  |
Gehäuse
An dieser Stelle sei noch einmal daran erinnert, dass man die Gefahren durch elektromagnetische Beeinflussung nicht unterschätzen sollte. Die optoelektronische Trennung verhindert in erster Linie, dass man sich Störsignale über das RS232-Schnittstellenkabel einfängt. Vor direkter Hochfrequenzeinstrahlung schützt diese Maßnahme nur bedingt. Gegen elektrische und magnetische Wechselfelder hilft nach wie vor nur ein Metallgehäuse. Dieses sichert die elektromagnetische Unabhängigkeit des Zufallsgenerators auch unter erschwerten Bedingungen (hausgemachte Störstrahlung aus Computerkomponenten, Angriffe durch sogenanntes HF-Fluten ...).
Beim Einbau in ein HF-dichtes Metallgehäuse kann und soll das Chassis auf direktem Weg mit Schaltungsmasse verbunden werden. Dafür ist der Erdungspin zwischen IC1/IC2 vorgesehen (siehe
Bestückungsplan). Die Betriebsspannungsbuchse muss dann allerdings isoliert eingebaut werden, oder man sieht auch auf dieser Seite eine feste Kabeldurchführung mit Gummitülle vor.
Test
Elektrische Prüfungen:
- Gesamt-Stromaufnahme an einem 9-V-Wechselstromnetzteil: Zwischen 50...100mA (...mehr wäre verdächtig.)
- Unstabilisierte Gleichspannung: 12...16 V an C5
- Stabilisierte Gleichspannung Pin 3 von VR1: 5V+/- 0,25V; Brumm < 50mVss
- Kontrollmöglichkeiten mit Oszilloskop:
Unbalanciertes Rauschen an Pin 3 von IC3
- Kontrollmöglichkeiten mit einem Frequenzzähler:
Balanciertes digitales Rauschen an IC3 Pin 5 oder 6 kann im laufenden Betrieb eine Summenfrequenz von 50...200 kHz erreichen.
(Hinweis: Diese Messmöglichkeit steht nur zur Verfügung, wenn der XR232 im nicht-synchronisierten Zustand belassen oder im laufenden Betrieb gemessen wird, da IC3 sonst gesperrt ist.)
Wenn o.k., dann:
- XR232 anschließen
- Testsoftware (siehe Downloads) laden.
- Sich vergewissern, dass die richtige Schnittstelle benutzt wird. (Zuordnung unter DOS / Windows / Linux kann unterschiedlich sein!)
- Starten und sich wie ein Kugelfisch freuen, dass es auf Anhieb funktioniert!
... oder:
- XR232 anschließen
- Terminalprogramm, z.B. HyperTerminal mit folgenden Einstellungen starten:
- Direktverbindung über COMx
- Bits pro Sekunde: 9600
- Datenbits: 8
- Parität: Keine
- Stoppbits 1 (1.5 und 2 gehen auch!)
- Protokoll: Kein
- Manuell Taktzeichen senden (Shift-U)
- Das sollte nach einigen Tastendrücken etwa so aussehen:

- Wenn man beim Testen bemerkt, dass nicht auf jeden Tastendruck ein Zeichen zurückkommt -
"Anruf - Trennen" und wieder "Anruf - Verbinden" (dadurch wird der Pegel auf DTR runter und wieder hochgesetzt!), nochmal versuchen.
Software
Mit der Schaltungsversion 2.0 ist der Zugriff nun wirklich kinderleicht geworden.
Die Nutzung des XR232 lässt sich jetzt ohne Weiteres "sprachübergreifend" erklären:
- Port öffnen (DTR geht auf +12V)
(ggf. eine Sekunde warten, bis sich die Hilfsspannung aufgebaut hat)
- Taktzeichen senden
- Auf Zeicheneingang im Empfangspuffer warten (wenn keines oder zwei Zeichen eintreffen - Fehler! Weiter bei 7!)
- Zufallszeichen abholen
- Wenn mehrere Zufallszeichen gewünscht, weiter bei 2, sonst:
- Port schließen (DTR geht wieder auf -12V, Bitzähler wird gesetzt und gesperrt)
- Fehlerbehandlung:
Port schließen; eine Sekunde warten; Port wieder öffnen; eine Sekunde warten; Taktzeichen senden; Zurück.
Von meiner Seite stehen weiterhin ein paar Demoprogramme (Punkt [11] der Linkliste) in QBasic sowie das DOS-Kommandozeilentool XR232.EXE zum Download zur Verfügung. Das DOS-Tool ermöglicht die wichtigsten Funktionstests des XR232, aber auch die Erzeugung größerer Zufallsdateien, wobei man verschiedene Balancierungsoptionen anwenden kann. Dieses Tool läuft unter DRDOS, Open-DOS, MSDOS (ab Version 4.0) sowie in einem Fenster unter Win9x.
Längst sind auch zwei aktuellere Entwicklungen für Linux in Gang gekommen; insbesondere möchte ich auf die Projekte [9] und [10] in der unten stehenden
Linkliste hinweisen!
Anmerkungen
Abschirmung
Die Unabhängigkeit von Zufallszahlen ist keine Qualität, die man ausschließlich an statistischen Testergebnissen festmachen könnte - genau genommen gibt es überhaupt kein mathematisches Verfahren, mit dem sich echter Zufall "beweisen" ließe. Eine Tatsache, die die meisten kommerziellen Anbieter von Zufallsgeneratoren im Zusammenhang mit verdächtig guten Testergebnissen ihrer Produkte geflissentlich verschweigen.
Es kommt noch schlimmer: Manch guter Pseudozufallsgenerator besteht eine ganze Reihe von statistischen Testverfahren (z.B. [2]) mit Bestnote. Und von Pseudozufallsgeneratoren wissen wir eines ganz genau: Dass sie mit echtem Zufall garnichts zu tun haben!
Bei logischer Betrachtung ist diese Tatsache dann doch nicht mehr so verwunderlich. Pseudozufallsgeneratoren sind Algorithmen, und die kann man gezielt darauf zuschneiden, bestimmte mathematische Eigenschaften zu haben. Statistische Testverfahren sind ebenfalls Algorithmen. Wir haben also mathematisch erzeugte Ergebnisse mit mathematischen Verfahren getestet...
Was sind statistische Testverfahren also wert, wenn man sie auf echte Zufallsdaten anwendet? Anscheinend können statistische Testverfahren immer nur Indizien dafür liefern, inwiefern die untersuchte Zahlenmenge bestimmte statistische Kriterien erfüllt, die man auch dem echten Zufall zuschreibt. Das ist ja garnicht mehr so doll!
Besonders unangenehm bei der ganzen Sache: Auch unterschwellig vorhandene Störungen eines echten Zufallsgenerators ließen sich mit mathematisch-statistischen Methoden nur schwer nachweisen. Anomalien bei Zufallsgeneratoren sind sicher ein hochinteressantes Thema (z.B.
sowas hier), das weit über die Kryptografie hinausgeht und das ich hier auch garnicht mit ein paar polemisch in die Tasten gehämmerten Worten abhandeln will. Aber solange in diesem Universum physikalische Gesetze gelten, muss man nicht unbedingt "Psi-Kräfte" dafür verantwortlich machen, wenn ein Zufallsgenerator scheinbar verrückt spielt - oft genügen schon Netzschwankungen, ein WLAN-Access-Point oder ein achtlos liegengelassenes Mobiltelefon in der näheren Umgebung, um ein allzu primitives oder auch allzu komplexes Schaltungskonzept aus der Ruhe zu bringen...!
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 Systemkomponenten, die vorgeben, speziell für Kryptoanwendungen entwickelt worden zu sein, ist ein gesundes Misstrauen sicher angebracht. So haben einige neuzeitliche CPUs bereits einen "echten Zufallsgenerator" on-chip [4]. Wäre das nicht eine superelegante und leistungsfähige Methode zur Generierung von Zufallszahlen und kryptografischen Schlüsseln? Ja, das wäre es, wenn man sich allein auf Pressemitteilungen verlassen könnte und sämtliche physikalischen Gesetzmäßigkeiten einmal außer Acht lässt... Nein, aus zwei Gründen: Zum einen erscheint es schon ziemlich gewagt, eine elektronische Rauschquelle in einem Umfeld betreiben zu wollen, in dem es vor Hochfrequenzstrahlung nur so wimmelt. Rauschquelle mitten auf einem Prozessor, das kann eigentlich nur ein Aprilscherz sein. Doch nach Angeben des Herstellers beruht die P**lock Engine ja ausdrücklich auf einer elektronischen Zufallsquelle, also thermisches Rauschen oder Zener-Rauschen, nicht etwa auf einem quantenoptischen Zufallsgenerator. Diese imaginäre Rauschquelle könnte selbst unter Anwendung ausgeklügelter symmetrischer Signalverarbeitungskonzepte nicht wirklich unabhängig arbeiten. Wenn das Ding trotzdem scheinbar unabhängige Zufallszahlen produzieren kann, dann liegt die Schlussfolgerung nahe, dass es sich in Wirklichkeit um einen komplexen Pseudozufallsgenerator handelt. Somit hat diese Implementierung auch garantiert keine "Hintertürchen" - sie IST ein einziges Hintertürchen!
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 dummerweise auf ein unvollständig ausgestattetes Mainboard ohne RS232 reingefallen ist, gibt es immerhin noch die Alternative einer sündhaft teuren Erweiterungskarte, oder eines sogenannten USB-COM-Adapters. Damit wäre das Problem "Weiterverwendung von RS232-Geräten auf sogenannten modernen Computern" im Grunde schon gelöst.
Dennoch werde ich beizeiten mal eine USB-Variante des XR232 in Betracht ziehen. Diese würde auf einem FT232xx-Chip aufsetzen, welcher ebenfalls ein USB/COM-Interface darstellt, nur eben mit reinen TTL-Pegeln auf der RS232-Seite. Man könnte den XR232-"Kern" direkt an dieses Interface anbinden und die Schaltung dann bequemerweise direkt über USB mit Strom versorgen (was ja Sinn der Sache wäre). Allerdings müsste man gleichzeitig auf zwei der wichtigsten Sicherheitsmerkmale des ursprünglichen XR232-Konzeptes verzichten: die galvanische Trennung und die elektromagnetische "Neutralität", die man mit der jetzigen Schaltung erreicht.
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 und preiswerten Bauteilen beruht. Der XR232 liefert vorbalancierte Rohdaten von guter Qualität mit bis zu 57600 Baud an die serielle Schnittstelle. Die Übertragung entspricht zu jedem Zeitpunkt den RS232-Standards, sodass die Ansteuerung auf nahezu jeder Rechnerplattform mit Standardtreibern möglich ist. Hierfür kommt ein simples Challenge-Response-Protokoll zum Einsatz, das möglicherweise als kleinster gemeinsamer Nenner für Zufallsgeneratoren an einem echten oder virtuellen seriellen Port geeignet ist.
Inzwischen stehen einige Programmierbeispiele für DOS/Windows und sogar Gerätetreiber für Linux-Systeme zur Verfügung. Auch diese Projekte sind Open-Source und über die verschiedenen URLs der jeweiligen Autoren verfügbar. Bitte haben Sie Verständnis, dass ich mich vor allem auf die Hardwareseite und die von mir gepflegte DOS-Software konzentriere! In diesem Rahmen stehe ich aber gern für Anregungen und Rückfragen zur Verfügung.
Höchst interessant wäre eine direkt verwendbare Einbindung des XR232 in echte Killer-Applikationen, wie etwa PGP/GNUPG. Wer sich beispielsweise mit Treiberprogrammierung auskennt und 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 kann ich zum Selbstkostenpreis zusammenstellen. Bei Interesse bitte
mailen!Nach oben
Links
[1] Prinzipien zu Rauschquellen, Rauschverstärkern (Englisch):
http://www.ciphersbyritter.com/RES/NOISE.HTM
[2] DIEHARD-Testbatterie (der Klassiker):
http://www.stat.fsu.edu/pub/diehard/[3] Anwendungen von Zufallsgeneratoren, Kryptografie, Zufallsforschung:
www.staff.uni-mainz.de/pommeren/DSVorlesung/KryptoBasis/Zufall.html
www.ibbergmann.org/1633700.htm
www.world.std.com/~reinhold/truenoise.html
www.infotech.tu-chemnitz.de/
www.kuno-kohn.de/crypto/crypto/prngs.htm
www.allemannda.de/Deutsch/Computer/Sicherheit.htm
[4] Obskur, proprietär, esoterisch überladen, kommerziell und hoffnungslos überteuert (oder alles zusammen):
www.westphal-electronic.com
http://noosphere.princeton.edu/index.html
www.true-random.com/index.htm
www.m-tec.ag
www.via.com.tw/en/initiatives/padlock/hardware.jsp
[5] Thomas, Julien: "Zufallsgenerator für die serielle Schnittstelle" FA 12/01, S.1337ff
[6] Thomas, Julien: "Potenzialfreie Pegelwandlung für die RS232-Schnittstelle" FA 11/05, S.1140-1141
[7] Wissenswertes zu RS232/EIA-232 von Wikipedia
http://de.wikipedia.org/wiki/RS232[8] Download der ersten XR232-Demosoftware (DOS) im Download-Archiv des FA, Stichwort "XR232":
www.funkamateur.de[9] Zum auf Linux beruhenden XR232-Projekt von Meinhard Schneider:
http://xr232.dl1fms.de/[10] Das brandneue Projekt "xr232random" für Linux von Jochen Brenner:
http://www.xr232.noedit.de[11] Julien's Paket aus
XR232-Schaltunterlagen und DOS-Tool
Revisionen: 12.02.2007, 09.02.2008, 29.02.2008