Telefonverschlüsselung für Alle
Wer private Daten auf seiner Festplatte für sich behalten will, verschlüsselt
diese. Wer private E-Mails übertragen will, verschlüsselt diese. Wer private Telefonate führen will ... verschlüsselt diese !
Nun ist Kryptografie für viele Menschen noch längst nicht so selbstverständlich,
wie etwa das Zukleben von Briefumschlägen oder das Absichern der Wohnungstür. Was
die Verschlüsselung von Telefongesprächen angeht, hier scheint es auch leider keine
einzige kommerzielle oder nichtkommerzielle Lösung zu geben, die robust
und praktisch
anwendbar
und transparent
und bezahlbar wäre.
1
Dabei wollen wir doch bloß das gesprochene Wort von "A" nach "B" transportieren,
ohne dass ein allzu neugieriger "C" diese Kommunikation mit realistischem Aufwand
entziffern kann. Wir wollen dabei keine unnötigen Datenspuren und Serverprotokolle
erzeugen, und wir wollen auch dort die Option für eine vertrauliche Sprachkommunikation
haben, wo nur ein ganz ordinärer Telefonanschluss zur Verfügung steht.
Da wir am Telefon keine langfristigen strategischen Planungen besprechen,
brauchen wir nicht zwangsläufig eine überkandidelte volldigitale Verschlüsselung,
bei der "ein Superrechner soundsoviele Millionen Jahre rechnen müsste, um den Code
zu brechen". Viel wichtiger als theoretische Zahlenspielchen sollte doch wohl sein, dass
das Kryptosystem in der Realität unkompliziert anwendbar ist und eine robuste und vor allem
nachvollziehbare Sicherheit gewährleisten kann. Der Schutz muss allerdings deutlich über dem
liegen, was kommerzielle "Scrambler" zu bieten haben. Und selbst einem ernsthaften kryptoanalytischen
Angriff sollte das System schon ein paar Tage, vielleicht auch eine Woche standhalten können; eben
gerade so lange, bis die interessanten Informationen schon wieder "veraltet" sind und ihre
verspätete Aufdeckung für den Abhörgegner keinen Nutzen mehr hätte.
Diese taktische Sicherheit lässt sich auch mit einem knackigen Analogverfahren erreichen!
Wobei wir unter "Analogverfahren" im erweiterten Sinne alle Methoden der
Signalverarbeitung verstehen wollen, bei denen das Audiosignal nicht als digitaler Datenstrom verschlüsselt wird,
sondern durch Manipulationen in der Zeit- und/oder Frequenzdomäne. Unter "taktischer Sicherheit" verstehen
wir in diesem Zusammenhang deutlich mehr, als etwa eine reine Verschleierung im Sinne von
Frequenzinversion
2.
Von den klassischen Analogverfahren hat vor allem die gute alte
Zeittransposition
das Potenzial, einem Sprachsignal nennenswerte Komplexität zu verleihen.
Das Verfahren ist simpel, aber hinsichtlich der erreichbaren kryptografischen Komplexität
fast beliebig skalierbar. Wer bereit ist, auf Bedienkomfort zu verzichten, kann nämlich die
Blocklänge und die Teilung bei der Zeittransposition sehr hoch ansetzen, und er bekommt
dafür eine Analogverschlüsselung, die diesen Namen auch verdient.
Allgemeine Vorteile von Analogverschlüsselungen: Im Gegensatz zu einem
volldigitalen Verschlüssler, der einen anspruchsvollen Datenstrom
übertragen muss, und der daher meist auf ein bestimmtes digitales
Transportmedium mit Sicherungsschicht (ISDN, UMTS, TCP/IP) angewiesen
ist, liefert der Analogverschlüssler an seinem Ausgang ein seltsam
klingendes Audiosignal. Dieses Signal lässt sich weiterhin über
schmalbandige Kanäle übertragen. Wegen seines analogen Charakters ist
das Signal weniger störanfällig, als beispielsweise ein Modemsignal.
Für den Analogverschlüssler ist es praktisch egal, ob das
Übertragungsmedium nun ein analoges oder digitales Funkgerät oder ein
analoges oder digitales Telefonsystem ist. Die Installation erfolgt
stets im niederfrequenten Signalpfad, sie ist nur eine Frage von
passenden Adaptern und der Angleichung von Signalpegeln.
Der Analogverschlüssler als universell einsetzbare und
langfristige Option zur Sprachverschlüsselung
Mit den heute zur Verfügung stehenden Komponenten können wir das analoge Verschlüsselungsverfahren der
Zeittransposition nicht nur relativ preisgünstig, sondern auch in einer Komplexität und
Präzision durchführen, die früher undenkbar war. Die Tatsache, dass
jedes schmalbandige Telefonie-System für die verschlüsselte Übertragung
benutzt werden kann, ist unter dem technisch-strategischen Gesichtspunkt auch nicht zu
verachten.
Das Projekt "HEKTOR" ist ein ganz konkreter Vorschlag, wie ein Analogverschlüssler mit
höherem Sicherheitsanspruch für den Hausgebrauch aussehen könnte. Die Technik passt
in ein kleines Kästchen, das sich mit wenigen Handgriffen an jeden analogen Telefonanschluss dranstöpseln
lässt (also z.B. auch: ISDN-Terminaladapter, VoIP-Box). Mit einer Art Akustikkoppler ist
auch der Einsatz ohne jede elektrische Verbindung zum Telefon möglich, beispielweise
in Verbindung mit einem "Handy". Die Umschaltung auf verschlüsselten Betrieb erfordert
die Eingabe eines Tagesschlüssels, einer bis zu 16-stelligen "PIN". Diese Nummer ist gleichbedeutend
mit dem symmetrischen Schlüssel des Kryptosystems. Es werden keine Chipkarten benötigt, der
Verschlüssler speichert Schlüsseldaten nirgendwo dauerhaft ab. Was den Bedienkomfort betrifft, kann
dieser Ansatz vermutlich nicht ganz mit den "idiotensicheren" Produkten für Amtsstuben oder
Militärangehörige mithalten - Dafür sind hier alle technisch-mathematischen Details offengelegt
und für den ernsthaft Interessierten lückenlos nachvollziehbar (Kerckhoff!).
Die hier praktizierte komplexe Variante der Zeittransposition dürfte mit semiprofessionellen
Angriffsmethoden nicht zu brechen sein. Darüber hinaus wurden ein paar nette Komplikationen eingebaut, die
sich um den leistungsfähigen phonetischen Analyseansatz kümmern. Mit dieser Kombination dürfte das
hier vorgeschlagene System auch professionellen Angriffsmethoden für einige Zeit Paroli bieten. Selbstverständlich
werde ich diese Einschätzung
weiter unten noch genauer begründen und zur Diskussion
stellen.
1 Wunsch: Eine einfach bedienbare, hart verschlüsselnde VoIP-Anwendung
einschließlich Anonymisierung der Verbindungsrouten, nachweislich ohne Hintertürchen
für einschlägige Dienste, steht als sexy Open-Source-Lösung weltweit zur Verfügung. Andere telefonieren
mit einem kryptofähigen Netzwerktelefon, dessen Hardware und Software ebenfalls vollkommen offengelegt und zu den
Software-Lösungen kompatibel ist. Kryptografie wird selbstverständlich und massenweise eingesetzt. Ein
gesundes (Selbst-)Bewusstsein in puncto Bürgerrechte hat sich durchgesetzt, ein Mindestmaß an technischem
Sachverstand hat breitere Bevölkerungsschichten erfasst... Wer jetzt noch unverschlüsselt kommuniziert,
gilt als unverbesserlicher "Hab'-nichts-zu-verbergen"-Naivling.
Wirklichkeit: Von den kommerziellen Anbietern darf man wohl keine brauchbaren Krypto-Lösungen erwarten.
Bisherige Open-Source-Konzepte, die mutmaßlich keine Hintertürchen oder Sicherheitslücken enthalten, sind
weiterhin recht heikel bei Installation und Anwendung. Irgendwie fehlt eine idiotensichere "Killer-Applikation", die
breitere Krypto-Begeisterung auslösen könnte.
Das "Internet" als basisdemokratisches und unzensiertes weltweites Kommunikationsmedium hat es außerdem nie gegeben -
und wird es vielleicht auch nicht mehr geben. Kommerzieller Dreck verstopft die Datenleitungen und verschwendet
unglaubliche Kapazitäten an Rechenleistung, Bandbreite, Infrastruktur und Energie. Staatlicher und geheimdienstlicher
Überwachungswahn behindert zunehmend den freien Informationsaustausch auch in vorgeblich "demokratischen" Ländern.
Wenn es nach den Meinungen der Schilys und Schäubles, der Zypressen und Zierkes, der Wiefelspütze und anderer leyenhafter
Terror-, KiPo- und Internet-Spezialisten ginge, dann würde sich schon bald jeder "verdächtig" oder gar "strafbar" machen,
der seine verfassungsmäßig garantierten Rechte auf freie Meinungsbildung und freie Meinungsäußerung in der
Realität mit technischen Maßnahmen absichert, sprich: Anonymisierung, Verschlüsselung, Torrent-Protokolle, alternative
DNS-Server... Wenn diesem Trend des Verbietens und Kriminalisierens nicht auf technischer und politischer
Ebene entgegengetreten wird, dann bleibt den meisten von uns in naher Zukunft nur noch der naive Kinderglaube
an verfassungsmäßig garantierte Rechte von einst - in der Realität totaler Überwachung.
2 Leider beschränken sich die handelsüblichen Spielzeuggeräte auf Manipulationen in der Frequenzdomäne.
Vorteilhaft ist hier die relativ gute Soundqualität und die Tatsache, dass keine nennenswerte
Durchlaufverzögerung entsteht. Viele Systeme für den Telefonbetrieb
ermöglichen gar einen richtigen Vollduplex. Soviel Komfort sollte misstrauisch machen...
Tatsächlich gelten alle Analogverfahren, die nur in der Frequenzdomäne operieren, als
relativ schwach. Selbst die aufwendigsten Varianten der Frequenzinversion (mehrere
Teilbänder, ständiger Wechsel der Mischfrequenzen) haben nach heutigen Maßstäben nicht genügend
Freiheitsgrade, um einen ausreichend großen Schlüsselraum zu generieren.
Aus diesem Grund lassen sich vermutlich auch die kompliziertesten Varianten
der Frequenzinversion mit darauf zugeschnittenen DSP-Tools in Windeseile knacken.
Ehrlicherweise sollte man hier garnicht von Verschlüsselung sprechen, sondern von
Verschleierung. Eine Verschleierung schützt jedoch nur gegen versehentliches
Mithören durch technisch schlecht ausgerüstete Gelegenheitslauscher ...
(Ergänzung: Gelegentlich liest man von ganz neuartigen Ansätzen zur analogen
Sprachverschlüsselung, die auf Grundlage von komplexen Modulationstechniken oder
Elementen der Chaostheorie funktionieren sollen - schade nur, dass diese interessant klingenden
Konzepte scheinbar nie zu praktisch einsetzbaren Geräten werden. Spekulation: Entweder
funktionieren diese Systeme auf realen Telefonsystemen doch nicht so richtig, oder sie funktionieren
und werden der Öffentlichkeit vorenthalten...)
Nach oben
Codename: "HEKTOR"
Das Konzept dieses Sprachverschlüsslers kombiniert zwei
unterschiedliche Verfahrensklassen zur analogen Sprachverschlüsselung:
Zeittransposition mit großzügigen Parametern sowie eine
einfache
Form der Frequenzsubstitution.
Die
Hardware beruht auf einem AVR-Mikrocontroller mit
RAM-Erweiterung und einem Minimum an Analogelektronik drumherum.
Es handelt sich um eine autonome, transparente, experimentierfreundliche und
preiswerte Plattform.
Die
Software realisiert eine komplexe Zeittransposition
mit langen Blöcken und feiner Teilung. Durch diese hoch angesetzten
Parameter für das Transpositionsschema wird erreicht, dass
die Untermenge von brauchbaren Transpositionen (das sind solche, die eine
wirklich gute Durchmischung des Signals gewährleisten) tatsächlich groß
genug wird, um einen Brute-Force-Angriff von vornherein aussichtslos
zu machen. Zusätzlich kommt eine dynamische Frequenzvariation zur Anwendung.
Als ergänzende Maßnahme zur Zeittransposition bewirkt sie, dass die
Symboldauer dynamisch verändert und die Frequenzkomponente auf dem
Übertragungsweg gespreizt wird. Diese Maßnahme soll phonetische Analyseverfahren
weiter erschweren und das Signal widerstandsfähiger gegen Kanalstörungen machen.
Das Schlüsselschema arbeitet mit 16-stelligen Dezimalzahlen und bietet
daher einen praktisch nutzbaren Schlüsselraum von
fast
10 Billiarden unterschiedlichen Startbedingungen. Dies
entspricht einer binären Schlüssellänge von immerhin 53 Bits.
Der Algorithmus zur Generierung der Transpositionstabellen
liefert
für jeden Block eine neue Transpositionstabelle, die auch
nur einmal verwendet wird.
In den eingangs erwähnten
technischen
Daten sind die wichtigsten Parameter der aktuellen Lösung zusammengefasst.
Wer sich diese einmal genauer ansieht, ahnt es sicher schon; der
Name
HEKTOR ist keine sinnige Abkürzung, er leitet
sich vielmehr von der griechischen Vorsilbe "
hekto" ab, also "Hundert".
Hier finden nämlich sage und schreibe
100 Transpositionen pro Sekunde
statt. Der Transpositionsblock ist in 128 Symbole von je
10 Millisekunden unterteilt, sodass sich eine Blocklänge
von 1,28 Sekunden ergibt.
Die rapide Symbolfolgefrequenz stellt zwar relativ hohe Anforderungen
an das Synchronisationsverfahren und an den Übertragungskanal, aber
diese Anforderungen scheinen durchaus noch im "grünen Bereich" dessen
zu liegen, was man von Telefonie-Systemen, die sich an wesentliche
ITU-Anforderungen halten, erwarten darf. Problematisch wird es
offensichtlich im GSM-Netz, und wahrscheinlich auch beim
Umweg über ähnlich stark komprimierende Sprach-Codecs (VoIP).
Durch die Realisierung mit einem Mikrocontroller besteht natürlich
immer die Möglichkeit, an allen technischen Parametern der Zeittransposition
noch einiges zu "drehen".
Zur Handhabung
Es handelt sich um ein klassisches (symmetrisches) Kryptosystem, das
mit memorierbaren Zahlenschlüsseln arbeitet. Eine Zahl kann jedenfalls
nicht verlorengehen oder geklaut werden, wie etwa eine Chipkarte. Eine
bis zu 16-stellige Zahl können wir bisweilen noch im Kopf behalten oder
mithilfe von Eselsbrücken nach Bedarf errechnen.
Das Schlüsselmanagement ist somit recht überschaubar und lässt sich
konsequent handhaben. Im Extremfall genügt es nämlich schon, wenn ein
einziges Mal eine Geheimzahl über einen sicheren Kanal (PGP) vereinbart
wurde, und wenn beide Teilnehmer später ihre Sitzungsschlüssel einfach "offline"
nach einer vorher vereinbarten Regel berechnen. (Mehr Phantasie ist in diesem
Bereich besser, als mehr Technik!)
Technisch gesehen beginnt die verschlüsselte Kommunikation immer als
unverschlüsseltes Telefonat über einen normalen Telefonapparat. Nach
Absprache geben beide Teilnehmer ihren bis zu 16-stelligen
Tagesschlüssel am Gerät ein. (Der Anrufer kann dies auch schon vorher
getan haben.)
Ungefähr gleichzeitig drücken dann beide Teilnehmer die
Bestätigungstaste und aktivieren damit den Verschlüssler. Dieser
schaltet sich auf die Leitung und wirft den Telefonapparat ab. Beide
Teilnehmer müssen anstelle des Telefons nun das Mikrofon und den
Kopfhörer des Verschlüsslers benutzen. Klingt etwas umständlich,
ist aber im Sinne einer sauberen Trennung zwischen sicherer und
potenziell unsicherer Hardware durchaus angebracht! Das reguläre
Telefon kann "verwanzt" sein. Manipulationen am Verschlüssler lassen
sich im Zweifelsfall besser verhindern (Gerät wegschließen, mit
Sprengkapseln absichern... "Mehr Phantasie"!)
Aufgrund der zweifachen Zwischenspeicherung (einmal beim Sender, einmal
beim Empfänger) und zusätzlicher Synchronisationssignale entsteht bei
diesem Verfahren eine ungewöhnlich große
Signalverzögerung von
insgesamt 2,6 Sekunden.
Bei solchen Laufzeiten ist an eine Kommunikation im Vollduplex
natürlich nicht mehr zu denken. Die Kommunikation muss im Halbduplex
(Wechselsprechen) stattfinden, ist dabei aber erstaunlich gut möglich.
Hinweis zu dieser Version
Das Projekt wurde erstmalig in
[10]
veröffentlicht, dort als zweiteiliger Aufbau, bestehend aus
einer Hauptplatine mit einer standardisierten Kontaktleiste
zum Anschluss verschiedener Anpassschaltungen (Telefonsysteme, Funkgeräte).
Dieser "modulare" Ansatz sollte es erleichtern, dass der
experimentierfreudige Nutzer bei Bedarf eigene maßgeschneiderte
Anpassschaltungen für das Funkgerät seiner Wahl entwickeln kann. Ein
universelles
HEKTOR-Radio-Interface, das mit jedem
Funkgerät zusammenspielen würde, gibt es leider bis heute nicht,
und die Entwicklung wird von mir persönlich zurzeit nicht
weiterverfolgt.
Für die Ankopplung an analoge Telefonsysteme existiert aber schon
seit Längerem eine einfache und zuverlässige Schaltung, das sogenannte
HEKTOR-Line-Interface. Auf der Basis dieses bewährten Konzeptes habe
ich nun eine
HEKTOR-Kompaktversion ersonnen, die sich
ausschließlich auf den Telefonbetrieb beschränkt. Dafür passt jetzt
alles auf eine einzige Platine von nur 75 x 100 mm, also
halbes Euroformat. Apropos "Euro", die kompakte Variante spart durch
Rationalisierungseffekte noch einiges an Materialkosten.
Die hier vorgeschlagene HEKTOR-Kompaktversion ist
funktional absolut identisch mit dem zweiteiligen Aufbau aus separater
Hauptplatine und Line-Interface. Es kommt auch bis auf Weiteres genau
dieselbe Software zum Einsatz. Alle Erklärungen zur Schaltungstechnik,
zur Bedienung und zur Sicherheit, gelten sinngemäß für beide Varianten.
Nach oben
 |
Bild 1b: Kompaktversion, offen
|
Technische Umsetzung
Das Transpositionsverfahren lässt sich mit der heute zur Verfügung
stehenden Technik recht preiswert und konsequent umsetzen. Dabei
besteht die vorgestellte Hardware-Plattform lediglich aus einem
größeren AVR-Mikrocontroller, dem
ATmega8515 mit zusätzlichem
Arbeitsspeicher und einer kompakten Software, die die gesamte
Ablaufsteuerung, die Schlüsselberechnung und die Sprachspeicherung besorgt.
Die Sprache wird nicht mit einem internen A/D-Wandler des AVR digitalisiert, da der
ATMega8515 dummerweise gar keinen besitzt. Dafür hat er einen schnellen Analogkomparator zu bieten,
der sich hervorragend zur A/D-Wandlung nach dem Prinzip der
Deltamodulation einsetzen
lässt. (Im Laufe des Projektes hat sich dann schnell herausgestellt, dass die Deltamodulation als
Notlösung hier ein echter Glücksgriff war, da sie für die Signalverarbeitung in dieser Anwendung einige besonders
interessante Eigenschaften aufweist. Mehr dazu weiter unten. Als Einstieg in die
Grundlagen der Deltawandler empfehle ich die Lektüre von [5].)
Für eine akzeptable "Telefonqualität" benötigt man unter Verwendung der
einfachen (nicht-adaptiven) Deltamodulation eine Mindest-Abtastrate von
etwa 64 kbit/s. In ein RAM von lediglich 256 kbit passen dann aber
bereits bis zu 4 Sekunden Sprache. Das ist für diese Anwendung genau
die richtige Größenordnung.
Praktischerweise unterstützt der ATmega8515 bereits in seinem
tiefsten Innersten den Zugriff auf externe Speicherbausteine mit
parallelem 16-Bit-Adressbus. Als Speicher kommt daher ein preiswertes
und robustes statisches RAM vom Typ 62256 zum Einsatz. (Recycling-Tipp:
Alternativ dazu wäre auch ein 61256 mit einem Adaptersockel
nutzbar. Die schnellen SRAMs wurden massenweise auf AT-Mainboards als
externer Prozessorcache verwendet, die müssten also noch in manch einer
Bastelkiste vorrätig sein, schmeißt man ja nicht weg, sowas Edles, die
Dinger waren damals richtig teuer...)
Für den Adress-/Datenmultiplex benötigt man als weiteren Baustein nur
noch ein Halteregister (Latch) vom Typ 74HC573. Das gesamte Timing und
Signalspiel wird zu 100% vom Prozessorkern des ATmega8515 verwaltet.
Sehr praktisch, das Ganze, denn als Programmierer kann man bei den
Zugriffen auf das externe SRAM fast genauso vorgehen, wie bei der
Verwendung des controllereigenen internen SRAMs. Nur mit dem
kleinen Unterschied, dass der externe Adressraum nun geradezu
sagenhafte 32 KB umfasst!
Die Aufschaltung des Sprachverschlüsslers an das Telefonsystem erfolgt
in bewährter Weise über einen NF-Transformator. Der Verschlüssler geht
bei Bedarf als eigenständiges "Nebengerät" auf die Leitung und wirft
den Telefonapparat einfach ab, genau wie ein analoges Modem.
Bei einer Zwischenschaltung in das Hörerkabel, die zunächst naheliegend schien,
weil es immerhin einige amerikanische Spielzeuggeräte so vormachen, hätten wir
im alten Europa keinesfalls einheitliche technische Bedingungen vorgefunden.
Die Anschlussbelegung von Hörerkabeln ist hier nämlich nicht genormt, es kann jeder
Hersteller sein eigenes Süppchen kochen. Es ist nicht festgelegt, welche Impedanzen
die Hörkapseln und Mikrofone haben müssen. Für die Hörkapsel kommen bisweilen sogar
Piezo-Lautsprecher zum Einsatz, und die billigen Elektret-Mikrofonkapseln funktionieren
natürlich nur mit der richtigen Polarität und dem richtigen Betriebsstrom. Für die Zwischenschaltung
eines Sprachverschlüsslers in das Hörerkabel wäre also eine Box mit Steckbrücken und relativ
aufwendigen Anpassschaltungen erforderlich gewesen.
Dagegen sind die Parameter zur direkten Anschaltung an ein analoges Telefonnetz im Hinblick
auf Schleifenstrom, Klingelspannung, Frequenzgang und Wählsystem inzwischen weltweit die gleichen.
In der Regel kommt man mit ein- und derselben Standardschaltung aus, nämlich einem
NF-Übertrager mit ungefähr passender Impedanz.
Allerdings gibt es in der EU noch immer die absonderlichsten nationalen Telefonstecker, eine erschreckende
Auswahl findet sich zum Beispiel
hier.
Die Gesamtkosten der hier vorgestellten Kompaktversion lassen sich locker unter 100 Euro halten. Diese Aussage gilt auch dann noch, wenn
man die Spendierhosen anhat und nun unbedingt alle Teile zu Apothekenpreisen beim "großen C" bestellen sollte.
Nach oben
Zeittransposition (Transposition in der Zeitebene, "Time Domain
Scrambling")
Verschlüsseln
Die Sprache wird blockweise elektronisch zwischengespeichert. Der Block
kann z.B. eine Sekunde Sprache aufnehmen und ist dann noch einmal in
viele kürzere Abschnitte adressierbar. Diese Abschnitte werden hier,
analog zur klassischen Kryptografie, als "Symbole" bezeichnet.
Sobald ein Block mit Sprachdaten angefüllt ist, werden die Symbole nach
einer Tabelle in pseudozufälliger Reihenfolge wiedergegeben. Was über
den Kanal gesendet wird, sind scheinbar zusammenhanglose Sprachfetzen.
Entschlüsseln
Der rechtmäßige Empfänger kennt die vom Sender verwendete
Transpositionstabelle; sie ist der gemeinsame Schlüssel (oder besser:
ein Teilschlüssel) des Kryptosystems. Der Empfänger benutzt diese
Tabelle, um die ankommenden Symbole bereits zum Zeitpunkt ihres
Eintreffens an der richtigen Position in seinem eigenen
Zwischenspeicher abzulegen. Hat der Empfänger auf diese Weise alle
Symbole eines Blockes gesammelt, kann er den zurückliegenden Block
wieder im Klartext abspielen.
|

|
Ein Lauscher, der das verwendete Transpositionsschema nicht
kennt, sieht sich mit einer mehr oder weniger großen Anzahl von
Kombinationsmöglichkeiten konfrontiert. Zunächst einmal gelten für
das Puzzle aus zerhackten Lauten dieselben mathematisch-statistischen
Voraussetzungen, wie etwa für eine klassische Transposition von
Zeichen innerhalb eines Textblockes.
Feine Blockteilung = großer Schlüsselraum
Die Zahl der theoretisch möglichen Vertauschungen bei einer
Blocktransposition ergibt sich vordergründig aus der Fakultät der
möglichen Positionierungen innerhalb eines Blockes. Das
Standardbeispiel aus der Stochastik wäre "Ziehen aus einer Urne
mit durchnummerierten Kugeln ohne Zurücklegen".
Auf diese Weise erhält man schon in dem oben genannten Beispiel
mit nur 8 Positionen eine erstaunlich hohe Zahl von möglichen
Symbol-Reihenfolgen:
8! = 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 = 40.320
Auf den zweiten Blick wird schnell klar, dass ein Großteil der
theoretisch möglichen Transpositionen in einem 8-er-Block gar keine so gute
Durchmischung der Symbole bewirken würde. Schlecht für kryptografische
Zwecke wären zum Beispiel alle Transpositionen, bei
denen längere Symbolfolgen in ihrer ursprünglichen Reihenfolge
auftreten, oder solche, bei denen allzu regelmäßig einzelne Symbole in
ihrer ursprünglichen Reihenfolge auftreten. Dann besteht nämlich die
Möglichkeit, dass ein menschlicher Hörer oder ein sehr
leistungsfähiges maschinelles Spracherkennungsverfahren die
ursprüngliche Aussage noch "heraushören" kann. Schuld
daran ist natürlich die hohe Redundanz der Sprache, die sozusagen als
eingebaute Fehlerkorrektur dafür sorgt, dass wir phonetische Inhalte
selbst unter dem Einfluss von starken akustischen Störungen noch
entziffern können.
Je feiner der Block jedoch aufgeteilt ist ( Teilung in
mindestens 40 Positionen ), umso mehr mögliche Transpositionen
gibt es logischerweise. Auch die Untermenge an kryptografisch
wertvollen Transpositionen, die eine gute statistische
Durchmischung der Symbole gewährleisten, wird dann entsprechend größer.
Kurze Symbole = erschwerte Signalanalyse
Abgesehen vom ineffizienten "Brute Force"-Vorgehen, wäre ein Angriff
auf die Zeittransposition noch über die Analyse des
vorliegenden Audiosignals denkbar. Der Angreifer müsste, ähnlich wie bei der
klassischen Spracherkennung, zunächst einmal versuchen, die phonetisch relevanten
Frequenz- und Hüllkurvenmerkmale
aus dem zeittransponierten Audiosignal zu extrahieren und zu klassifizieren.
Das sind DSP-Verfahren vom Feinsten. Sie dürften relativ viel
Rechenleistung in Anspruch nehmen und müssten auf die
Eigenarten des anzugreifenden Transpositionssystems zugeschnitten
werden. Falls es aber gelingt, die durch Zeittransposition zerstückelten
Phoneme automatisch wieder zusammenzufassen und in eine Art Lautschrift
zu überführen, dann hätte der Angreifer bereits eine Aufstellung der
vorkommenden "Buchstaben". Durch nachfolgende statistische
Verfahren kann er in einem zweiten Schritt versuchen, die
wahrscheinlichste Aussage zu rekonstruieren. Möglicherweise
können noch weitere Korrelationen aus dem Signal abgeleitet werden,
die das Vorgehen unterstützen. Angriffe dieser Art sind für einschlägig
berüchtigte Schnüffelorganisationen angeblich kein Problem.
(Allerdings beziehen sich solche Ausagen immer nur auf marktgängige
Systeme, die alle in einem ziemlich groben Zeitraster und mit relativ
kurzen Blöcken arbeiten.)
Wenn man aber ein besonders feines Zeitraster anwendet, bei dem die
Symbole kürzer sind als 20 Millisekunden, dann tritt ein
sehr interessanter Effekt auf: Der menschliche Hörer bemerkt, dass sich
der akustische Eindruck der zeittransponierten Sprache verändert. Selbst
charakteristische Laute sind plötzlich nicht mehr eindeutig aus dem
Signal herauszuhören, obwohl sie ja im Signal weiterhin vorhanden sein müssten.
Streckenweise bekommt man sogar den Eindruck, es handele sich garnicht mehr
um menschliche Sprache, sondern um "irgendwas Synthetisches". Der Grund
dürfte vor allem darin liegen, dass unser Gehirn zur Unterscheidung von
Phonemen einen kontinuierlichen Höreindruck von durchschnittlich
20-50 ms Dauer benötigt. (Literaturwerte, z.B. unter [9].)
Diese 20-Millisekunden-Grenze scheint also kein reiner
psychoakustischer Effekt zu sein, sondern vielmehr eine
Art "Biokonstante", die den meisten menschlichen Sprachen
gemeinsam ist. Das würde nun aber bedeuten, dass eine Erkennung der Phoneme
anhand von kürzeren Audio-Samples selbst mit leistungsfähigsten maschinellen
Verfahren generell problematisch wäre. Tatsächlich arbeiten alle
gängigen Spracherkennungsverfahren heute mit kleinsten Samples
von 20 ms Spieldauer. In einem deutlich kürzeren Messintervall ließen sich die
Spektralkomponenten für eine Formantanalyse nicht mehr hinreichend genau bestimmen.
Dieser interessante Aspekt führt uns zur vorläufigen Schlussfolgerung:
Durch ein besonders feines Zeitraster ( tSym < 20ms ) lässt sich die
Zeittransposition vermutlich gegen alle Angriffe abhärten, die auf Methoden der Phonemanalyse aufsetzen.
Lange Blöcke = hohe Komplexität
In einen längeren Zeitabschnitt passen mehr Wörter, Silben und Phoneme,
als in einen kurzen Zeitabschnitt. Die besten kommerziellen Scrambler
nach dem Prinzip der Zeittransposition arbeiten mit Blocklängen von
immerhin bis zu einer halben Sekunde. Bei einem solchen System können
ein gutes Dutzend Phoneme in jedem Block vorkommen.
Wenn wir zugunsten des Angreifers annehmen, dass er diese Phoneme
mithilfe automatisierter Analyseverfahren einwandfrei bestimmen
und zusammenfassen kann, dann hätte er also bereits die "Buchstaben",
die er nur noch mit statistischen Mitteln zur richtigen Lösung
rekombinieren müsste. Da die Information jetzt digital vorliegt, sollte
dies blitzschnell möglich sein. Doch was ist das? Schon für
relativ kurze Anagramme gibt es mitunter eine ganze Reihe von
Lösungen, die dann auch noch statistisch ungefähr gleichwahrscheinlich
sind. Hat der Angreifer keine weitere "Kontextinformation" zur Hand,
und kann er keine weiteren Korrelationen aus dem Signal ableiten, dann
steht er jetzt vor einem richtigen Problem: Das Rätsel kann nicht
gelöst werden. Mit jedem zusätzlichen Buchstaben, der im Angebot steht,
wird sich die Zahl der möglichen Rekombinationen, die einen "Sinn
machen" nochmals erhöhen. Diese Mehrdeutigkeit lässt sich auch
nicht durch höhere Rechenleistung beseitigen.
Schlussfolgerung: Möglichst lange Blöcke ( tBlock>
0,5s ) erhöhen die Wahrscheinlichkeit, dass eine Transposition wegen
Mehrdeutigkeiten kryptoanalytisch unbrechbar wird.
Weitere Komplikationen
Durch sinnvolles Kombinieren unterschiedlicher Verfahrensklassen
erreicht man in einigen Fällen deutlich höhere kryptografische Sicherheit,
als es die Mächtigkeit der Einzelverfahren vermuten lässt. Diese
altbekannte Tatsache lässt sich, wenn auch nicht mit besonders viel
Auswahlmöglichkeiten, auf Analogverfahren übertragen. Hier könnte es
sinnvoll sein, die Zeittransposition zum Beispiel durch ein weiteres
Analogverfahren zu ergänzen, das zusätzliche Manipulationen in der
Frequenzdomäne vornimmt.
jt2007
|
Schaltunterlagen HEKTOR-kompakt Version 1.0
1. Schaltplan
HEKTOR-kompakt V1.0 (Anklicken zum Vergrößern oder Herausspeichern)
|

|
| 2. Stückliste
HEKTOR-kompakt Version V1.0 |
------------------------------------
Stückliste HEKTOR VOICE ENCRYPTOR
Kompaktversion für Telefonbetrieb
Version 1.00
------------------------------------
05/2008 Julien Thomas, Kiel
------------------------------------
Widerstände:
R1 100k
R2-R8 470
R9-R12 330
R13, R14 1k0
R15, R16 22k
R17 220k
R18 470k
R19 22k
R20 100
R21 15k
R22 22k
R23-R27 10k
R28 100
R29 47k
R30 100k
R31 470
Kondensatoren:
C1-C5 100nF Kerko
C6 10nF Kerko
C7 100nF Folie (MKS)
C8 100pF Kerko
C9, C10 470nF Folie (MKS)
C11 1µF/10V Elko
C12 22nF Kerko
C13 22µF/10V Elko
C14 220nF Folie (MKS)
C15, C16 22p Kerko, NPO
C17 47µF/10V Elko
C18 47µF/25V Elko
C19 100nF Folie (MKS)
C20 1nF Kerko
Halbleiter:
VR1 7805
D1 1N4001
D2 1N4148
T1-T3 BC547C
T4 BC337-25
IC1 AVR AT90S8515-16 oder
ATMEGA8515-16 PDIP
IC2 74HC(T)573
IC3 SRAM 62256 - 80ns
IC4 CMOS 4053
LED1 LED rot
LED2 LED gelb
LED3 LED grün
LED4 LED grün (alle LED Standard oder
Low Current)
Sonstiges:
- IC-Fassungen für IC1-IC4
- Schwingquarz 10 MHz RM5 (HC18)
- Tastatur Matrix 3x4 (z.B. Conrad Bestnr. 709840, ggf. passenden
Rahmen mitbestellen)
- Stiftleisten/Platinenstecker-Kombinationen für X1-X5
- 2x5 pol. Wannenstecker für X6 (ISP)
- Steckverbindungen zum Anschluss der LEDs
- Platine nach Layout 75 x 100 mm
- NF-Übertrager für Telefonanwendungen, Übertragungsverhältnis 1:1 bis 1:5 DER
GLEICHSTROMWIDERSTAND AUF DER HOCHOHMIGEN SEITE (a/b) MUSS MINDESTENS 100 OHM BETRAGEN. (z.B. Conrad NTE-1 515940, Conrad NF-Uebertrager 515701)
- Re1 - 5V/6V DIL-Relais 2fach Umschalter, Spulenwiderstand mind. 90 Ohm, z.B. von Reichelt:
Fin30.22.9 6V (Finder), RY05 W-K (Takamisawa)
- Modular-Einbaubuchse RJ11 6-polig, z.B. von Reichelt: MEB6-6
für TAE-N-Kabel mit RJ11-Stecker auf der anderen Seite, z.B. von Reichelt: TAE 4NWS-I
|
|
3. Layout HEKTOR-kompakt
Platinenversion V1.0, einseitig, 300dpi, 75 x 100 mm (Anklicken und
Herausspeichern möglich)
|
|
Schaltungsdetails: HEKTOR-kompakt Version 1.0
Allgemeines
Die Schaltung wird über einen 7805-Linearregler (VR1) mit
stabilisierten 5 Volt versorgt. Der Bereitschaftsstromverbrauch bei
laufender Verschlüsselung liegt unter 60 mA. Ein Großteil
dieses Strombedarfs wird durch die LEDs, den Ruhestrom des NF-Verstärkers
sowie durch ein eingeschaltetes Line-Relais verursacht. Wenn man hier kein
allzu niederohmiges Exemplar verwendet, dann kommt die gesamte
Schaltung auch im aktiven Betrieb nicht über 100 mA Summenstrom.
Das kann unser 7805 noch ohne Kühlkörper regeln, wenn wir mit der
Eingangsspannung nicht deutlich über 9V gehen.
Hinweis: Für einen Batteriebetrieb müsste die
Summenspannung der Zellen noch mindestens 6 V betragen, damit eine
ausreichende Stabilisierung über VR1 gegeben ist. Also mindestens 4
frische Alkalizellen mit 1,5 V. Diese könnten allerdings nicht voll
ausgenutzt werden, denn schon bei einer Entladung auf 1,3 V würde das Spannungsgefälle
nicht mehr zur Stabilisierung ausreichen. (Andererseits lassen sich Alkali-Zellen ganz wunderbar
"wiederauffrischen", da gab es doch mal so einen Artikel über den Umbau
von herkömmlichen Billigladegeräten...)
Ein Akkupack aus NiCd- oder NiMH-Zellen müsste mindestens 5 oder besser 6 Zellen
beinhalten (6,0V bzw. 7,2V Nennspannung), damit wäre genügend Stabilisierungsspielraum
vorhanden und das Gerät kann die Akkus mit langer Laufzeit gut ausnutzen.
Kryptomaschine
Herzstück ist der AVR-Mikrocontroller
ATmega8515 (IC1). Die
Beschreibung seiner Peripherie erfolgt hier anhand des
Stromlaufplans
zur HEKTOR-Kompaktversion
im Uhrzeigersinn um den Baustein herum:
Port A
Die Leitungen PA0-PA7 sind ein 8 Bit breiter Adress- und Datenbus.
Diese 8 Portleitungen führen in ihrer Funktion als Adressleitungen direkt auf
das Latch IC2 und gehen parallel dazu auf die SRAM-Datenleitungen D0-D7
von IC3.
Port E
Der Ausgang PE0 liefert ein "PTT"-Signal, bei dem HIGH-Pegel für den Sendemodus
steht, LOW für den Empfangsmodus.
Der Strom aus dem AVR-internen Porttreiber reicht zur Ansteuerung der Rx/Tx-LEDs und
eines weiteren Logikeinganges gerade aus. In der zweiteiligen HEKTOR-Variante wird
dieses Signal auf die Steckverbindung für das jeweilige Interface
herausgeführt, es müsste zur Steuerung eines Funkgerätes in der Regel
noch invertiert werden (Schalttransistor oder Optokoppler), wodurch
dann ein gewisser Schutz für den Controller gegeben ist. In der HEKTOR-Kompaktversion
geht dieses Signal direkt auf den Steuereingang des Signalumschalters IC4 (CMOS4053).
Der Ausgang PE1 arbeitet in seiner Funktion als Address-Latch-Enable
(ALE), er steuert den Adress-/Datenmultiplex über IC2 (74LS573 bzw. 74HC573).
Die Leitung PE2 liefert das Signal zur Umschaltung zwischen
Transparentbetrieb und Verschlüsslerbetrieb.
HIGH entspricht verschlüsseltem Betrieb. Die an +5V liegende LED1
leuchtet demnach nur, wenn der Ausgang PE2 auf LOW steht. Dann zeigt
sie durch ihr mahnendes rotes Leuchten an, dass sich der Verschlüssler
noch im unsicheren Transparentmodus befindet. Dieses Signal wird zur Schaltstufe des
Telefoninterfaces weitergegeben, wo es über T4 (BC337) das Line-Relais Re1 durchschaltet.
Port C
Port C liefert weitere 8 Adressleitungen, von denen aber nur 7 benötigt
werden. Zusammen mit PA0-PA7 bilden PC0-PC6 also 15 Adressbits für den
direkten Zugriff auf IC3 (32-kByte-SRAM vom Typ 62256).
Port D
Die Lese- und Schreibvorgänge auf das SRAM werden durch die
Controllerports PD6 und PD7 (in ihrer Funktion als /WR und /RD)
koordiniert.
Die Leitung PD2 dient zur Ansteuerung von LED2 (Sync).
Die Leitung PD3 ist als Eingang konfiguriert und wertet
Synchronisationssignale aus. Dazu wird das über Audio-IN ankommende
Signal über T1 bis in die Begrenzung verstärkt, sodass am Kollektor
bereits ein Quasi-TTL-Pegel zur Verfügung steht (Kollektorwiderstand
wird vom AVR-Port bereitgestellt). Die Erkennung der richtigen
Synchro-Frequenzen erfolgt rein softwaretechnisch.
Leitung PD4 ist als Ausgang konfiguriert und bildet mit R22 und C9
einen Tiefpass für die Rückführung der Delta-Regelgröße auf PB3, das
ist der nichtinvertierende Eingang des internen Komparators (AIN1).
Vergleichsgröße für den Delta-Modulator ist natürlich das
Audio-Eingangssignal, welches über C14 auf den invertierenden Eingang
PB2 (AIN0) eingekoppelt und über den Spannungsteiler R15/R16 mit einem
Offset von etwa der halben Betriebsspannung vorgespannt wird.
Der Ausgang PD5 liefert das Ausgabesignal (Delta-Bitstrom) an einen
ähnlich dimensionierten Tiefpass (R23, C10) mit nachgeschalteter
Pufferstufe (T2 und umliegende Bauteile). Der Audio-Ausgang wird unter
Zwischenschaltung des Koppelkondensators C13 (47µF) zur
Telefonanschaltung weitergeleitet.
(Anmerkung: Des Weiteren waren auf der ursprünglichen HEKTOR-Platine noch die Leitungen
PD0 (RXD) und PD1 (TXD) auf einen 4-poligen Steckverbinder zusammen mit Vcc und GND herausgeführt.
An diesen Stecker konnte man direkt einen RS232-TTL-Wandler, wie z.B. unter [7], anschließen,
um die Ausgabe von bestimmten Programmteilen am PC aufzeichnen zu können.
Da diese UART-Funktionen jedoch Rechenleistung kosten, wurden sie für die reguläre Nutzung
des Sprachverschlüsslers wieder abgeschaltet. Die entsprechenden Zeilen zum Debugging sind aber im Programmtext
noch in auskommentierter Form zu finden.)
Port B
Einerseits dienen die Leitungen PB0,1,2 (Spalten) und PB4,5,6 (Zeilen)
zur Abfrage der angeschlossenen 3x4-Matrixtastatur. Andererseits werden
die Leitungen PB2/PB3 noch als Komparatoreingänge (AIN0/AIN1) zur
A/D-Wandlung nach dem Verfahren der Deltamodulation genutzt.
Darüber hinaus können PB5/PB6/PB7 auch noch als ISP-Schnittstelle
(MOSI/MISO/SCK) zum Flashen des Controllers
genutzt werden. Dazu wurde nun auch auf der Platine der Kompaktversion
wieder ein ISP-Stecker vorgesehen, die 10-polige Steckverbindung X6.
Sie entspricht der von Atmel spezifizierten Anschlussbelegung und kann
also mit einem ensprechenden Programmer für serielle ISP/SPI direkt
angesprochen werden (AVR-ISP, diverse Parallelprogrammer).
Telefonankopplung
Dieser Schaltungsteil entspricht weitgehend dem
HEKTOR-Line-Interface
(HLI), welches in der zweiteiligen Aufbauvariante als separate
Platine realisiert wurde.
Der Anschluss an das Telefonsystem erfolgt über ein vierpoliges Kabel
mit TAE-N-Stecker. Die Anschaltung findet wie bei Modem und Anrufbeantworter
durch Abwurf des Telefons und Aufschaltung des eigenen Line-Übertragers
auf die Leitung statt.
Solange der Verschlüssler keinen Betriebsstrom hat oder sich im
Transparentmodus befindet, wird das Leitungspaar a/b über die
Ruhekontakte des Line-Relais Re1 unverändert an a'/b' weitergegeben (also
entweder an das Telefon oder an das nächste Nebengerät).
Erst, wenn der Verschlüssler in den aktiven Betrieb umschaltet, legt
der Controller seine Leitung "Aktiv/Transparent" (PE2) auf HIGH und
schaltet damit den Transistor T4 durch. Jetzt zieht das
Line-Relais an, wirft den Telefonapparat ab und schaltet
stattdessen seinen eigenen NF-Übertrager (Tr1) auf die
Leitung. Der Übertrager sorgt durch seinen Innenwiderstand in der
Größenordnung von 100 bis 300 Ohm dafür, dass weiterhin ausreichend
Schleifenstrom fließt und eine günstige Anpassung an den
Quellenwiderstand der Telefonleitung vorliegt. HINWEIS: Die relativ hochohmige
Seite soll auf der Seite des Telefonnetzes liegen.
Weil das Umschalten weniger als 0,1 s dauert, wird die bestehende
Verbindung gehalten. Nun können niederfrequente Signale in beide
Richtungen übertragen werden.
Die Umschaltung der Signalrichtungen vom Controller zum Übertrager und
zu Kopfhörer und Mikrofon besorgt ein CMOS-Signalumschalter (IC4, Typ
4053). Das Mikrofonsignal von einer Elektret-Kapsel (z.B. im Headset)
muss noch etwa 10-fach vorverstärkt werden, dafür ist die Transistorstufe mit
T3 zuständig.
In der Stückliste sind Typenbezeichnungen von Übertragern
angegeben, die in dieser Anwendung bereits erfolgreich eingesetzt
wurden.
Recycling-Tipp: Alte Modems oder Anrufbeantworter enthalten in der
Regel auch einen Übertrager, der sich ganz hervorragend für diese
Anwendung eignet.
Hinweis zum Übertrager: Das Übersetzungsverhältnis ist nicht kritisch.
Die Synchronisation ist darauf ausgelegt, in einem weiten Pegelbereich zu
funktionieren, und auch der Pegel der Audiosignale darf in einem weiten
Rahmen schwanken. Sowohl die Deltamodulation als interner Codec, wie auch
die allgemeinen technischen Spezifikationen von Telefonsystemen erlauben da einen
gewissen Spielraum. Zu hohe Pegel werden immer begrenzt.
Nach oben
Anschlüsse auf der Platine HEKTOR-Kompaktversion
X1
|
Anschluss einer unstabilisierten
Gleichspannungsquelle 6-9 V, Belastbarkeit etwa 250 mA.
Die Spannung sollte aus einem sauberen Netzteil oder (bei
Funkanwendungen) aus Batterien stammen. |
X2
|
Hier wird eine 3x4-Matrixtastatur angeschlossen,
über die die Schlüsseleingabe stattfindet und wesentliche Gerätefunktionen
gesteuert werden (Z.B. eine Taste als Sprechtaste).
|
X3
|
Analoger Endgeräteanschluss -
hierfür sollte ein 4-poliges Kabel mit TAE-N-Stecker benutzt werden,
damit der Verschlüssler als Nebengerät die Leitung exklusiv benutzen
kann (wie Modem oder Anrufbeantworter).
|
X4
|
Mikrofon-Anschluss für
direkten Anschluss einer 2-poligen Elektret-Mikrofonkapsel bzw.
Mikrofon des Headsets
|
X5
|
Kopfhörer-Anschluss, vorzugsweise hochohmiges Exemplar
für Sprachwiedergabezwecke, z.B. Kopfhörer eines PC-Headsets |
X6
|
ISP-Anschluss (2x5-polige
Stiftleiste) nach Atmel-Spezifikationen
|
LED
1-4 |
Vier zweipolige Steckverbinder für den direkten Anschluss von Status-LEDs
zur Anzeige der verschiedenen Betriebszustände. |
Nach oben
Hinweise zum Nachbau
Das Gerät lässt sich problemlos mit Amateurmitteln aufbauen, zumal
hier ausschließlich bedrahtete Bauteile zum Einsatz
kommen. Die einseitige
Platine stellt an den Ätzvorgang nur
mäßige Anforderungen. Sogar mit dem Toner-Transferverfahren könnte es
noch klappen (wenn man
wirklich gut ist). Die Herstellung nach dem
Fotoverfahren ist vollkommen unproblematisch.
Für das
Flashen des Mikrocontrollers gibt es auch auf der
Kompaktversion wieder einen 10-poligen ISP-Stecker (hier mit X6
bezeichnet). Hier können wir jeden Programmer für das serielle
Programmieren von AVRs anschließen. Beim Flashen der Fusebits und
der Firmware bitte unbedingt die
Hinweise weiter unten
beachten!
Für die
Steckverbindungen auf der Platine kommen verschiedene
Systeme im Rastermaß 2,54 mm infrage. Auch Selbstgebasteltes aus
SIL-Sockelleisten, Litze, Heißkleber und Phantasie kann verwendet
werden. Die Anschlüsse für Betriebsspannung
(X1), Tastatur (X2) und Telefonanlage (X3) sollten einigermaßen
stabil und rutschsicher ausgeführt sein.
Ein Quell immerwährender Freude ist sicher wieder der
mechanische Zusammenbau. So benötigt die Zahlentastatur
einen einigermaßen passgenauen Gehäuseausbruch, was der geübte
Laubsäger natürlich mit links und mit nur geringem Nachbearbeitungsaufwand
durchaus hinkriegen kann... Wer aber darauf keinen Bock hat, sollte für
die Tastatur gleich einen überteuerten
Rahmen
mitbestellen. Der bessere optische Eindruck, den das
Gerät dann später macht, entschädigt für alles.
Beim Anschluss der
Matrixtastatur ist auf die richtige
Zuordnung von Pin 1 (erste Spalte, im Stromlaufplan Leitung A1) zu
achten, falls das Kabel auf der Tastaturseite direkt angelötet werden
soll. Hierzu sei angemerkt, dass die Tastatur von C**rad keine
Pin-1-Markierung hat und dass man bei der Lektüre des dazugehörigen
"Datenblatts" von Informationen überschüttet wird. Um die Raterei
etwas abzukürzen: Wenn wir die Tastatur seitenrichtig vor uns
liegen haben und sie dann umdrehen, dann liegt auf der Rückseite
Pin 1
rechts.
Für den Anschluss des TAE-Kabels gibt es mehrere Optionen. Ein direktes
Festlöten auf der Platine ist nicht empfehlenswert. Es sollte
mindestens für X3 eine 4-polige Steckverbindung dazwischen gesetzt
werden. Ich selbst verwende RJ11-Einbaubuchsen und beschalte diese so,
dass ein genormtes TAE-N-Modemkabel angeclippt werden kann. Das
bedeutet: Die Adern a/b liegen auf den beiden mittleren Anschlussfedern (3/4),
die Adern a'/b' liegen auf den weiter außen liegenden Anschlussfedern
(2/5). Eventuell vorhandene weitere äußere Anschlüsse (1/6) müssen
unbeschaltet bleiben. Selbstverständlich wäre auch jede andere
"Hausnorm" möglich, is' ja'n freies Land oder so, aber dann bitte
nicht wundern, wenn die Sache nur bei Vollmond mit einem bestimmten
Anschlusskabel funktioniert!
Es sei noch darauf hingewiesen, dass selbstgebaute Telefongeräte ganz bestimmt nur
an private Nebenstellenanlagen angeschlossen werden dürfen ;-)
Nach oben
Tests
Die Software beinhaltet einen elementaren
Testmodus, welcher
direkt nach dem Einschalten, einem Hardware-Reset oder nach dem
Neustart des Programms mit der Taste "
# " aktiviert
werden kann. Das Programm geht dann direkt in
eine Endlosschleife, in der die Interruptroutine kontinuierlich das
Synchro-Signal "Blockstart" (ca. 1,5 kHz) erzeugt. Das Signal wird aus dem RAM heraus mit
konstanter Lesegeschwindigkeit erzeugt, sodass auch permanent
Speicherzugriffe mit konstanter Geschwindigkeit stattfinden. Dabei ist
die Übertragungsrichtung im Testmodus jedoch auf "Empfang" festgelegt,
sodass der Ton direkt über das Headset abgehört werden kann.
Eine qualitative Bewertung ist schon per Ohr möglich: Der Ton sollte
relativ weich klingen (kein Rechteck, eher Dreieck, wenig Oberschwingungen) und
er darf keine hörbaren Frequenzschwankungen aufweisen.
Messsignale im Testmodus
- Mit Oszilloskop oder Frequenzzähler an Pin 15 des
Controllers (PD5, Ausgabe Deltamodulation) sollte im Testmodus ein
TTL-Rechteck mit 50-zu-50 Prozent Tastverhältnis und 1510 Hz zu messen sein;
- Am unbelasteten Audioausgang (C13) soll das verstärkte und
geglättete Signal (dreiecks-ähnlich) mit einem Pegel von mindestens
2 Vss vorliegen.
- An den Pins 16/17 (PD6/PD7) des Controllers treten
pulsförmige Taktsignale (Speicherzugriffe) mit einer Frequenz von 12080 Hz
auf. (Anmerkung: Die angegebenen Frequenzen beziehen sich auf die
aktuelle Programmversion 1.0b.)
Wenn dies soweit alles zutrifft, haben wir folgende Gewissheiten: Das
Programm ist lauffähig (korrekt geflasht, Alter!); der Taktoszillator des AVR
läuft mit dem externen 10-MHz-Quarz; Treiberverstärker und
Signalumschaltung funktionieren. Gut gemacht!
Funktionstest
Nun möchten wir sicher schonmal das Ver- und Entschlüsseln testen.
Dazu ist nicht unbedingt ein zweites Gerät erforderlich. Es genügt,
eine verschlüsselte Sendung aufzunehmen und danach wieder in das
Gerät einzuspielen.
Mit einem alten Diktiergerät oder einem schlechten Cassettenrecorder
dürfte es wegen der Gleichlaufschwankungen schiefgehen. Mit einem
guten Cassettendeck, einem Tonbandgerät, einem MP3-Diktiergerät
oder mit der Soundkarte des PC sollte es problemlos funktionieren.
Das HEKTOR-Synchronisationsverfahren kann Laufzeitschwankungen in einem
Bereich von maximal 20 ms ausgleichen. Auch die Pegelverhältnisse
bezüglich des Audiosignals sind nicht sehr kritisch. Wichtig ist,
dass das Programm für Aufnahme und Wiedergabe wirklich kontinuierlich
aufnehmen und wiedergeben kann. Sonst wundert man sich, warum eine
scheinbar perfekte Aufnahme immer wieder zu Entschlüsselungsfehlern führt.
An einem PC sollten wir alle anderen Fenster schließen und konkurrierende
Prozesse beenden. Als Aufnahme- und Wiedergabeprogramm sollte immer
das einfachste verfügbare Programm verwendet werden, das die geringste
Systemauslastung erzeugt. Schon eine Pause von mehr als etwa 20 ms,
die wir mit dem Ohr kaum wahrnehmen, kann bereits das ganze Zeitschema
durcheinanderbringen.
Aufnahme: Signal von den Adern a/b (X3-2 und
X3-3) direkt auf einen LINE-IN der Soundkarte oder des Aufnahmegerätes
geben. Polung egal. Sprechtaste drücken und einen kompletten Durchgang
von mindestens 10 Sekunden mitschneiden.
Wiedergabe: Die Adern a/b mit dem Lautsprecherausgang bzw.
LINE-OUT des Aufnahmegrätes anschließen. Polung egal. Die Aufnahme
wieder einspielen.
Wichtig: Vergessen wir nicht, den Verschlüssler vor dem Wiedereinspielen
einer solchen Testaufnahme nochmal mit dem verwendeten Code neu zu
initialisieren - ansonsten werden wir uns trotz einwandfreier Synchronisation
nicht wiedererkennen...!
Um den Test zu vereinfachen, enthält das
Paket
im FA-Download
noch ein paar Audiodateien, die mit der aktuellen Software (und vielleicht
auch mit folgenden Versionen) kompatibel sind und absichtlich in eine miese
Telefonqualität von 8000 Hz / 8 Bit PCM umcodiert wurden.
Auch diese Beispiele sollten sich mit dem Wartungscode * # oder * 0 #
problemlos entschlüsseln lassen.
Nach oben
Zur Bedienung
Ablauf
- Die Verbindung wird über konventionelle Festnetz-Telefone hergestellt.
- Nach Absprache geben beide Teilnehmer, ungefähr zur gleichen Zeit, ihre Tagesschlüssel ein:
- Die Schlüsseleingabe beginnt mit "Sternchen" und darf bis zu 16 Dezimalziffern enthalten.
- Nach Bestätigung mit der Taste "Doppelkreuz" schaltet sich der Verschlüssler in die bestehende Telefonverbindung.
- Das konventionelle Telefon wird von der Leitung getrennt und der Verschlüssler schaltet sich auf die Leitung.
Die Verbindung wird vom Verschlüssler übernommen und gehalten.
- Beide Geräte befinden sich nun in Bereitschaft.
- Hörer des konventionellen Telefons auflegen, Sprechgarnitur aufsetzen.
- Wer zuerst auf die Sprechtaste " 0 " drückt, darf auch zuerst sprechen (senden).
- Das Gerät der Gegenstelle erkennt die Start-Synchronisation und geht von Bereitschaft in den aktiven Empfangsmodus (Entschlüsseln).
- Nachdem der sendende Teilnehmer seinen Durchgang beendet hat, gehen beide Geräte automatisch wieder in den Bereitschaftsmodus.
- Der bisherige Empfänger kann jetzt antworten, indem er selber auf die Sendetaste drückt.
- Nach Vereinbarung können auch beide Teilnehmer wieder in den normalen, unverschlüsselten Telefonmodus zurückschalten:
Bereitschaftsmodus, " * " drücken.
- Mit der Taste " * " lässt sich das Gerät aus jedem Modus heraus neustarten (Vorsicht, Rückkehr in den Transparentmodus!).
- Mit der Taste " # " lässt sich das Gerät aus dem Empfangsmodus bei gestörter Durchgang-Ende-Kennung in den Bereitschaftsmodus bringen.
Betriebsarten HEKTOR-Firmware 1.0b
STATUS
|
Optionen
|
LED1
Trans
(rot)
|
LED2
Sync
(gelb)
|
LED3
Rx
(grün)
|
LED4
Tx
(grün)
|
Kopfhörer
|
| Testmodus |
Einschalten, # drücken |
leuchtet
|
aus
|
leuchtet
|
aus
|
Dauerton |
Transparent
|
Neustart mit *
|
leuchtet
|
aus
|
leuchtet
|
aus
|
Startquittung dreimal Kurz
|
Schlüssel- eingabe
|
Neubeginn mit *, Eingabe max. 16 Ziffern, Bestätigen mit #
|
leuchtet
|
aus
|
leuchtet
|
aus
|
Bestätigungstöne für jeden Tastendruck
|
Bereitschaft
|
Sprechen mit 0
Neustart mit *, |
aus
|
leuchtet
|
leuchtet
|
aus
|
kein Ton
|
Hören
|
Zurück in Bereitschaft mit #
Neustart mit * |
aus
|
blinkt
|
leuchtet
|
aus
|
Gegenstelle
|
Sprechen
|
Taste "0" gedrückt halten Neustart mit *
|
aus
|
blinkt
|
aus
|
leuchtet
|
kein Ton
|
Synchronisation
Die hier praktizierte Methode der Blocksynchronisation hat sich wohl
gerade wegen ihrer Primitivität als ausgesprochen störungsresistent und
zuverlässig erwiesen. Auf einigermaßen brauchbaren Verbindungen kann es
mit dem hier implementierten Protokoll
im Prinzip garnicht mehr dazu
kommen, dass die Transpositionstabellen "auseinander laufen".
Das System synchronisiert sich mit jedem Block neu. Sollte die
Blocksynchronisation zeitweise fehlen, dann läuft das System noch über
mehrere Blöcke mit der Ganggenauigkeit der lokalen Taktoszillatoren weiter.
Sobald wieder Synchronisationssignale ankommen, wird die volle Genauigkeit
des Zeitrasters normalerweise wieder hergestellt, und die folgenden Blöcke
lassen sich dann auch wieder problemlos entschlüsseln.
Bei schweren Übertragungsstörungen kann sich das System in der Pause
zwischen zwei Durchgängen (Bereitschaftsmodus) wieder auf ein- und
dieselbe Tabelle einstellen, sodass die Übertragung ebenfalls ohne
Neustart fortgesetzt werden kann. (Wie der Trick funktioniert, steht in den
Überlegungen zur Sicherheit - Tabellensynchronisation.)
Die Synchronisation und das Schlüsselschema ließen es durchaus zu, dass
mehr als zwei Teilnehmer verschlüsselt kommunizieren. Diese Variante
wurde aber noch nicht ausführlicher getestet. Bei einer Dreierkonferenz
oder QSO-Runde sollte man sich wohl besser auf eine feste Sprechreihenfolge
einigen, um keine Kollisionen heraufzubeschwören.
Schlüsselvereinbarungen
Da es sich hier um ein klassisches symmetrisches Kryptosystem handelt,
bleibt das alte Problem der Schlüsselvereinbarung, für die im
Vorfeld natürlich ein sicherer Kommunikationsweg benötigt wird.
In Zeiten von E-Mail und PGP sollte dies nun aber wirklich kein Problem
sein. Zur sicheren Übermittlung von ein paar Zahlen tut's vielleicht auch schon ein gutes (!)
Steganografie-Tool.
Oder die wohl bequemste Variante: einfach im Laufe einer verschlüsselten Kommunikation weitere Schlüssel oder Regeln vereinbaren!
Schlüsselmanagement
Sicher ist es nicht jedermanns Sache, gleich mehrere 16-stellige
Schlüssel im Kopf zu behalten. So reicht in Friedenszeiten
vielleicht schon eine Zusammensetzung aus "nur" 8-stelliger
Geheimzahl plus Datum, um auf bequeme Weise für jede Sitzung einen
neuen Tagesschlüssel zu bekommen. Also ganz primitiv zum Beispiel:
Geheimzahl: 12345678
Datum: 20080601
Eingabe: *1234567820080601#
Hardwaresicherheit
Wenn eine Krypto-Hardware schon mit memorierbaren Schlüsseln arbeitet,
dann sollte sie konsequenterweise auch vollkommen "gedächtnislos"
angelegt sein. Eine Speicherung von Schlüsselkomponenten im EEPROM des
Controllers oder gar auf externen Chipkarten erscheint daher auch nicht
empfehlenswert.
Diese gedächtnislose Hardware kann von jedermann gefahrlos
benutzt werden, ohne dass es nach dem Abschalten der Betriebsspannung
noch Datenspuren im Gerät gäbe. Sobald die Betriebsspannung
unterbrochen wurde, sind gewissermaßen automatisch "die Walzen in
Ausgangsstellung gebracht",
sodass bei Verlust oder Diebstahl der Maschine kein Aufdeckungsrisiko
für das Schlüsselschema besteht. (Das ist übrigens auch der Grund,
weshalb ich auf der Hauptplatine für die Betriebsspannung keine
größeren Stützkondensatoren vorgesehen habe!)
Nach oben
Überlegungen zur Sicherheit
An dieser Stelle werde ich alle wichtigen Parameter der hier
vorgeschlagenen Lösung genauer erläutern. Aussagen zur praktischen
Sicherheit mache ich nur dort, wo es genügend Vergleichsmöglichkeiten
gibt.
Parameter der Zeittransposition
Teilung in 128 Positionen
Die Teilung eines jeden Blockes in 128 Positionen bedeutet zunächst
einmal, dass es rein rechnerisch n=128! Möglichkeiten der Vertauschung
gibt. Das ergibt sagenhafte 3,86 * 10
215
Transpositionstabellen - eine verdächtig große Zahl, die wir auch
gleich wieder vergessen können, denn sie ist ausschließlich von
theoretischem oder schlechterdings von kommerziellem Interesse.
Für Transpositionschiffren im Allgemeinen und für die
Audio-Zeittransposition im Besonderen gilt, dass man natürlich
nur solche Transpositionstabellen verwenden sollte, die eine möglichst gute
Durchmischung der Symbole gewährleisten. Es darf vor allem nicht vorkommen, dass zu viele Symbole allzu
regelmäßig in ihrer ursprünglichen Reihenfolge auftreten. Dann wäre es nämlich für einen
geübten menschlichen Hörer möglich, aus dem Signalgemisch doch einen Inhalt herauszuhören (und
dies ist dann eventuell auch mit einem hochentwickelten maschinellen Verfahren möglich). Andererseits kommt für
den Abhörgegner erschwerend hinzu, dass das "Störsignal" (also Sprachfetzen, die an der
falschen Stelle stehen), sich qualitativ überhaupt nicht vom "Nutzsignal" (also Sprachfetzen, welche
zufällig an der richtigen Stelle stehen) unterscheidet. Bei langen Transpositionsblöcken erhöht sich
zudem die Wahrscheinlichkeit, dass man aus dem zeittransponierten Signal
irgendwas heraushören kann (Mehrdeutigkeit).
Der hier vorgeschlagene Algorithmus für den Tabellengenerator soll mit seinen 10
16 Startbedingungen einen
soliden Kernbereich von wirklich guten Transpositionsschlüsseln abdecken.
Blocklänge von 1,3 Sekunden
In einer Sekunde lassen sich bereits ganze Sätze unterbringen
(nicht nur in Norddeutschland).
Der einzelne Block enthält daher mit hoher Wahrscheinlichkeit eine
Auswahl der gebräuchlichsten Phoneme. Bei flotter Sprechgeschwindigkeit
können bis zu 50 Phoneme in einem Block
zusammenkommen.
Sollte es dem Angreifer mithilfe eines genialen maschinengestützten
Verfahrens gelingen, alle vorkommenden Phoneme bzw. ihre Bruchstücke
eindeutig zu identifizieren, zusammenzufassen und zu katalogisieren,
dann hätte er nicht mehr und nicht weniger als eine Liste von
"Buchstaben". Diese müsste er nun in einem zweiten Schritt mithilfe
statistischer Methoden (z.B. Häufigkeitsanalyse, Wörterbuchverfahren)
oder möglicherweise auch unter Zuhilfenahme von weiteren Korrelationen,
die sich vielleicht (nach meiner Einschätzung aber eher nicht!)
aus dem Signal ableiten lassen, zur wahrscheinlichsten Aussage rekombinieren.
Wegen der großen Blocklänge stehen aber recht viele Buchstaben im Angebot, sodass
es in der Regel mehrere Lösungen von höherer statistischer Evidenz gibt.
Das Anagramm würde in solchen Fällen unlösbar, und diese
Mehrdeutigkeit ließe sich
auch mit beliebig gesteigerter Rechenleistung nicht mehr auflösen.
Symbollänge von durchschnittlich 10 Millisekunden
Ein ernsthafter Angriff auf die Zeittransposition, der nicht auf
Brute-Force beruht, wäre durch eine Analyse des Signals hinsichlich
seiner phonetisch bedeutsamen Komponenten denkbar. Die Anforderungen
dürften noch einmal beträchtlich höher sein, als für eine gewöhnliche
"Spracherkennung". Diese kann sich normalerweise auf die
zeitliche Korrelation zwischen aufeinander folgenden Samples stützen.
Durch die Zeittransposition wird aber genau dieser Zusammenhang aufgelöst.
Der Gegner bräuchte also ein Spracherkennungssystem, das die phonetischen
Komponenten punktuell und treffsicher erkennen kann. Das sind
Forderungen, die sich teilweise widersprechen.
Die bekannten Verfahren zur Phonemanalyse beruhen auf der Auswertung der
sogenannten Formanten (das sind die charakteristischen
Frequenzspektren der Vokale und Konsonanten) sowie der Hüllkurven
(Amplitudenverläufe im Audiosignal).
Zur Erkennung eines Phonems wird in der Regel ein Messintervall von
mindestens 20 ms benötigt; die meisten konventionellen
Spracherkennungsysteme arbeiten daher mit genau diesem Zeitraster. In einem
gröberen Zeitraster würden die Übergänge zwischen den Phonemen
möglicherweise "verschluckt", in einem engeren Zeitraster
funktioniert die Formantanalyse nicht mehr ausreichend treffsicher
(Frequenzbestimmung wird zu ungenau).
Was liegt also näher, als unser System mit einer Symbolrate zu
betreiben, die deutlich unter diesen 20 Millisekunden liegt!
HEKTOR arbeitet mit Symbolen von durchschnittlich nur noch 10 ms
Spieldauer, deren Länge dynamisch variiert wird. Damit sollte das
Signal keiner konventionellen Phonemanalyse mehr zugänglich sein.
(Anmerkung: Sicher kann man das eine oder andere charakteristische
Merkmal der Sprecherstimmen als Durchschnittswerte über mehrere Symbole
ermitteln - damit lassen sich aber in der Regel keine konkreten
sprachlichen Aussagen extrahieren.)
Schlüsselraum
Als Schlüssel können bis zu 16-stellige Dezimalzahlen über den
Zehnerblock am Gerät eingegeben werden. Der Schlüsselraum umfasst also einen
Wertebereich von 10
16 verschiedenen Startbedingungen.
Ins Binärsystem umgerechnet entspricht dies einer Schlüssellänge von
ungefähr 53 Bit.
Ziel eines guten Permutations-/Transpositionsalgorithmus ist es zunächst einmal,
dass jede erzeugte Transpositionstabelle eine möglichst gute (d.h. statistisch gleichmäßige) Durchmischung
der Symbole garantiert. Der Schlüsselraum muss "echt" sein, das heißt, zwei Schlüssel,
die sich in nur einer Ziffer unterscheiden, oder auch zwei beliebig herausgegriffene Schlüssel
aus der Menge aller möglichen Schlüssel, sollen garantiert unterschiedliche Sequenzen
von Transpositionstabellen hervorbringen. Die Sequenzen dürfen sich auch nach einer realistischen
Laufzeit (Rechenvorgänge zur Generierung neuer Transpositionstabellen) nicht überlappen.
Zu den Erfolgsaussichten für einen "Brute-Force"-Angriff: Wenn die oben genannten Bedingungen erfüllt sind, und es
spricht einiges dafür, dann gibt es für das Durchprobieren aller Schlüssel keine effektiven "Abkürzungen",
die den zu untersuchenden Schlüsselraum drastisch einschränken würden. Für Brute-Force müsste der Angreifer also
davon ausgehen, dass er durchschnittlich den halben Schlüsselraum durchsuchen muss. Das wären bei diesem
System etwa 5 Billiarden Schlüssel. Die Nachbildung des HEKTOR-Schlüsselschemas ist trivial, sie
erfordert auch nur relativ wenig Rechenaufwand. Zusätzlich bräuchte der Angreifer allerdings noch
ein (automatisierbares!) Verfahren, das einen phonetischen "Treffer" sicher und zuverlässig erkennen kann.
Diese Kleinigkeit ist eindeutig weniger trivial. Dieses fiktive Spracherkennungsverfahren müsste blitzschnell
entscheiden können, ob ein auf gut Glück entschlüsselter Block (und die folgenden Blöcke) auch
wirklich sinnvoll entschlüsselt wurde. "Blitzschnell" bedeutet, das System sollte schon pro Sekunde
mindestens 58 Mrd. Schlüssel testen können, wenn dieser Angriff innerhalb eines Tages erfolgreich
sein soll. Nun, diese Anforderungen erscheinen im Hinblick auf die Leistungsfähigkeit bekannter
Spracherkennungssysteme noch vollkommen unrealistisch.
Tabellengenerierung
Der 16-stellige Initialschlüssel wird im BCD-Format in ein
softwaremäßig implementiertes rückgekoppeltes Schieberegister (
Logical
Feedback Shift Register, LFSR) mit der Länge 63 Bit übernommen.
Das LFSR mit XOR-Rückführungen an den Positionen 63 und 62 liefert eine
pseudozufällige Bitsequenz, die sich erst nach n = 2
63-1
Taktschritten zum ersten Mal wiederholen würde.
Auf der Basis dieser Pseudozufallsbits wird die Transpositionstabelle mit jedem
Blockwechsel neu umgestellt, und zwar gründlich. Grundlage für
eine einzige neue Tabelle ist die Ziehung von 1664 Pseudozufallsbits
(mindestens erforderlich wären 886 Bits gewesen) aus dem LFSR.
Die großzügige Nutzung des LFSR hat zweierlei Gründe: Zum
Einen wird die relativ starke Autokorrelation der LFSR-Bits kompensiert; zum
Anderen soll sichergestellt werden, dass keine nennenswerte Korrelation
zwischen direkt aufeinander folgenden Tabellen verbleibt.
Da die Transpositionstabelle nicht mit jedem Block neu berechnet,
sondern sukzessive umgestellt wird, gibt es zusätzlich zur Entropie des
Pseudozufallsgenerators einen Aufbaueffekt. Das Schlüsselschema liefert
also nicht etwa "nur" 10
16 unterschiedliche Tabellen insgesamt,
sondern selbstverständlich kann es 10
16 unterschiedliche
Tabellen
sequenzen liefern.
Obgleich mathematisch noch nicht abschließend geklärt, ist doch davon
auszugehen, dass sich Tabellensequenzen, welche durch zwei unterschiedliche
Startzahlen erzeugt würden,
niemals überlappen werden, und dass
alle Schlüssel zu einer Sequenz von brauchbaren Transpositionstabellen (gute Durchmischung des
Signals) führen werden.
Direkt aufeinander folgende Transpositionstabellen dürften daher statistisch
fast ebenso unabhängig voneinander sein, wie zwei Tabellen, die weiter
auseinander liegen. Selbst wenn der Angreifer es fertigbringt, eine
oder mehrere Transpositionstabellen vollständig und fehlerfrei zu
extrahieren, so kann er dadurch noch immer keinen Rückschluss auf weitere
Transpositionstabellen oder auf den verwendeten Initialschlüssel ziehen.
Frequenzvariation
Die reine Zeittransposition lässt auch bei sehr feinem Zeitraster noch
einige charakteristische Frequenzkomponenten der Sprecherstimmen
durchkommen. Diese könnten beispielsweise zur Identifikation der
Sprecher genutzt werden. Möglicherweise lassen sich auch noch weitere
Korrelationen zwischen den Symbolen finden, die auf Schmutzeffekte bei
der A/D-Wandlung oder auf die Symbolfrequenzen zurückzuführen wären
(Mischprodukte aus Symbol- und Stimmfrequenz).
Da liegt es nahe, auch die Frequenzkomponente nach einem
pseudozufallsschema zu beeinflussen. Im Rahmen der vorliegenden
Hardware lässt sich dies realisieren, indem wir die Abtastraten für
A/D- und D/A-Wandlung nach einem Pseudozufallsschema dynamisch
modulieren, sodass sich die Aufnahmegeschwindigkeit gegenüber der
Wiedergabegeschwindigkeit verändert.
Hierzu ein wichtiger Hinweis: Im Gegensatz zur Frequenz
inversion
(Mischung mit anderen Frequenzen und Herausfiltern der unerwünschten
Seitenbänder) erhält man durch die Modifikation der Samplingfrequenzen kein Signal,
das vom akustischen Eindruck her vollkommen unverständlich wird. Die
Operation ist eher mit einem schneller oder langsamer laufenden Tonband
zu vergleichen, also allein für sich angewandt ein eher schwaches
Verschleierungsverfahren. Allerdings entstehen auch
keine neuen
Mischprodukte bzw. Spiegelfrequenzen, die man vor der Übertragung aufwendig
herausfiltern müsste.
In der vorliegenden Implementierung wird die Symboldauer und die
Tonhöhe der stimmhaften Laute um bis zu +/-50% variiert, was in etwa
dem Frequenzumfang einer Oktave entspricht. Eine größere
Schwankungsbreite erschien nach einigen Experimenten auch nicht
sinnvoll, da das Signal ansonsten aus der zur Verfügung stehenden
Übertragungsbandbreite herausfallen könnte.
Als Ergänzung zur Zeittransposition verspricht die Frequenzvariation
einen Sicherheitsgewinn, da die Symbole von ehemals zusammengehörigen
Lauten jetzt nicht nur an unterschiedlichen Positionen auftreten, sondern auch
mit unterschiedlichen Frequenzen. Mögliche Korrelationen zwischen den
Sprachfetzen, die die Zeittransposition noch übriggelassen hat, sollten
nach Anwendung der Frequenzvariation beseitigt oder stark vermindert
worden sein. Effektiv wird durch diese Operation auch das Audiospektrum
verbreitert, was allgemein eine bessere Robustheit des Signals
gegenüber möglichen Störungen verspricht.
Das Pseudozufallsschema zur Frequenzvariation liegt in der
gegenwärtigen Umsetzung ebenfalls als Tabelle aus 128 gleichverteilten
Zufallswerten vor. Diese wird, vom Transpositionsschema unabhängig, mit
jedem Durchgang gewechselt.
Synchronisation
Dogma:
Zu keinem Zeitpunkt sollen irgendwelche
Schlüssel-Informationen übertragen werden!
Wenn schon ein symmetrisches Schlüsselschema mit memorierbaren
Schlüsseln verwendet wird, dann wäre jede Übertragung von
Meta-Informationen zum Schlüssel eine Verschlechterung der Sicherheit.
Das System überträgt lediglich drei einfache Synchronisationssignale: ein
Startsignal für den Beginn des Durchganges, ein wiederkehrendes Signal zur
Blocksynchronisation, ein Stoppsignal für das Ende des jeweiligen
Durchganges.
Die Signale identifizieren sich über ihre Frequenz und ihre
Dauer. Sie enthalten nicht mehr Information, als unbedingt
notwendig.
Der Frequenzbereich der Synchro-Signale wurde nach folgenden
technischen Überlegungen gewählt:
Insbesondere die Frequenz der Blocksynchronisation sollte hoch
genug sein, um durch eine möglichst kurze Periodendauer eine präzise
Synchronisation zu ermöglichen. Andererseits durfte diese Frequenz
nicht über 2400 Hz liegen, damit sie bei Telefoniesystemen noch ganz im
Übertragungsbereich mit geringster Dämpfung liegt.
Mit Frequenzen zwischen 1200-1800 Hz fährt man hier erfahrungsgemäß am besten.
Die genauen Frequenzen für Blockstart/Synchro/Ende ergeben sich aus der Programmierung
(Taktfrequenzen, sichere Unterscheidbarkeit der Töne).
Tabellensynchronisation
Dogma:
Zu keinem Zeitpunkt sollen irgendwelche
Schlüssel-Informationen übertragen werden!
Natürlich auch dann nicht, wenn der Gleichlauf der Transpositionstabellen
durch eine Störung durcheinander gekommen ist.
Dieser Fall könnte eintreten, wenn ein dauerhafter Zeitversatz
von mehr als 20 ms (halbe Dauer des Blocksynchro-Signals) auf
dem Übertragungsmedium auftreten sollte, wenn eine sehr starke
Störung ungünstig auf den Zeitpunkt der Blocksynchronisation fällt,
oder wenn die Übertragung für mehr als etwa 3 Blöcke komplett
ausfallen sollte. Dann reicht die Ganggenauigkeit der lokalen
Taktoszillatoren nicht mehr aus, um den Gleichlauf aufrecht
zu erhalten und das System kann sich nicht mehr mit der
nächsten Blocksynchronisation "fangen".
Ein Rückfall in die unverschlüsselte Übertragung und anschließende
Wiederaufnahme des verschlüsselten Betriebs wären umständlich und mit
Sicherheitsrisiken verbunden, besonders dann, wenn man gezwungen wäre,
nochmal mit demselben Tagesschlüssel neu zu starten. Besser wäre es,
wenn das System in so einem Fall automatisch einen neuen Sitzungsschlüssel
bereitstellen würde. Dieser Vorgang sollte aus Sicherheitsgründen
selbstverständlich ohne die Übertragung weiterer Informationen
abgewickelt werden. (Schon die Übertragung von Laufnummern zu den
Schlüsseln, oder allein die Information, dass die Übertragung effektiv
gestört werden konnte, sind für einen Abhörgegner bereits interessant.)
Die Idee einer "stillen Tabellensynchronisation" wurde schließlich
folgendermaßen umgesetzt:
Der sendende Teilnehmer merkt erstmal nichts von einer Störung und wird
seinen Durchgang ganz normal fortsetzen, irgendwann die Sendetaste
loslassen und sich wieder im Bereitschaftsmodus befinden, weil er auf eine
Antwort wartet. Der Empfänger bemerkt die Störung und wartet
seinerseits in aller Ruhe das Ende des Durchganges ab. Die Umschaltung
vom Empfangsmodus in den Bereitschaftsmodus funktioniert normalerweise
auch dann noch automatisch, wenn ein größerer Zeitversatz von mehr als
einer Blocklänge zwischen Sender und Empfänger entstanden sein sollte.
Sollte der Empfänger nicht automatisch in den Bereitschaftsmodus
kommen, dann kann der Benutzer den Durchgang auch manuell durch Drücken
der Taste "#" beenden, sobald er aus dem Signalgemisch das Tonsignal
für "Durchgang-Ende" heraushört.
Egal, ob ein Durchgang gestört wurde oder nicht, beide Teilnehmer
befinden sich normalerweise nach einer gewissen Zeit und vor allem zur gleichen
Zeit wieder im Bereitschaftsmodus. Nach jedem Übergang vom Sende- oder Empfangsmodus in den
Bereitschaftsmodus überspringt das Programm immer eine gewisse
Anzahl von Tabellen. Dabei wird nicht etwa eine fixe Anzahl von
Tabellentranspositionen durchgeführt, sondern immer bis zur nächsten
vollen 128er-Einheit ("Meilenstein") gezählt. (Nebenbei nutzt das System
die Bereitschafts-Pause, um eine neue Tabelle für die Frequenzvariation
zu generieren.)
Mit diesem Verfahren wird also (fast) jeder eventuell vorhandene
Unterschied in den Tabellenzählern mit dem Erreichen des
Bereitschafts-Modus automatisch wieder ausgeglichen. (Ausnahme: Einer
der Teilnehmer ist gerade bei Tabelle Nr. 127 angelangt und muss in
der Bereitschafts-Pause nur noch eine Tabelle weiterspringen, während
der andere Teilnehmer schon die 128 erreicht hatte und nun
ganze 128 Tabellen weiterspringt. Die Wahrscheinlichkeit hierfür
liegt bei unter einem Prozent.)
Und das Wichtigste: Dieser automatische Neuabgleich der Tabellen
funktioniert, ohne dass über den unsicheren Kanal irgendwelche
zusätzlichen Informationen ausgetauscht werden mussten!
Vorteile der analogen Übertragung
Das analog verschlüsselte Audiosignal kommt bis auf die Synchronimpulse
ohne digitale Signalkomponenten aus. Die einzigen digitalen Komponenten (im Sinne
einer eindeutigen Auswertbarkeit) sind die drei Synchronisationssignale, welche
auch nur drei verschiedene Informationen beinhalten: "Durchgangs-Beginn", "Block-Ende",
"Durchgangs-Ende".
Möchte der Angreifer mehr Informationen haben, dann muss er sich schon
mit dem nicht codierten, analogen Teil des Signals beschäftigen. Schon das
Aufzeichnen einer nicht digital codierten Übertragung ist bereits mit dem ersten
Informationsverlust (Quantisierungsfehler) behaftet, und vor allem ist
es beim Analogsignal auch nicht immer möglich, Kanalstörungen vom
Nutzsignal zu unterscheiden. Dies erschwert die Signalanalyse zusätzlich, da hier
weitere Unsicherheiten ins Spiel kommen.
Der berechtigte Empfänger hat es da wesentlich leichter. Sobald er
eines der Synchronisationssignale sauber erkannt hat und den
richtigen Schlüssel verwendet, ist er in der Lage, das korrekte
Modell für die Transpositionen und Frequenzvariationen direkt auf
das Signal anzuwenden. Das funktioniert selbst dann noch,
wenn die Übertragung zeitweise stark gestört wird oder sogar für einige Sekunden
komplett ausfällt. Im Gegensatz zu volldigitalen Verfahren
kommt es dann nicht zu vollständigen Aussetzern und es müssen auch
keine Daten zur Neusynchronisation übertragen werden, die
möglicherweise kompromittierend wären.
Etwaige Störungen in der Analogübertragung treten als akustische
Störgeräusche in Erscheinung, aber die werden von unserem psychoakustischen
Biocomputer ganz hervorragend herausgefiltert. Gegenüber volldigitalen
Alles-oder-Nichts-Codierungen hat die Zeittransposition doch so
einige Vorteile bezüglich der "Useability".
Weitere Sicherheitsaspekte ergeben sich aus der Verwendung
von Deltamodulation als internem Codec:
- Durch die integrierenden Eigenschaften der Deltamodulation
werden harte Pegelsprünge an den "Schnittkanten" der Symbole
regelrecht abgerundet - das bedeutet, das Signal verliert gerade jenen
Teil seiner Hüllkurveninformation, der für einen Angreifer besonders
interessant gewesen wäre. Um auf den Puzzle-Vergleich zurückzukommen:
Wir schneiden von jedem Puzzleteil einen Teil der Zacken ab!
- Zur D/A-Rückwandlung eines Delta-Bitstroms reicht ein
simpler Tiefpass. Damit lassen sich höherfrequente Mischprodukte aus
Symboltakt und Nutzsignal, die eventuell kompromittierende
Informationen beinhalten könnten, bereits sehr gut unterdrücken.
- Im Zusammenspiel mit modernen Telefonsystemen dürfte es von
Vorteil sein, dass die Deltamodulation mit einem hohen
Oversampling-Faktor arbeitet. Die Delta-Abtastfrequenz liegt dann weit
von der normalerweise üblichen PCM-Abtastrate von 8 kHz entfernt.
Aliasing-Effekte sind hier nicht zu befürchten.
Mögliche Schwachstellen des Verfahrens
Die Schutzwirkung der Zeittransposition lässt bei besonders langsamer
Sprechgeschwindigkeit nach. Bei langsamem Sprechen kommen nur wenige
unterschiedliche Phoneme in einem Block zusammen, und damit lässt sich der erwähnte
Effekt der Mehrdeutigkeit nicht ausnutzen. Auch wäre es denkbar, dass man mit den bereits
angesprochenen phonetischen Analyse- und Angriffsstrategien bei einem Block, der nur wenige
Silben enthält, durchaus eine Chance hätte. Andererseits enthält ein einzelner langsam
besprochener Block nur wenig Informationen, die kompromittiert werden könnten. Durch den
hier angewandten Algorithmus zur Generierung der Transpositionstabellen ist außerdem sichergestellt,
dass das Auflösen eines einzelnen Blockes überhaupt keinen Rückschluss auf die vorherige/nächste
Transpositionstabelle oder auf den Initialschlüssel zulässt.
Die angewandte Methode zur Frequenzvariation lässt sich möglicherweise
noch verfeinern. Das ursprüngliche Ziel einer Verbreiterung des
Signalspektrums wird bereits mit der vorliegenden Variante erreicht,
das kann man hören und anhand von
Spektrogrammen
objektiv nachweisen. Allerdings sind in der vorliegenden
Implementierung die Samplingfrequenzen für Aufnahme und Wiedergabe über
ein- und denselben Interrupt aneinander gekoppelt. Aus diesem Grund
kann man in der derzeitigen programmiertechnischen Umsetzung für einen
Durchgang auch immer nur ein- und dieselbe Frequenztabelle benutzen,
weil ansonsten das Last/First-Prinzip bezüglich der Abspielfrequenzen
nicht eingehalten werden kann. Ich gehe davon aus, dass die Frequenzvariation
in jedem Fall ein Sicherheitsgewinn ist, und dass sich keine neuen
Korrelationen und Angriffspunkte durch sie ergeben.
Mögliche Schwachstellen der Hardware
Nach einigen (qualitativen) Tests mit einem empfindlichen Messempfänger sind die elektromagnetischen
Abstrahlungen dieses mit 10 MHz getakteten Mikrocontrollersystems vergleichsweise schwach.
Eine Detektion oder gar Auswertung der Tastendrücke wäre, meiner Einschätzung nach, höchstens mit
professionellem Equipment aus vielleicht zehn oder zwanzig Metern Entfernung noch vorstellbar. Es kann also
nicht schaden, ein Metallgehäuse oder eine metallische Bodenplatte vorzusehen und die Zuleitungen zur
Matrixtastatur so kurz wie möglich zu halten. Beides reduziert die EM-Abstrahlungen drastisch. Zuleitungen
sollten zusätzlich verdrosselt werden.
Die jetzige Platinenversion enthält auch wieder einen 10-poligen ISP-Stecker,
sodass das AVR-Programm direkt auf der Platine geflasht werden kann. Das ist
erstmal sehr praktisch, andererseits bedeutet es natürlich ein gewisses
Sicherheitsrisiko, weil jemand, der Zugriff zum Gerät erlangt, das Programm
ebenfalls recht schnell gegen eine "Spezialversion" austauschen könnte.
Andererseits - wenn einfach jemand in die Wohnung spazieren kann, um dort
technische Manipulationen vorzunehmen, dann ist bereits die nächste Eskalationsstufe
erreicht, und man sollte sich ernsthafte Gedanken über ein ganzheitlicheres Schutzkonzept für
die privaten Räumlichkeiten machen...
Nach oben
Firmware
Das Programm
Das Programm wurde unter der komfortablen Editoroberfläche von
BASCOM-AVR erstellt und compiliert. Es besteht zum größten Teil
aus Assemblerroutinen, die von einem Gerüst aus unkritischen
Basic-Strukturen gewissermaßen verwaltet werden. Auf diese Weise konnten
die Interruptroutine und die Schlüsselberechnung effizient und dennoch
weitgehend transparent realisiert werden. Dem hohen Anteil an echter
Maschinensprache-Programmierung ist es denn auch zu verdanken, dass sich
das ganze Programm noch mit der Demoversion von Bascom-AVR compilieren
ließ. Das Programm kann hier natürlich nicht im Detail besprochen werden.
Die Struktur sollte aber auch für den Assembler-Hasser gut nachvollziehbar
sein, denn der Quellcode ist reichlich kommentiert.
Download
Die Verschlüsslersoftware ist für alle bisher entwickelten
Hardware-Varianten vollkommen identisch. Für die hier beschriebene
Kompaktversion kommt also dasselbe Programm zum Einsatz, wie es für die
zweiteilige Variante auch verwendet wird. Die stabile Version
steht im Download-Bereich von [10] zur Verfügung. Sollte ich
Experimentierversionen mit besonderen Features herausbringen, dann
wären diese zunächst auf meinen eigenen Seiten zu finden.
Flashen
Die Binär- oder Hex-Files können zum Beispiel mit AVR-OSP, AVRprog oder
TwinAVR übernommen und in den Chip geschrieben werden. Im
Auslieferungszustand sind die AVR-Fusebits üblicherweise so gesetzt,
dass der interne RC-Oszillator zur Takterzeugung verwendet wird, der
Chip also in jedem Fall programmiert werden könnte. Ich empfehle
jedoch, zunächst die Fusebits für den Betrieb mit einem externen
Quarz entsprechend zu setzen (dann hat man die "gefährlichste"
Sache gleich am Anfang erledigt), und dann den Programmcode zu flashen.
Unter AVR-Prog, das zusammen mit der Open-Source-Weiterentwicklung
des "AVR910"-Programmers (Version 3.8) ganz hervorragende Dienste
leistet, wären die Optionen für die Fusebits dann: "externer Quarz,
mittlere/hohe Frequenz".
Fusebit-Fallstricke
Nebenstehendes Bild zeigt die Fusebits in der
Darstellung von
Twin-AVR, wie sie
gesetzt sein müssen, damit der AVR den externen 10-MHz-Quarz zur
Takterzeugung benutzt.
Im Gegensatz zum Auslieferungszustand ist also das Fusebit
CLKSEL0 jetzt ebenfalls
gesetzt, was unter TwinAVR aber
bedeutet,
Häkchen weg. CLKSEL2 und CLKSEL3 müssen zusätzlich gelöscht
werden, damit der externe Quarz benutzt wird - hier also
Häkchen hin.
- Siehe Screenshot!
Ich hoffe, dass damit nun alle Klarheiten beseitigt sind und wirklich niemand
mehr auf die lustige Idee kommt, erstmal nur CLKSEL0 zu setzen, ohne
gleichzeitig
CLKSEL2 und CLKSEL3 zu ändern - nur um bestätigt zu sehen, dass der AVR dann ganz ohne
Taktgenerator dasteht und sich plötzlich auch nicht mehr per ISP/SPI ansprechen lässt...
(
Endlich ein Grund zur Panik? Nicht ganz: Der Chip ist nicht kaputt, er
lässt sich nur nicht mehr im seriellen Programmiermodus ansprechen.
Einfach externen Oszillator von z.B. 1 MHz an den Pin XTAL1 anschließen,
schon sind Flash und Fusebits wieder erreichbar.)
Nach oben