Verschluesselung fuer Poin2Point Kommunikation mit wenig CPU last
-
Hallo Leute.
Wir haben folgendes System:
1 zentraler Datenbank Server
zu dem sich N clients connecten (wobei N vermutlich nie mehr als 20 sein wird und eher gegen 2-3 gehen wird)Jeder dieser Clients hat aber zu M embedded geraeten eine TCP/IP verbindung. Wobei M hier im Bereich 10-30 anzusiedeln ist.
Die Verbindung Client zu Server ist trivial, da die beiden Rechner kaum CPU last ziehen. Die Verbindung Client zu Embedded Geraete dagegen ist interessanter.
Die Daten muessen verschluesselt werden da wir ja ueber oeffentliche Netze fahren koennten. Nur was nimmt man da am besten? Die CPU power der embedded geraete ist ziemlich niedrig, genaue MHz zahlen stehen noch nicht fest, deshalb muessen wir mit sowenig last wie moeglich auf den geraeten auskommen.
generell haette ich ja etwas wie SSL/TLS genommen, nur habe ich da keine ahnung ob das nicht zuviel last zieht. Wir wollen keine verbindung halten sondern jedesmal wenn es etwas zu tun gibt eine neue verbindung aufbauen, anfrage senden, ack abwarten, verbindung schliessen. die meiste zeit werden beide seiten idle sein - nur gibt es dann eben spitzen wo sehr viel datenverkehr herrschen wird (auch wenn dies selten vorkommt).
Da wir das Rad nicht neu erfinden wollen: was gibt es da fuer fertige loesungen? sicherheit ist wichtig, aber wichtiger ist, dass es die cpu last moeglichst niedrig haelt. Ideal waeren Loesungen wo handshake, verschluesselung, etc. bereits spezifiziert ist - so dass wir keine eigenen systeme implementieren muessten.
-
Naja, was für Embedded-Geräte sind das? Die Frage wäre schon interessant. Wenn es sich um etwas Richtung Mobiltelefon oder PDA handelt, würde ich mir wenig Sorgen machen. Wenn es um einen 8Bit Controller geht schon mehr.
Aber im Grunde würde ich erst einmal TLS ausprobieren. Das Problem ist natürlich, dass man vielleicht "leichtere" Verschlüsselungsalgorithmen nehmen kann. Aber es geht ja nicht nur um die Verschlüsselung, sondern es geht ja auch um das verwendete Protokoll. Das alles auch noch richtig ohne größere Erfahrung in dem Bereich hinzukriegen, ist schon sehr schwer.
Es gibt ja auch kommerzielle Lösungen für TLS, die speziell für Embedded-Systeme sind http://sharkssl.com/ (Aber hier kommt wahrscheinlich das Problem hinzu, dass für Sicherheit kein extra Geld ausgegeben werden soll :().
-
rüdiger schrieb:
Naja, was für Embedded-Geräte sind das? Die Frage wäre schon interessant. Wenn es sich um etwas Richtung Mobiltelefon oder PDA handelt, würde ich mir wenig Sorgen machen. Wenn es um einen 8Bit Controller geht schon mehr.
Ja, sind wirklich sehr schwache geraete. Sind codiergeraete fuer magnetstreifen.
Vorallem: wir haben haben schon eine Menge Geraete im Einsatz und die kommunizieren ueber rs232 bzw. rs242. Wir werden wenn wir auf TCP/IP umstellen aber diese geraete nicht alle sofort tauschen, sondern wandler dazwischen schalten die die TCP/IP kommunikation auf die alte rs242 protokolle umlegen. diese geraete sollen so billig wie irgend moeglich sein. deshalb kenne ich die spezifikationen noch nicht.Aber im Grunde würde ich erst einmal TLS ausprobieren. Das Problem ist natürlich, dass man vielleicht "leichtere" Verschlüsselungsalgorithmen nehmen kann. Aber es geht ja nicht nur um die Verschlüsselung, sondern es geht ja auch um das verwendete Protokoll. Das alles auch noch richtig ohne größere Erfahrung in dem Bereich hinzukriegen, ist schon sehr schwer.
testen geht leider erst sehr spaet in der entwicklungsphase (zumindest an den orginal-geraeten). deshalb frage ich ja hier ob jemand bereits loesungen fuer das problem kennt.
wenn nicht dann abstrahieren wir die verschluesselung so gut wie moeglich und implementieren erst einmal SSL/TLS und hoffen dass es reicht. und bauen uU spaeter etwas effizienteres ein wenn noetig...
Es gibt ja auch kommerzielle Lösungen für TLS, die speziell für Embedded-Systeme sind http://sharkssl.com/ (Aber hier kommt wahrscheinlich das Problem hinzu, dass für Sicherheit kein extra Geld ausgegeben werden soll :().
exakt
die aktuelle kommunikation ueber rs242 laeuft unverschluesselt - was ok ist da sich niemand in die leitung haengen kann. nun soll es ueber tcp/ip laufen und nunja, man kennst es ja: wozu geld fuer sicherheit ausgeben - die war doch beim vorherigen modell auch schon by design drinnen. das suckt halt - aber da kann man nichts machen.wobei sharkssl schon ganz gut aussieht - werde mich dort mal nach preisen erkundigen.
-
Im Zweifelsfall geht vielleicht ein sehr sehr schwaches Modell. Kannst du davon ausgehen, dass die Geräte nicht in die Hand von Angreifern fallen? Wenn ja, dann würde ja eine einfache symmetrische Verschlüsselung reichen. Wenn nein, hast du ein Problem da der Angreifer ja nur das Gerät nehmen muss und den Schlüssel auslesen.
-
gute option - muss man mal durchdenken.
scheitert aber vermutlich an dem umstand den man hat fuer jeden kunden in die firmware ein anderes passwort zu schreiben. aber als option denkbar. uU kann man passwort beim initialisieren setzen.und bei diebstahl des geraets kann man passwoerter neu intialisieren, da dann sowieso ein techniker vor ort sein muss fuer die neuinstallation...
alles in allem, klingt wie ein guter plan b
-
RSA fuer die initializierung, ein paar randomizer die dir nen xor wert liefern fuer ne art one-time-pad. das ist sehr sehr flink und auch recht sicher.
-
rapso schrieb:
RSA fuer die initializierung, ein paar randomizer die dir nen xor wert liefern fuer ne art one-time-pad. das ist sehr sehr flink und auch recht sicher.
hätte ich auch gesagt.
-
rapso schrieb:
RSA fuer die initializierung, ein paar randomizer die dir nen xor wert liefern fuer ne art one-time-pad. das ist sehr sehr flink und auch recht sicher.
ne ne ne, OTP ist doch totaler Blödsinn. Das funktioniert nur, wenn du wirklich gute Zufallszahlengeneratoren hast und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne, warum müssen bei jeder Diskussion zu Verschlüsselung Leute kommen und OTP erwähnen. OTP ist Schwachsinn. Vergesst es einfach!
Wenn die Magnetkartenleser RSA aushalten, dann kann man auch einen vernünftigen Verschlüsselungsalgorithmus nehmen. Es gibt ja auch Algorithmen, die kleiner und schneller sind, als zB AES. Ich denke mal, dass es auch nicht so viel Aufwand wäre im Zweifelsfall TLS mit einem alternativen Verschlüsselungsverfahren zu benutzen.
Ganz zu schweigen davon, dass Shade dann ja noch ein ganzes Protokoll dazu entwerfen müsste. Nichts gegen Shade. Aber ohne große Erfahrung kann man bei so etwas leicht Fehler machen.
-
Shade Of Mine schrieb:
Die CPU power der embedded geraete ist ziemlich niedrig, genaue MHz zahlen stehen noch nicht fest, deshalb muessen wir mit sowenig last wie moeglich auf den geraeten auskommen.
vielleicht die verschlüsselung in einen externen chip auslagern?
schau mal hier: http://point-at-infinity.org/avraes/
-
rüdiger schrieb:
rapso schrieb:
RSA fuer die initializierung, ein paar randomizer die dir nen xor wert liefern fuer ne art one-time-pad. das ist sehr sehr flink und auch recht sicher.
ne ne ne, OTP ist doch totaler Blödsinn. Das funktioniert nur, wenn du wirklich gute Zufallszahlengeneratoren hast und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne, warum müssen bei jeder Diskussion zu Verschlüsselung Leute kommen und OTP erwähnen. OTP ist Schwachsinn. Vergesst es einfach!
glaubst du nur weil du bloedsinn, schwachsinn usw. rufst hinterlaesst du irgendeinen eindruck ausser laecherlichkeit? auf dem niveau nicht mit mir!
Wenn die Magnetkartenleser RSA aushalten, dann kann man auch einen vernünftigen Verschlüsselungsalgorithmus nehmen.
sehr oft ist es egal wie langsam RSA implementiert ist weil es nur zur initialisierung dient, 128byte zu entschluesseln schaft auch eine ec karten.
Es gibt ja auch Algorithmen, die kleiner und schneller sind, als zB AES.
AES (was symmetrisch ist) als substitution zu RSA (was assymetrisch ist)? das macht deinen ausbruch oben nicht serioeser.
-
Also ich würde gern wissen, welche Sicherheitsanforderung vorliegen. Wirklich Sicherheit, Pseudosicherheit wegen juritsche Rahmenbedinung.
-
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
-
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
es darf kein echter zufallsgenerator sein, es muss ein pseudogenerator sein, sodass beide seiten die gleichen werte erhalten ;).
-
rapso schrieb:
rüdiger schrieb:
rapso schrieb:
RSA fuer die initializierung, ein paar randomizer die dir nen xor wert liefern fuer ne art one-time-pad. das ist sehr sehr flink und auch recht sicher.
ne ne ne, OTP ist doch totaler Blödsinn. Das funktioniert nur, wenn du wirklich gute Zufallszahlengeneratoren hast und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne, warum müssen bei jeder Diskussion zu Verschlüsselung Leute kommen und OTP erwähnen. OTP ist Schwachsinn. Vergesst es einfach!
glaubst du nur weil du bloedsinn, schwachsinn usw. rufst hinterlaesst du irgendeinen eindruck ausser laecherlichkeit? auf dem niveau nicht mit mir!
Ich habe dazwischen ja auch ein Argument geliefert. Du hast einfach keine zuverlässige Quelle für Zufallszahlen auf dem Generator. Somit fällt OTP flach, weil dass eine der absolut kritischen Voraussetzungen für OTP ist. Ansonsten ist OTP _nicht_ sicher.
rapso schrieb:
Wenn die Magnetkartenleser RSA aushalten, dann kann man auch einen vernünftigen Verschlüsselungsalgorithmus nehmen.
sehr oft ist es egal wie langsam RSA implementiert ist weil es nur zur initialisierung dient, 128byte zu entschluesseln schaft auch eine ec karten.
Wenn du 128 byte entschlüsselst und für OTP nehmen willst, dann kannst du auch nur 128 byte Daten übertragen. Warum also nicht gleich die 128 byte Daten in das RSA-Paket packen?
rapso schrieb:
Es gibt ja auch Algorithmen, die kleiner und schneller sind, als zB AES.
AES (was symmetrisch ist) als substitution zu RSA (was assymetrisch ist)? das macht deinen ausbruch oben nicht serioeser.
Nicht für RSA. Ich habe nie behauptet, dass es für RSA sein soll. TLS verwendet asymetrische Verschlüsselungsverfahren nur um den Schlüssel zu übertragen (ähnlich wie dein Vorschlag). Skaliert aber wesentlich besser, weil der Schlüssel für die Session bestehen bleibt. Das macht deinen Vorschlag OTP zu verwenden auch nicht seriöser
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
Das Rauschen könnte man ja beeinflussen oder selbst auslesen, wenn man Zugang zum Gerät hat.
rapso schrieb:
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
es darf kein echter zufallsgenerator sein, es muss ein pseudogenerator sein, sodass beide seiten die gleichen werte erhalten ;).
Und damit funktioniert OTP eben nicht. OTP verlangt echte Zufallszahlen als Schlüssel!
-
Zeus schrieb:
Also ich würde gern wissen, welche Sicherheitsanforderung vorliegen. Wirklich Sicherheit, Pseudosicherheit wegen juritsche Rahmenbedinung.
Juristisch - nichts. Es werden keine Personenbezogenen Daten übermittelt - aber es werden eben Magnetstreifen erstellt und wir wolle nicht dass Jemand anhand des Datenverkehrs den wir haben selber solche Magnetkarten erstellt und unsere Kartenleser damit austricksen kann.
Der Datenverkehr findet auch nicht über das Internet statt, sondern in mehr oder weniger geschlossenen Netzen - wobei hier natürlich durchaus auch sowas wie WLAN vorkommen kann - die Netze sind also nicht abgesichert und tw sogar absichtlich offen für unbekannte Clients.
Wir garantieren halt eine gewisse Sicherheit wenn man unser System verwendet und sie damit (aktuell eben wegen besserer Sicherheit der Magnetstreifen) durchaus nicht schlecht positioniert.
-
rapso schrieb:
es darf kein echter zufallsgenerator sein, es muss ein pseudogenerator sein, sodass beide seiten die gleichen werte erhalten
verschlüsselung ist so ziemlich unwirksam, wenn man pseudo-zufallswerte nimmt, die auch ein angreifer vorausberechnen kann. wenn der verschlüsselungs-algo initialisierungsvektoren usw. austauschen muss, dann sollte er sich besser sowas hier bedienen: http://en.wikipedia.org/wiki/HMAC
rüdiger schrieb:
-fricky- schrieb:
rüdiger schrieb:
...und wie willst du die in einem Magnetkartenleser einbauen? Ne ne ne
mit ner z-diode, oder einem rauschgenerator: http://www.techlib.com/electronics/pinknoise.htm
oder gleich was fertiges nehmen: http://home.comcast.net/~orb/
geht alles, also nicht immer nur 'nein' sagen. wir sind ja nicht im c++ forum.
Das Rauschen könnte man ja beeinflussen oder selbst auslesen, wenn man Zugang zum Gerät hat.
was iss'n das für'n argument? wenn man zugang zum gerät hat, zumindenst auf dem level, dass man hardwareeingriffe machen kann, dann ist sowieso jede art von verschlüsselung für die katz.
-
-fricky- schrieb:
was iss'n das für'n argument? wenn man zugang zum gerät hat, zumindenst auf dem level, dass man hardwareeingriffe machen kann, dann ist sowieso jede art von verschlüsselung für die katz.
Ne, das stimmt nicht. Zumindest Verschlüsselungschips, Smartcards etc. sind ja so gebaut, dass man das Gerät zerstören müsste um einen Zugriff auf die Interna zu bekommen.
Aber ja, dass Argument ist ein bisschen weit hergeholt. Nur steht es wohl außer Frage, dass Shade an jedes Gerät noch zusätzliche Hardware basteln kann. Zumal sich dann ja eher ein Verschlüsselungschip anbieten würde.
Und das Rauschen kann man ja immer noch in gewisser Hinsicht beeinflussen bzw. Beeinflussungen des Rauschens ausnutzen.Mein Punkt ist einfach nur: OTP ist was für die Theorie. In der Praxis ist der Einsatz einfach nicht realistisch durchführbar (Gibt natürlich ein paar Spezialfälle. Aber die sind vernachlässigbar) oder führt dazu, dass das System unsicher wird. Die Amis konnten zB während des 2. Weltkriegs die Kommunikation des Auswärtigenamtes lesen, obwohl die OTP benutzten, einfach weil der Zufallsgenerator mit dem die Schlüssel generiert wurden nicht zufällig genug war.
-
Warum muss der client das passwort generieren? Das kann doch auch der Server machen.
-
nachgefragt schrieb:
Warum muss der client das passwort generieren? Das kann doch auch der Server machen.
Aber dann hat man immer noch das Problem den Schlüssel zu verteilen. Und bedenke, dass du für jedes verschlüsselte Byte ein Byte Schlüssel benötigt.
Sprich es bringt dir auch nichts den Schlüssel via asymmetrischer Kryptographie zu verteilen, da du dann genauso gut die Nachricht direkt via asymmetrischer Kryptographie schicken könntest.
=> OTP ist nicht praktikabel.
-
rüdiger schrieb:
Aber dann hat man immer noch das Problem den Schlüssel zu verteilen. Und bedenke, dass du für jedes verschlüsselte Byte ein Byte Schlüssel benötigt.
Sprich es bringt dir auch nichts den Schlüssel via asymmetrischer Kryptographie zu verteilen, da du dann genauso gut die Nachricht direkt via asymmetrischer Kryptographie schicken könntest.
=> OTP ist nicht praktikabel.
rapso schrieb:
...fuer ne art one-time-pad...
Nen richtigen OTP wollte er glaub ich nicht, sondern nur ein relativ langes Passwort, so habs ich zumindest verstanden.
XOR dürfte halt die beste Wahl sein, wenn man wirklich extrem CPU Power sparen muss, sonst kann man auch was aufwendigeres nehmen.