Hallo, was mich interessiert ist, wie man ein Protokoll für ein Netzwerk aus Microcontrollern "sicher" (im Sinne von Datensicherheit) macht, also mindestens um Verschlüsselung und Robustheit gegen "Man-in-the-middle"-Angriffe erweitert. Ich bewege mich hier (erstmal) auf theoretischer Ebene, falls also wichtige Angaben fehlen, bitte fragen - ich steh erst am Anfang der Thematik :) Kollisionserkennung oder definierte Antwortzeiten (im Sinne von Übertragungssicherheit) lasse ich mal außen vor. Ich nehme der Einfachheit halber das S.N.A.P.-Protokoll als Beispiel: http://www.hth.com/snap/ Scheint zwar "kaltgestellt" zu sein, da keinerlei Updates der für Erweiterung vorgesehenen Bitfelder seit mehreren Jahren, aber ich find's soweit eigentlich ganz gut, verständlich und vermutlich einfach zu implementieren. Man kann vermutlich mehr oder weniger jedes andere Protokoll nehmen, welches halbwegs in Schichten ála OSI arbeitet. Ich hab versucht, S.N.A.P. mal auf's OSI-Modell abzubilden - ich weiß nicht ob das der richtige Ansatz ist, aber irgendwo musste ich ja anfangen. Wenn jemand ein besseres Beispiel hat, um daran die Erweiterung vorzunehmen, gerne her damit. Wenn ich nach der Wiki-Beschreibung https://de.wikipedia.org/wiki/OSI-Modell#Die_sieben_Schichten der Schichten gehe, ist S.N.A.P. Schicht 2, weil das Protokoll von sich behauptet, unabhängig vom Übertragungsmedium zu sein. Schaue ich mir aber dann die Erklärung zu "Frames" aus der Wiki-Tabelle an, dann müsste ich sagen, dass es Schicht 1 & 2 ist, weil es sowohl Präambel als auch Sync-Byte (= Start-of-Frame) definiert. Soweit, so gut... wenn ich weiter nach der Wiki-Tabelle gehe, sind die "Protokolle", die ich mit dem Begriff "verschlüsselt" assoziiere in Schicht 5+ angesiedelt, bspw. HTTPS. Der Beschreibung nach ist Verschlüsselung Aufgabe der Schicht 6. Damit ist nach meinem Verständnis nur ein Teil des Frames aus Schicht 1 bzw. 2 verschlüsselt, ist das korrekt? Wenn ja, was würde man dann bei S.N.A.P. verschlüsseln? Aus der Hüfte geschossen würde ich sagen, alles außer dem Sync-Byte und der Checksumme. Begründung: aus den Headerdefinitionsbytes kann man Rückschlüsse auf die Art der Nachricht bzw. deren Länge ziehen. Und Absender/Empfänger sowie die eventuelle Verwendung des Kommandomodes gehen m.E. auch keinen was an. Bezüglich "Man-in-the-middle"-Angriffen, ich denke, spätestens hier sollte ich mal zumindest grob die Netzwerkstruktur und die Angriffe, die ich mir vorstellen kann, definieren: 1) Struktur: Master-/Slave- oder MultiMaster-System (beides gibt das S.N.A.P.-Protokoll ja her) 2) Topologie: Bus, d.h. alle Teilnehmer hängen an der gleichen Strippe (evtl. mit Repeater) - ähnlich RS485. 3) Angriffe: a) ein "fremder" Teilnehmer lauscht passiv mit und gibt die Daten nach "irgendwohin" weiter b) ein "fremder" Teilnehmer gibt sich als neues Mitglied des Netzwerks aus c) ein "fremder" Teilnehmer ersetzt ein bestehendes Mitglied des Netzwerks 3a ist ja der eigentliche Grund für die Verschlüsselung. 3b würde man in einem Master/Slave-System mit einer WhiteList im Master lösen, richtig? Hierzu müssten die Teilnehmer etwas unikates aufweisen, um sie eindeutig unterscheiden zu können (UniqueID, MAC-Adresse o.ä. und selbst die ist ja fälschbar). In einem MultiMaster-System müssten alle Teilnehmer die WhiteList führen. 3c in dem Fall ist denke ich eh alles über die Wupper... Okay, zurück zu 3b: soweit ich es verstanden habe, werden hierfür u.a. Zertifikate bzw. Signaturen und Message Authentication Codes verwendet. Zertifikate, um den Absender zu identifizieren, und MACs um die Manipulation von Nachrichten erkennen zu können. Die MACs i.V.m. Zeitstempel, fortlaufender Nummer oder Einmal-MACs habe ich denke ich verstanden - zumindest mit der Beschreibung von Wiki :) Das mit den Zertifikaten/Signaturen durchschaue ich noch nicht ganz. Die Zertifikate "bescheinigen", dass man wirklich mit dem gewünschten Teilnehmer und nicht mit einem Fremden kommuniziert. Wie sieht das abgebildet auf ein Master-/Slave- oder MultiMaster-System aus? Muss das Zertifikat nicht schon vor der Inbetriebnahme des Teilnehmers am Netzwerk im Teilnehmer hinterlegt sein, damit das ganze "sicher" wird? Oder kann das Zertifikat auch bei der Inbetriebnahme am Netz ausgetauscht werden? Wie unterscheidet man dann einen "gewünschten" neuen Teilnehmer von einem "Angreifer"? Zum Zertifikat selber: wie wird dieses generiert? Aus der Wiki-Beschreibung werd ich nicht ganz schlau. Soweit ich es verstanden habe mittels Public-Key, also asymmetrischem Schlüsselaustausch. Das Zertifikat wird lt. Wiki aber nicht über die Nachricht, sondern deren Hashwert gebildet. Was aber ist dann die Nachricht? Ist damit tatsächlich jede Übertragung gemeint oder "nur" einmalig beispielsweise die UID des Teilnehmers? Wenn für jede Übertragung ein Zertifikat erstellt und mitgeschickt werden muss, bläht das ja ganz schön auf. Oder verwechsle ich hier Zertifikat und Signatur? Um es nochmal zu betonen, ich bewege mich hier auf seeehr theoretischem Boden, das ist mir klar - mir geht's drum, erstmal die Grundlagen zu verstehen. Falls ich hier also Sachen vermenge, die nicht zusammen gehören möge man es mir nachsehen und helfen das sauber aufzudröseln. Grüße
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
read a book or something!
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Ralf schrieb: > was mich interessiert ist, wie man ein Protokoll für ein Netzwerk ... aus > "sicher" (im Sinne von Datensicherheit) macht Man würde damit anfangen, ein einschlägiges Buch zu lesen. Sagen wir mal "Applied Cryptography" von Bruce Schneier. Dann schaut man sich an, was für Angriffe man denn erwartet. Schau an, das machst du ja sogar. Auf eine oberflächliche Art. > spätestens hier > sollte ich mal zumindest grob die Netzwerkstruktur und die Angriffe, die > ich mir vorstellen kann, definieren: > 1) Struktur: Master-/Slave- oder MultiMaster-System (beides gibt das > S.N.A.P.-Protokoll ja her) > 2) Topologie: Bus, d.h. alle Teilnehmer hängen an der gleichen Strippe > (evtl. mit Repeater) - ähnlich RS485. > 3) Angriffe: > a) ein "fremder" Teilnehmer lauscht passiv mit und gibt die Daten > nach > "irgendwohin" weiter > b) ein "fremder" Teilnehmer gibt sich als neues Mitglied des > Netzwerks > aus > c) ein "fremder" Teilnehmer ersetzt ein bestehendes Mitglied des > Netzwerks Und dann gleicht man das mit den kryptographischen Begriffen ab. Mit diesen Begriffen findet man dann die kryptographischen Primitiven, die den jeweiligen Aspekt absichern. Zertifikate a'la SSL/TLS sind eine Art "silver bullet". Sie sind aber teuer (aufwendig) und erfordern Infrastruktur. > Zum Zertifikat selber: wie wird dieses generiert? Ein Zertifikat wird von einer vertrauenswürdigen dritten Stelle erzeugt, die gemeinhin CA ( certificate authority ) genannt wird. Der Aufwand zum Betreiben einer solchen CA ist ein Teil des "teuer" von eben. > Soweit ich es verstanden > habe mittels Public-Key, also asymmetrischem Schlüsselaustausch. Public-Key Krypto ist ein Baustein für Zertifikate. Aber gleich mehrfach. Zum einen hat die CA selber einen solchen Schlüssel, mit dem sie von ihr ausgestellte Zertifikate signiert (der public key ist öffentlich bekannt und dient zur Prüfung der Signatur). Zum zweiten enthält das Zertifikat den public key des Teilnehmers, für den das Zertifikat ausgestellt wurde. Wenn jemand mit dem reden will, läßt er sich das Zertifikat schicken (Klartext). Er prüft anhand der Signatur, ob das Zertifikat von einer CA kommt, der er vertraut. Und wenn ja, nutzt er den public key aus dem Zertifikat, um mit dem anderen Teilnehmer einen Sitzungsschlüssel für die eigentliche Kommunikation auszuhandeln. Falls es die Anwendung erfordert, passiert das in beiden Richtungen. > Das > Zertifikat wird lt. Wiki aber nicht über die Nachricht, sondern deren > Hashwert gebildet. Zertifikate werden nicht für Nachrichten gebildet. Zertifikate sind Ausweispapiere für Kommunikationsteilnehmer. Nachrichten werden verschlüsselt und evtl. signiert. Nachrichten werden mit dem Sitzungsschlüssel (im wesentlichen ein Zufallswert, den nur die beiden Partner kennen) unter Verwendung eines symmetrischen Verfahrens verschlüsselt. Das deswegen, weil symmetrische Verfahren viel billiger sind. Eine Signatur wird in der Tat nur über den Hashwert der Nachricht gebildet statt über der Nachricht selber. Einfach deswegen, weil public key Krypto teuer ist. Da will man nicht u.U. Megabytes an Daten durchjagen. Statt dessen bildet man einen kurzen Hashwert und signiert den. Wenn die Nachrichten immer kurz sind, kann man sich das natürlich sparen.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Axel S. schrieb: > Man würde damit anfangen, ein einschlägiges Buch zu lesen. Sagen wir mal > "Applied Cryptography" von Bruce Schneier. Danke. > Dann schaut man sich an, was für Angriffe man denn erwartet. Schau an, > das machst du ja sogar. Auf eine oberflächliche Art. Ich bin bemüht :) > Und dann gleicht man das mit den kryptographischen Begriffen ab. Mit > diesen Begriffen findet man dann die kryptographischen Primitiven, die > den jeweiligen Aspekt absichern. Okay, also erstmal Lektüre. > Zertifikate a'la SSL/TLS sind eine Art "silver bullet". Sie sind aber > teuer (aufwendig) und erfordern Infrastruktur. > Ein Zertifikat wird von einer vertrauenswürdigen dritten Stelle erzeugt, > die gemeinhin CA ( certificate authority ) genannt wird. Der Aufwand > zum Betreiben einer solchen CA ist ein Teil des "teuer" von eben. Mmmh, also nicht unbedingt was für ein "einfaches" Microcontrollernetzwerk. > Public-Key Krypto ist ein Baustein für Zertifikate. Aber gleich > mehrfach. Zum einen hat die CA selber einen solchen Schlüssel, mit dem > sie von ihr ausgestellte Zertifikate signiert (der public key ist > öffentlich bekannt und dient zur Prüfung der Signatur). Zum zweiten > enthält das Zertifikat den public key des Teilnehmers, für den das > Zertifikat ausgestellt wurde. Wenn jemand mit dem reden will, läßt er > sich das Zertifikat schicken (Klartext). Er prüft anhand der Signatur, > ob das Zertifikat von einer CA kommt, der er vertraut. Und wenn ja, > nutzt er den public key aus dem Zertifikat, um mit dem anderen > Teilnehmer einen Sitzungsschlüssel für die eigentliche Kommunikation > auszuhandeln. Falls es die Anwendung erfordert, passiert das in *beiden* > Richtungen. In beide Richtungen heisst, dass die Slaves dem Master vertrauen umgekehrt? Also potentiell geeignet um zu prüfen, ob ein Teilnehmer überhaupt ins Netzwerk darf bzw. mit ihm geredet wird. > Zertifikate werden nicht für Nachrichten gebildet. Zertifikate sind > Ausweispapiere für Kommunikationsteilnehmer. Nachrichten werden > verschlüsselt und evtl. signiert. Also wie vermutet Begrifflichkeiten verwechselt. Ralf
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Ralf schrieb: > Axel S. schrieb: >> Ein Zertifikat wird von einer vertrauenswürdigen dritten Stelle erzeugt, >> die gemeinhin CA ( certificate authority ) genannt wird. Der Aufwand >> zum Betreiben einer solchen CA ist ein Teil des "teuer" von eben. > Mmmh, also nicht unbedingt was für ein "einfaches" > Microcontrollernetzwerk. Das Hauptproblem mit Zertifikaten und µC dürfte sein, daß man Zertifikate aus Sicherheitsgründen mit einer begrenzten Lebensdauer ausstattet (Standard sind 2 Jahre). Das heißt man muß innerhalb von 2 Jahren alle Zertifikate rundherum austauschen. Wenn man das verpaßt, geht dann plötzlich nichts mehr. Auch große Anbieter kriegen das regelmäßig nicht hin. Letztens war Cisco mal wieder in den Schlagzeilen, weil eines ihrer Produkte den Betrieb einstellte. Zertifikat abgelaufen. >> Falls es die Anwendung erfordert, passiert das in *beiden* >> Richtungen. > In beide Richtungen heisst, dass die Slaves dem Master vertrauen > umgekehrt? "Im Internet weiß niemand, daß du ein Hund bist" In einem Netzwerk weißt du vorher nicht, mit wem du sprichst. Wenn wir bei deinem Sensornetzwerk bleiben, dann weiß der Sensor nicht, ob der jenige, dem er die Daten schickt, diese Daten überhaupt haben darf. Die andere Seite wiederum weiß nicht, ob die Daten tatsächlich vom Sensor kommen oder jemand anderem. Das kann jeweils eine Gefahr darstellen. Oder auch nicht. Das ist genau der Teil, der geklärt werden muß, bevor man sich für ein Protokoll entscheidet. Wenn man Zertifikate verwendet, dann muß jeder eins haben, dessen Identität zweifelfrei festgestellt werden soll. Im Extremfall sind das alle.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Man sollte sich bewusst sein, dass verschluesselte Nachrichten, sobald man flexibel bleiben will, einen 32 bit Controller bedingen. Einen Slave alleine mit einem festen Schluessel, ja, das geht noch mit einem AVR, dann ist aber langsam Schluss.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Moin, Da sollte man die eigenen Faehigkeiten nicht zu sehr ueberschaetzen. Daher wuerde ich die Finger von sowas lassen. Also nicht selbst irgendwelche "sicheren" Protokolle entwerfen, sondern lieber gucken, was es schon so alles geeignetes gibt. Und das dann einbauen. Gruss WK
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Generell würde ich hier nicht versuchen, das Rad neu zu erfinden. Diese Thematik ist zu komplex, was man alleine schon daran erkennt, dass sogar große Projekte wie diese elektronische Krankenakte diesbezüglich gravierende Fehler hatten. Besser ist es, die Endgeräte ohne besondere Sicherheit zu entwickelen und deren Kommunikation durch einen sicheren Kanal (z.B: VPN) zu tunneln. Das kannst du auf separate handelsübliche Computer auslagern und ggf. durch etwas anderes ersetzen, falls eine inakzeptable Lücke gefunden wird. Die Dokumentation zu OpenSSL und den darin kombinierten Technologien könnte ein guter Einstiegspunkt sein, um sich einzulesen. Auch die Erklärungen zu geschlossenen Lücken in OpenSSL finde ich interessant.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Naja, das sind auch verschiedene Anwendungen. Die embedded anwendung ist eine Verschluesselung der embedded kommunikation. Falls die Kommunikation selbst abgeaendert werden kann, also nicht sicher ist. Weil das Gelaende zB zugaenglich ist. Weil die Anlage zu gross ist. zB weil die Raffinerie/Anreicherungsanlage unterwandert sein kann. Man koennte sich auch fragen, ob man sie nicht besser abschalten sollte... Und das andere ist das Gateway zu einem externen Computer.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Joggel E. schrieb: > Die embedded anwendung ist > eine Verschluesselung der embedded kommunikation. Was verstehst du unter "embedded kommunikation"? Alles, was einen Raum verlässt, ist für mich nicht mehr embedded und deswegen würde ich das ganz dringend über Standard-Protokolle laufen lassen die man fix und fertig kauft. Im einfachsten Fall Bluetooth oder WLAN.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Hallo an alle, vielen Dank für eure Antworten. Axel S. schrieb: >> Mmmh, also nicht unbedingt was für ein "einfaches" >> Microcontrollernetzwerk. > Das Hauptproblem mit Zertifikaten und µC dürfte sein, daß man > Zertifikate aus Sicherheitsgründen mit einer begrenzten Lebensdauer > ausstattet (Standard sind 2 Jahre). Das heißt man muß innerhalb von 2 > Jahren alle Zertifikate rundherum austauschen. Wenn man das verpaßt, > geht dann plötzlich nichts mehr. Auch große Anbieter kriegen das > regelmäßig nicht hin. Letztens war Cisco mal wieder in den > Schlagzeilen, weil eines ihrer Produkte den Betrieb einstellte. > Zertifikat abgelaufen. Woran scheitert das denn eigentlich? Organisatorisch? Faulheit? >> In beide Richtungen heisst, dass die Slaves dem Master vertrauen >> umgekehrt? > In einem Netzwerk weißt du vorher nicht, mit wem du sprichst. > ... > Wenn man Zertifikate verwendet, dann muß jeder eins haben, dessen > Identität zweifelfrei festgestellt werden soll. Im Extremfall sind das > alle. Okay, dann geh ich mal vom "schlechtesten Fall" aus und sage: alle müssen eins haben. Joggel E. schrieb: > Man sollte sich bewusst sein, dass verschluesselte Nachrichten, sobald > man flexibel bleiben will, einen 32 bit Controller bedingen. Einen Slave > alleine mit einem festen Schluessel, ja, das geht noch mit einem AVR, > dann ist aber langsam Schluss. Mir geht's ums Protokoll, nicht um die verwendete MCU :) Ob die dann 32-bit, ohne/mit AES-Engine oder sonstwas ist, steht auf nem (bisher unbeschriebenen) anderen Blatt. Dergute W. schrieb: > Da sollte man die eigenen Faehigkeiten nicht zu sehr ueberschaetzen. > Daher wuerde ich die Finger von sowas lassen. Also nicht selbst > irgendwelche "sicheren" Protokolle entwerfen, sondern lieber gucken, was > es schon so alles geeignetes gibt. Und das dann einbauen. Ich bin eigentlich grad eher beim EINschätzen :D Ich stimme dir zu, was fertiges ist vorzuziehen, weil's erprobt und auch schon belastet wurde. Nur leider hab ich da bisher nichts gefunden, was ich für geeignet halte. Das liegt aber daran, dass ich noch nicht genau weiß, was ich eigentlich haben will. Jedenfalls wäre die komplette Abbildung von bspw. Ethernet/TCP-IP/etc. wohl ein bisschen oversized, selbst wenn ich davon ausgehe dass, bezogen auf's OSI-Modell, gar nicht alle Schichten benötigt werden. Das war auch der Grund, warum ich die "Standard"-Protokolle nicht in Betracht gezogen habe. Stefan ⛄ F. schrieb: > Generell würde ich hier nicht versuchen, das Rad neu zu erfinden. Diese > Thematik ist zu komplex, was man alleine schon daran erkennt, dass sogar > große Projekte wie diese elektronische Krankenakte diesbezüglich > gravierende Fehler hatten. Naja, je größer das Projekt, desto größer die Bugs, oder? :) > Besser ist es, die Endgeräte ohne besondere Sicherheit zu entwickelen > und deren Kommunikation durch einen sicheren Kanal (z.B: VPN) zu > tunneln. Das kannst du auf separate handelsübliche Computer auslagern > und ggf. durch etwas anderes ersetzen, falls eine inakzeptable Lücke > gefunden wird. Ähm... Microcontroller-Netzwerk, wie oben geschrieben - keine Notwendigkeit für VPN oder ähnliches, bzw. wenn, dann nicht Aufgabe innerhalb dieses Netzwerks. > Die Dokumentation zu OpenSSL und den darin kombinierten Technologien > könnte ein guter Einstiegspunkt sein, um sich einzulesen. Auch die > Erklärungen zu geschlossenen Lücken in OpenSSL finde ich interessant. Das schau ich mir an, danke. Grüße
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Gegen A. kannst du nix machen. Lauschen kann man immer. Ob er versteht was "gesprochen" wird ist eine andere Sache. B + C kann man wenn man das Protokoll "erweitert" leicht verhindern. Und zwar in den du ein privates Hilfsprotokoll benutzt. Du verschlüsselst die Daten anhand der Uhrzeit nochmal , übergibst sie an der verschlüsselte Übertragungsprotokoll und sendest sie so. Der Empfänger entschlüsselt nach der Norm des Übertragungsprotokoll und dann mit den aktuellen Schlüssel der Zeit (2-3 Uhr = x23ds-Code) noch mal. Ist im Prinzip das selbe als wenn du über ssl eine Zip-Datei überträgst. Aber zu knacken ist grundsätzlich alles. Ist nur eine Frage der Zeit / Technik. Bei Zertifikate muss ich immer an Lehmann-Brothers denken. ;)
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Wenn nicht vor mitlesen geschützt werden soll bietet sich keyed hashing an, das ist vom Implementierungsaufwand auf einem µc überschaubar.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Moin, Ralf schrieb: > Das liegt aber daran, dass ich noch nicht genau weiß, was ich > eigentlich haben will. > Jedenfalls wäre die komplette Abbildung von bspw. Ethernet/TCP-IP/etc. > wohl ein bisschen oversized, selbst wenn ich davon ausgehe dass, bezogen > auf's OSI-Modell, gar nicht alle Schichten benötigt werden. > Das war auch der Grund, warum ich die "Standard"-Protokolle nicht in > Betracht gezogen habe. Das ist dann halt so die Frage. Ich glaube: Da denkt man oft, das alles ist bisschen zu oversized fuer meinen Fall, denn ich brauche ja nur bla und blupp, oder ich weiss es noch garnicht genau... Aber wie's dann so kommt, kommt doch noch das eine oder andere dazu (z.b. Security) oder man hat's nicht bedacht und eh' man sich's versieht, waere es insgesamt doch einfacher gewesen, gleich am Anfang das "oversized" einzubauen und den Rest und alles was sonst noch so kommen kann, mit bestehenden und erprobten Standards totzuschlagen. Gruss WK
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
> Alles, was einen Raum verlässt, ist für mich nicht mehr embedded und
deswegen würde ich das ganz dringend über Standard-Protokolle laufen
lassen die man fix und fertig kauft. Im einfachsten Fall Bluetooth oder
WLAN.
Aaaaahhhhh. Eher nicht. Dann hast du verloren. WLAN... tsss.
Eine 32bit maschine mit eiem Linux drauf hat natuerlich nicht die
Zuverlaessigkeit wie eine kleinere Maschine mit weniger Komplexitaet.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
An fertigen Standards gibt es ja nicht nur SSL auf Schicht 4 (TCP) sondern z.B. auch IPsec (Schicht 3, IP) oder MACsec (Schicht 2, Ethernet). Gerade die letzten beiden unterscheiden deutlich zwischen der reinen Sicherung der Nutzdaten (Verschlüsselung + Hash mit symmetrischen Schlüsseln) und dem Einrichten dieser verschlüsselten Verbindungen (Schlüsselaustausch: Einigung über verwendete Algorithmen, Vertrauensmanagement (Zertifikatskette prüfen), Schlüsselerzeugung). Letzteres braucht meist asymmetrische Algorithmen, die nochmal mehr Speicher und Rechenleistung brauchen (AES kann mit ca. 10kB zusätzlichem Code bereits eine Belastung sein). Wenn man nur ein kleines Netzwerk hat, kann man sich das Zertifikatsgedöns auch sparen und die symmetrischen Schlüssel von Hand eintragen. Das ist natürlich für viele Anwendungen immernoch Overkill. Um z.B. einen Fensterkontakt mit der Alarmanlagen-Zentrale zu verbinden braucht man kein Ethernet, denn der Sensor hat ja nur ein einziges Bit zu melden; wenn er das nicht gerade in XML oder JSON formuliert, ist es völliger Quatsch, das z.B. noch mit 20 Byte IP-Header, 8 Byte IPsec-Header, 16 Byte Initialisierungsvektor und 20 Byte Hash aufzublähen. Da ist es dann sinnvoller, sich selbst ein Protokoll zu basteln, das mit einem AES-Block für die Nachricht auskommt. Natürlich muss man sich vorher über die möglichen Angriffe (Abhören, replay, Manipulieren, Verzögerung) und wirksame Gegenmaßnahmen informieren.
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
Zertifikaaaate sind Mist, wenn es gut und lange funktionieren soll. Beispiel: Arztpaxen, wo wegen eines VOR ORT abgelaufenen Zertifikats die Verbindung fehlte und die Kiste VOR ORT getauscht od. aktualisiert werden mußte. WER bezahlt die dezentralen Anfahrten???? "Störung nur vor Ort behebbar" https://www.heise.de/news/Elektronische-Gesundheitskarte-Reparatur-des-Stammdatendienstes-beginnt-4772549.html
Re: Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)
oszi40 schrieb: > Zertifikaaaate sind Mist, wenn es gut und lange funktionieren soll. Jedes Stück Technik ist Mist, wenn man nicht bereit ist, sich um die nötige Wartung zu kümmern. Ein Personalausweis ist auch Mist, wenn man das Gültigkeitsdatum verpennt. Der richtige Mist an Zertifikaten ist, dass sie dem Nutzer vortäuschen, dass das Problem des Vertrauensmanagements jetzt endgültig gelöst ist. Und dann denkt natürlich niemand mehr an Updates. Oder daran, dass der Browser nicht wissen kann, ob "Iranian Telecom" oder "Let's Encrypt" garantieren kann, dass der Server, mit dem er da redet, der echte microcontroller.net ist.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.