Diskussionsvorschlag für eine i-telex Authentifizierung

[detlef]

Ich habe mir mal Gedanken gemacht, wie man eine sichere Authentifizierung beim jedem i-Telex-Anruf realisieren könnte.
Nachdem ich einige selbstausgedachte Verfahren durchgespielt habe, bin ich eigentlich immer wieder beim Private/Public-Key-Verfahren gelandet.
Damit die i-Telex-Karte nicht mit RSA/DNS-Verschlüsselung belastet wird (das schafft die nicht), könnte man den Teilnehmer-Server für die Key-Berechnungen nutzen.

Praktisch könnte das folgendermaßen aussehen:

Wenn der Server die Verschlüsselung übernimmt, braucht man eigentlich nur einen Key, der auf dem Server gespeichert wird. Das ist dann ein Zwischending aus Public und Private Key.

Bei einem Anruf lässt sich der Anrufer vom Server ein mit seinem Key verschlüsseltes Anmeldetoken erzeugen, mit dem er sich beim angerufenen System authentifiziert. Das Token bleibt auf dem Server gespeichert.
Das angerufene System schickt den verschlüsselten Token zum Server, dieser entschlüsselt das Token mit dem Key des Teilnehmers, vergleicht ihn mit dem letzten gespeicherten Token und bestätigt die Echtheit.
Der Token sollte am besten zufällig erzeugt werden und muss bei jedem Anruf neu erzeugt werden, damit der Angerufene nicht einfach den Token speichern und weitergeben kann.
Bei der Authentifizierung sendet der Anrufer natürlich seine i-Telex-Nummer mit, damit der Server den Token zuordnen kann. Damit weiss auch der Angerufene immer, von wem er angerufen wird.

Man könnte das Verfahren noch etwas vereinfachen, in dem man statt zu Verschlüsseln einfach mit einem Hashwert arbeitet, der aus dem zufälligen Token und dem hinterlegen Key der Teilnehmers gebildet wird.

Natürlich muss dafür die Server- und die Teilnehmer-Software aktualisiert werden. Das Anfordern einer Authentifizierung vom Anrufer sollte als Option in der Teilnehmersoftware ein- und ausgeschaltet werden können.
Dann aktivieren das möglichst erst mal nur die Teilnehmer, die Bedenken wegen Spam haben und können dann aber keine Anrufe mehr von Teilnehmern mit alter Software empfangen.
Die Motivation, die eigene i-Telex-Software zu aktualsieren, steigt mit abnehmenden Anzahl an Systemen, die man noch anrufen kann.

Die Authentifizierung zwischen den Teilnehmenr könnte über zwei neue Paket-Typen erfolgen (Authentifizierung anfordern und Authentifizierung senden). Bei alter Software oder abgeschalteter Authentifizierungsoption kommt keine Authentifizerungsaufforderung. Was macht die alte Software, wenn sie einen unbekannten Pakettyp empfängt. Ich nehmen an, der wird ignoriert?

Das alternative Telnet/ASCII-Protokol bleibt davon unberührt. Das funktioniert nach wie vor ohne Authentifizierung.

Klar, das ist mit einigem Aufwand verbunden. Ich biete dabei meine maximale Unterstützung an (sowohl beim Coden als auch beim Testen).

Das ist jetzt einfach mal ein Diskussionsvorschlag. Gibt es offensichtliche Lücken? Habe ich was übersehen?

[FredSonnenrein]

Hallo Detlef,
danke für deine Nachrichten.
Die "Private/Public-Key-Verfahren" kenne ich gar nicht, daher kann ich das Konzept (noch) nicht nachvollziehen.

Folgende Bauchschmerzen habe ich:

A) Es gibt mehrere Teilnehmer-Server, die sich zwar untereinander synchronisieren, das passiert aber nur alle paar Sekunden.
Wenn nun der Anrufer einen anderen Server benutzt als der Angerufene, dann liegt ggf. kein aktuelles "Token" vor.

B) Es gibt viele Anwender, die ihre Software des i-Telex nicht aktualisieren, weil sie es nicht KÖNNEN (z.B. keinen Windows-PC
besetzen oder allgemein diesbezüglich unbegabt sind).

C) ASCII-Protokoll bleibt unverschlüsselt -> Dann hilft das gegen Spam nur sehr eingeschränkt.

Was spricht denn deiner Meinung nach gegen das Verfahren, dass einfach die IP-Adresse des Absenders auf "Authenzität" überprüft wird? Das sollte der Teilnehmer-Server können (ist bereits vorbereitet).

[detlef]

Hallo Fred,

Wie würde das genau ablaufen? Bei einem Anruf fragt der Angerufene beim Teilnehmerserver an, ob die IP-Nummer des Anrufers mit der IP-Nummer in Teilnehmerverzeichnis übereinstimmt.
Da der Angerufene den Anrufer nicht identifizieren kann, würde der Teilnehmerserver nur prüfen, ob die IP-Nummer überhaupt im Teilnehmerverzeichnis vorkommt und könnte dann aber auch gleich die Nummer des Teilnehmers zurückliefern. Ist das so gedacht?
Dann müssten in der Tat nur die updaten, die Bedenken wegen Spam haben. Hört sich gut an und ist viel einfacher als mein Vorschlag.

Dass es mehrere Teilnehmerserver gibt, war mir nicht klar.

Nur mal so als Idee: Wegen der Updatepoblematik könnte man einen Update-Arduino basteln, der auf Knopfdruck über die serielle Schnittstelle eine neue Firmware aufspielt.
Den könnte man auch leihweise verschicken (wobei das Zurückschicken bei den Hardwarekosten kaum lohnt). Es ist ja vielleicht auf Dauer nicht so sinnvoll, wenn einige Teilnehmer auf immer und ewig auf uralten Firmware-Versionen arbeiten.

Bei der Gelegenheit: Wilfried war überrascht, dass bei meinem i-Telex-Netzteil die Leds nicht durchlaufen. Gag es mal eine Firmware-Version, die das gemacht hat?

Gruß, Detlef

[ProgBernie]

Die "Private/Public-Key-Verfahren" kenne ich gar nicht, daher kann ich das Konzept (noch) nicht nachvollziehen.

Da hattest Du doch parallel bereits (berechtigte) Bedenken wegen der Rechenleistung der ATMega angemeldet. RSA dürfte zu hartes Brot für die 8bitter sein. Prinzipiell könnte man auch Zertifikate mit ECC (Elliptic Curve Cryptography) nehmen, ich glaube Sun Research Lab hatte das mal als Proof-of-concept für einen AVR implementiert, ist aber irgendwie nicht mehr so recht auffindbar.

[FredSonnenrein]

Hallo Detlef,

Wie würde das genau ablaufen? Bei einem Anruf fragt der Angerufene beim Teilnehmerserver an, ob die IP-Nummer des Anrufers mit der IP-Nummer in Teilnehmerverzeichnis übereinstimmt.
Da der Angerufene den Anrufer nicht identifizieren kann, würde der Teilnehmerserver nur prüfen, ob die IP-Nummer überhaupt im Teilnehmerverzeichnis vorkommt und könnte dann aber auch gleich die Nummer des Teilnehmers zurückliefern. Ist das so gedacht?
Dann müssten in der Tat nur die updaten, die Bedenken wegen Spam haben. Hört sich gut an und ist viel einfacher als mein Vorschlag.

Genau. Denkbar wäre zusätzlich, dass die Ziffernfolge der Kennung ODER eine versteckt von der Ethernet-Karte geschickte Hauptrufnummer auf "Passfähigkeit" zur IP-Adresse überprüft wird.
Natürlich ist die Kiste dann erstmal am laufen. Die Verbindung kann dann aber nach z.B. 20 Sekunden getrennt werden, falls die Authentifizierung fehlschlägt.
Gegen Mehrfach-Versuche hilft dann eine zeitlich beschränkte Blockierung von IP-Adressen.

Nur mal so als Idee: Wegen der Updatepoblematik könnte man einen Update-Arduino basteln, der auf Knopfdruck über die serielle Schnittstelle eine neue Firmware aufspielt.
Den könnte man auch leihweise verschicken (wobei das Zurückschicken bei den Hardwarekosten kaum lohnt). Es ist ja vielleicht auf Dauer nicht so sinnvoll, wenn einige Teilnehmer auf immer und ewig auf uralten Firmware-Versionen arbeiten.

Welcher Arduino hat denn mehr als 128 kByte ROM? Momentan sind 174kByte genutzt.

Bei der Gelegenheit: Wilfried war überrascht, dass bei meinem i-Telex-Netzteil die Leds nicht durchlaufen. Gag es mal eine Firmware-Version, die das gemacht hat?

Das ist ein "AddOn" der SV-Karte mit dem Prüfchip. Dann sind 9 LED auf der Karte.

[detlef]

Genau. Denkbar wäre zusätzlich, dass die Ziffernfolge der Kennung ODER eine versteckt von der Ethernet-Karte geschickte Hauptrufnummer auf "Passfähigkeit" zur IP-Adresse überprüft wird.
Natürlich ist die Kiste dann erstmal am laufen. Die Verbindung kann dann aber nach z.B. 20 Sekunden getrennt werden, falls die Authentifizierung fehlschlägt.
Gegen Mehrfach-Versuche hilft dann eine zeitlich beschränkte Blockierung von IP-Adressen.

Das habe ich jetzt nicht verstanden.

Welcher Arduino hat denn mehr als 128 kByte ROM? Momentan sind 174kByte genutzt.

Oha, 174KB? Dann müsste man noch eine SD-Karte spendieren.

Das ist ein "AddOn" der SV-Karte mit dem Prüfchip. Dann sind 9 LED auf der Karte.

Ich dachte, ich hätte schon die Luxus-Variante mit dem Prüf-Chip. Gibt es da noch eine Advanced-Version?

[FredSonnenrein]

Wie viele LED hast du auf dem Board?
Ist die IC Fassung bestückt?

[detlef]

Hallo Paul,

Was ist Centralex? Google liefert dazu keinen einzigen brauchbaren Treffer.

[Paul]

Was haltet ihr denn davon das über das Centralex laufen zu lassen?


Ich würde für eine Authentifizierung folgendes vorschlagen:

Das Centralex Protokoll wird um 3 Packete erweitert:

RemCall [ typ: 0x83 ] [ Länge = 44b ] [4 Byte Rufnummer Anrufer] [ 40 Byte Name Anrufer ] // -> rückwärts kompatible Neudefinition (sieht unten)
RemAuth [ typ: 0x86 (?) ] [ Länge = 6b ] [4 Byte Rufnummer] [2 Byte PIN]
RemPromptCall [ typ: 0x87 (?) ] [ Länge = 4b ] [4 Byte Rufnummer]


RemAuth unterscheidet sich von RemConnect dadurch, dass kein Port für den Client geöffnet wird
und der Teilnehmerservereintrag nicht modifiziert wird. Der Client muss ausserdem kein DynIp Client sein.
Das bedeutet aber, dass eine andere Authentifizierungsmöglichkeit benötigt wird, welche ich dann in den TLN Server einbauen müsste.

RemCall kündigt weiterhin einen eingehenden Anruf an, teilt nun aber auch die Identität des Anrufers mit.

RemPromptCall wird verwendet, um eine Anruf zu starten, ein Client sollte nur auf ein solches Packet reagieren, wenn es seine Nummer enthält


Bereits existierende Centralex Packete:
RemConnect:
0x81 0x06 [4 Byte Rufnummer] [2 Byte PIN]
... also Struktur wie das ClientUpdate zum Server
RemConfirm
0x82 0x00
... falls Server Daten anhängen will wäre das zulässig wird aber vom Client ignoriert
RemCall
0x83 0x00
... falls Server Daten anhängen will wäre das zulässig wird aber vom Client ignoriert
RemAck
0x84 0x00



Der Ablauf wäre dann Folgender:

Schritt	Anrufer	<->	Centralex Server	<->	Angerufener	Kommentar
0	RemAuth	-->				oder RemConnect -> centralex Client (wenn der Client schon angemeldet ist können [Schritte 0 und 1] übersprungen werden)
1		<--	RemConfirm
2	RemPromptCall	-->				enthält die Nummer des Angerufenen
3			RemPromptCall	-->		enthält ebenfalls die Nummer des Angerufenen; sollte von einem Normalen ITelex ignoriert werden -> nach timeout: [Schritt C] evtl. wird vorher noch benachrichtigt, dass ein alter ITelex Client erreicht wurde; ab hier ist die Identität des Anrufers noch nicht bekannt, da ein MITM sonst wüsste, wer wen anruft. so ist zuerst nur bekannt, dass ein neuer Anruf vorliegt
4				<--	RemAck
5				<--	End
6					<disconnect>
						Bestätigung der Identität des Centralex Servers durch reconnect
7					<connect>
8				<--	RemAuth
9			RemConfirm	-->
A			RemCall	-->		ab hier weiß der Angerufene, wer angerufen hat (-> kann auflegen)
B				<--	RemAck
C		<--	RemCall			ab hier weiß der Anrufer, dass der Anruf erfolgreich war und angenommen wurde
D	RemAck	-->
E		<->	Durchverbindung	<->
F		<->	Trennung	<->

Das sollte sollte für mich im Centralex Server implementierbar sein und es Fred erlauben einen Großteil der Centralex Client Logik wiederzuverwenden.

Das ist natürlich keine vollständige Definition, das Prinzip sollte aber denke ich mal klar werden.

Was haltet ihr davon?

[Paul]

Da wollte ich noch bei Gelegenheit mal einen Post zu machen, war ich aber noch nicht zu gekommen.
Das Centralex ist der Server, über den die neuen Standleitungen laufen.
Ich hatte ürsprünglich sowieso noch einige andere Features dafür geplant, aber im Moment öffnet es nur Ports für Clients mit Standleitung, ändert deren Teilnehmerservereintrag und leitet Verbindugen auf die Ports an den jeweiligen Client weiter.