Protokoll "absichern" (Verschlüsselung, Man-in-the-middle-Robustheit, Teilnehmererkennung, etc.)

[Ralf (Gast)]

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

[vgn (Gast)]

read a book or something!

[Axel S. (a-za-z0-9)]

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.

[Ralf (Gast)]

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

[Axel S. (a-za-z0-9)]

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.

[Pandur S. (jetztnicht)]

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.

[Dergute W. (derguteweka)]

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

[Stefan F. (Gast)]

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.

[Pandur S. (jetztnicht)]

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.

[Stefan F. (Gast)]

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.

[Ralf (Gast)]

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

[Schlaumaier (Gast)]

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. ;)

[Hasch (Gast)]

Wenn nicht vor mitlesen geschützt werden soll bietet sich keyed hashing 
an, das ist vom Implementierungsaufwand auf einem µc überschaubar.

[Dergute W. (derguteweka)]

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

[Pandur S. (jetztnicht)]

> 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.

[Nosnibor (Gast)]

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.

[oszi40 (Gast)]

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

[Nosnibor (Gast)]

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.