Erstmal ein freundliches Hallo an euch!
Aktuell habe ich mir vorgenommen, einen Schlüsselaustausch mit
CAN-Controller zu realisieren. Dafür viel mir letztes Jahr im
CAN-Newsletter das von Bosch vorgestellt Plug-and-Secure Verfahren ein.
Leider ist es doch nicht ganz so simpel, wie es anfangs schien. Das
Protokoll sieht vor, dass zwei Parteien die Payloadbits (bestehend aus
dem Schlüsselbit und dem zugehörigen inversen Bit) zeitgleich auf den
Bus schreiben und lesen. Dadurch kann man bei einer Kombination von '00'
davon ausgehen, dass beide Parteien sich zueinader inverse Bits
geschickt haben und entsprechend wissen, wer welches Bit gesendet hat.
Bei '01' oder '10' werden diese Bits sozusagen verworfen und das
entsprechende Bit aus dem zu übertragenen Schlüssel gelöscht.
Soviel zu der sehr kurzen Theorie.
Praktisch habe ich es mit einem Transceiver schon hinbekommen, einen
Schlüsselaustausch damit herzustellen. Nun wollte ich es auch für den
Controller schreiben.
Dabei benutze ich zwei AT90CAN auf dem Olimex Board.
Langsam zweifle ich jedoch, dass es mit dem AT90CAN möglich ist, dass
beide Parteien zeitgleich eine Nachricht senden und empfangen. Bisher
habe ich es mit einem zusätzlichen Interrupt als Trigger versucht, der
von der einen Partei aktiviert wird und der zweiten damit mitteilt, dass
beide nun ihre Nachricht senden sollen. Leider ohne Erfolg.
Kann mir einer von euch vielleicht etwas zum zeitgleichen Senden mit dem
AT90CAN sagen?
Viele Grüße
Peter
Hallo, ne Frage: dass beide Parteien zeitgleich eine Nachricht senden
und empfangen.
Zeitlich senden und empfangen? Wie soll das gehen? Ein MC kann doch
immer nur eins machen oder steh ich da auf dem Schlauch?
Danke.
Ugh, das ist doch quasi ein Misbrauch vom CAN?
Also zwei Controller sollen zeitgleich eine Botschaft mit der gleichen
ID auf den CAN schreiben und die Botschaften sollen sich dann inhaltlich
gegenseitig überschreiben?
Das wird ohne sehr spezialisierte Hardware nicht funktionieren.
Ein üblicher CAN-Controller kümmert sich um den kompletten Daten-Rahmen,
das bekommt man erstens nicht synchronisiert und zweitens dürfte das
Checksummen-Fehler geben, falls man es zufälligerweise doch synchron
hinbekommt.
Man müsste schon auf den Bus lauschen und den Payload synchron zur
Botschaft mit eintakten.
Ohne FPGA oder speziell auf sowas angepassten CAN-Controller wird das
nichts.
Sehen wir mal vom Missbrauch von CAN ab. Es dient ja letztendlich zu
einem größeren Wohl ;) . Dem Einführen eines gemeinsamen geheimen Keys.
Genau, durch den Payload wird der Key erzeugt. Wie gesagt, kann ein
Angreifer bei einem '00' Bit Paar im Payload nicht wissen, wer von den
beiden Parteien die 1 und die 0 gesendet hat. Dadurch kann er nur bei
jedem Paar raten.
Ich denke mal bei dem CRC Check könnte man irgendwie tricksen, um das
hinzubekommen. Ich befürchte nur, dass es wirklich daran scheitert, dass
es unmöglich ist, zwei Nachrichten synchron zu übermitteln.
Peter schrieb:> Kann mir einer von euch vielleicht etwas zum zeitgleichen Senden mit dem> AT90CAN sagen?
Die Antwort lesen:
Beitrag "Re: AT90CAN Probleme beim senden in kurzer Folge"Rudolph schrieb:> Man müsste schon auf den Bus lauschen und den Payload synchron zur> Botschaft mit eintakten.> Ohne FPGA oder speziell auf sowas angepassten CAN-Controller wird das> nichts.
Kann mich dem nur anschliessen.
Hier ist ein aktueller Artikel zu dem Verfahren:
http://www.all-electronics.de/security-kommunikation-in-can-netzwerken-plug-and-secure-datensicherheit/
Dort steht u.a., dass zur Einhaltung von Stuff-Bit-Regeln und der
korrekten CRC entsprechende Hardware im CAN-Controller oder im
Transceiver vorhanden sein muss (Bild 3).
Sprich: mit den zur Zeit verfügbaren CAN-Controllern, bzw. Transceivern
funktioniert das Verfahren nicht.
Oh vielen Dank, ich kannte bisher nur das Paper und die Grafik war darin
nicht enthalten und davon wurde darin nichts geschrieben. Das ist nun
ein wenig blöd.
Daniel E. schrieb:> Hallo, ne Frage: dass beide Parteien zeitgleich eine Nachricht senden> und empfangen.>> Zeitlich senden und empfangen? Wie soll das gehen? Ein MC kann doch> immer nur eins machen oder steh ich da auf dem Schlauch?>> Danke.
Ja, Du stehst drauf.
Der CAN.Controller muß zwecks erkennen von Buskollisionen immer mithören
(Rx) was er sendet(Tx). Somit it Rx und Tx gleichzeitig möglich und
nötig.
MiWi
Wenn du das so schreibst, könnte das, was ich vorhabe ja doch in einer
vereinfachten Weise gehen? Man müsste sie nur noch zum ca gleichen
Senden bekommen?
Hast du den in dem verlinkten Artikel komplett gelesen?
"Durch die zeitgleiche Übertragung von CAN-Botschaften durch Alice und
Bob im Payload-Teil ergeben sich praktische Herausforderungen, zum
Beispiel hinsichtlich einer gegebenenfalls notwendigen Einführung von
Bitstopfen bei der Übertragung von mehr als fünf gleichen Bits in Folge
oder der Korrektheit der zyklischen Prüfsumme (CRC) für die überlagerte
CAN-Botschaft. Dies liegt daran, dass die Überlagerung von korrekten
Einzelbotschaften im Allgemeinen nicht zu einer korrekten überlagerten
CAN-Botschaft führt. Eine Lösung stellt die dynamische Ermittlung von
CRC und Bitstopfen basierend auf der effektiven Bitsequenz auf dem
CAN-Bus anstatt auf Grundlage der jeweiligen Sendesequenzen dar. Damit
entsteht eine Rückwärtskompatibilität, sodass Steuergeräte, die das
Verfahren nicht unterstützen, keine Probleme verursachen. Das Verfahren
lässt sich unkompliziert in den normalen CAN-Verkehr einbinden, sodass
Nachrichten mit hoher Priorität nicht gestört werden."
Und deswegen braucht es spezielle Hardware im Controller/Transceiver:
"Zur Realisierung des Verfahrens lässt sich ein entsprechendes
Hardware-Modul entweder direkt in einen Mikrocontroller oder in einen
CAN-Transceiver integrieren."
Selbst wenn du die Telegramme zeitgleich sendest, ist spätestens
aufgrund des unterschiedlichen Inhaltes bei der CRC Schluss. Dann siehst
du nur Active-/Passive-Fehler.
Peter schrieb:> Aktuell habe ich mir vorgenommen, einen Schlüsselaustausch mit> CAN-Controller zu realisieren. Dafür viel mir letztes Jahr im> CAN-Newsletter das von Bosch vorgestellt Plug-and-Secure Verfahren ein.
Dafür benötigt man einen passend veränderten CAN Controller. Für Bosch
kein Problem...
Peter schrieb:> Langsam zweifle ich jedoch, dass es mit dem AT90CAN möglich ist, dass> beide Parteien zeitgleich eine Nachricht senden und empfangen.
Während der Arbitrierung geht das, wenn man das SOF zeitgleich
hinbekommt. Mehr als ein Bit pro Arbitrierung dürfte so aber nicht
hinzubekommen sein.
Wichtig ist, dass für einen mitloggenden Dritten nicht zu erkennen ist,
welche Teilnehmer welche Nachricht geschickt hat.
Rudolph schrieb:> Also zwei Controller sollen zeitgleich eine Botschaft mit der gleichen> ID auf den CAN schreiben und die Botschaften sollen sich dann inhaltlich> gegenseitig überschreiben?
Zwei Controller senden gleichzeitig. Auf dem CAN Bus alles wie gehabt.
Die CAN Controller brechen jedoch nicht ab, wenn sie etwas anderes
empfangen als Senden (und korrigieren den Stream). Da beide Controller
Ihre Nachrichten kennen, können sie aufgrund der Empfangsdaten auf die
Sendedaten des jeweils anderen schließen. Wer auf dem CAN Bus ohne
Kenntnis eines Stream mitliest, kann dies nicht.
Peter schrieb:> Genau, durch den Payload wird der Key erzeugt.
Nein, es werden die Schlüssel getauscht, ohne dass sie mitgelesen werden
können.
MiWi schrieb:> Der CAN.Controller muß zwecks erkennen von Buskollisionen immer mithören> (Rx) was er sendet(Tx). Somit it Rx und Tx gleichzeitig möglich und> nötig.
Das soweit richtig. Allerdings landet die empfangene Nachricht bei den
CAN-Controllern, die ich kenne, nicht im Empfangspuffer und kann damit
auch von keiner Software ausgewertet werden.
Wozu auch? Der Controller hat sie ja gerade erst gesendet, also wird sie
verworfen.
Oder gibt es Controller, bei denen das nicht so ist?
Nein, den kenne ich nicht. Das von Bosch vorgestellte Verfahren geht
damit aber definitiv nicht.
Das von Steffen R. verlinkte CANcrypt
> http://www.esacademy.com/blog/2016/02/26/cancrypt-...
scheint aber mit Standardhardware zu funktionieren. Das solltest du dir
vllt. mal näher angucken.
Wenn der µC in der CAN Peripherie Einheit ein "PnS" hat, dann kann
dieser die Schlüssel tauschen.
Da der Artikel recht neu ist und der AT90CAN schon zur Steinzeit
entwickelt wurde, wird dieser wohl ungeeignet sein um Schlüssel aus zu
tauschen.
Aktuell kenne ich keinen µC der "PnS" drin hat.
Aber Du kannst natürlich Port-Pins setzen/löschen und die CAN-Peripherie
selbst in Software schreiben - das geht so ziemlich mit jedem µC der
Port-Pins hat. Nachteil: Die Baudrate müsstest Du recht niedrig wählen,
zum Test sollte es dennoch reichen.
Jedenfalls: Sehr interessant was die Bosch-Leute erfunden haben!
Bisher habe ich es ja schon direkt über den Transceiver realisiert.
Dabei steuere ich direkt die Pins RXCAN und TXCAN an und übertrage dann
nur den Payload über CANH und CANL. Wenn ich es mit dem Oszilloskop
messe bekomme ich halt ein paar Spikes, da sie nicht komplett synchron
sind, aber damit ist ja auch zu rechnen.
Schade, dass es nicht auch direkt mit dem integrierten Controller geht.
Markus M. schrieb:> Jedenfalls: Sehr interessant was die Bosch-Leute erfunden haben!
Nun, so schwer wird das wohl nicht zu knacken sein.
Allein schon die Exemplar- und Quartzstreuungen machen es möglich
(natürlich mit entsprechender Hardware).
Einer wird immer langsamer sein - und wenn es nur ns sind...
Peter schrieb:> Schade, dass es nicht auch direkt mit dem integrierten Controller geht.
Deswegen entwickeln die ja ein neues Modul :)
Auf dem CAN-Bus entsteht eine Überlagerung, die unterschiedlich zu
beiden gesendeten Streams ist. Die CAN Controller müssen abhängig von
der Überlagerung Stuff-Bits und CRC berechnen. Die Überlagerung muss
schließlich ein echtes CAN-Frame bleiben.
Marc V. schrieb:> Nun, so schwer wird das wohl nicht zu knacken sein.>> Allein schon die Exemplar- und Quartzstreuungen machen es möglich> (natürlich mit entsprechender Hardware).> Einer wird immer langsamer sein - und wenn es nur ns sind...
Das geht noch viel einfacher, man kann einfach anhand des Signalpegels
mit dem Oszi erkennen, ob von einem oder von zwei Stellen getrieben
wird.
Das sieht man bei normalem CAN schön am ACK Bit, da dieses von mehreren
Stellen gesendet wird. Die Spannung ist somit höher bzw. niedriger, je
nachdem welche Leitung man betrachtet.
Marc V. schrieb:> Markus M. schrieb:>> Jedenfalls: Sehr interessant was die Bosch-Leute erfunden haben!>> Nun, so schwer wird das wohl nicht zu knacken sein.>> Allein schon die Exemplar- und Quartzstreuungen machen es möglich> (natürlich mit entsprechender Hardware).> Einer wird immer langsamer sein - und wenn es nur ns sind...
Naja, in Zeiten von CAN FD darf die Varianz nur noch gering sein. Und
bei Security auf billig-Hardware zu setzen ist auch der falsche Weg.
Und starke Verschlüsselung bei den wenigen Daten, die mit CAN übertragen
werden, ist auch schwierig. Man kann es nur etwas schwerer machen.
Mit der dargestellten Methode wird man auch keinen Schlüsseltausch
machen, sondern "nur" Daten austauschen, die vorher im Klartext über die
Leitung ging (Salt, öffentlicher Schlüssel).
Einfach nur, um einen Angriff zu erschweren.
M. H. schrieb:> Das geht noch viel einfacher, man kann einfach anhand des Signalpegels> mit dem Oszi erkennen, ob von einem oder von zwei Stellen getrieben> wird.> Das sieht man bei normalem CAN schön am ACK Bit, da dieses von mehreren> Stellen gesendet wird. Die Spannung ist somit höher bzw. niedriger, je> nachdem welche Leitung man betrachtet.
Man wird schon aufeinander abgestimmte Hardware nutzen. Ist ja Security!
Da muss man schon Aufwand und Know How reinstecken. Die
Spannungsunterschiede entstehen häufiger durch unterschiedliche
Spannungen, mit denen die Transceiver betrieben werden (3.3V, 5V). Aber
ja, durch solche Spannungsunterschiede kann man Nachrichten gut den
Sendern zuordnen, wenn es sie gibt.
Und es ist ja schon an Hand der Daten bekannt, wann einer und wann zwei
die jeweiligen Daten schicken. Unbekannt ist, wer von beiden welche
Daten schickt.
Und es ist immer einen Kosten Nutzen Abwägung. Alles ist knackbar. Ist
immer nur eine Frage des Aufwandes. (und einer cleveren Idee... Nur um
mal schlechte Zufallszahlen als einen Punkt zu nennen.)
Steffen R. schrieb:> Die Spannungsunterschiede entstehen häufiger durch unterschiedliche> Spannungen, mit denen die Transceiver betrieben werden (3.3V, 5V).
CAN-Transceiver werden mit nominell 5V betrieben, 3,3V sind da
bestenfalls als I/O Versorgung zum µC dran.
Steffen R. schrieb:> Naja, in Zeiten von CAN FD darf die Varianz nur noch gering sein. Und> bei Security auf billig-Hardware zu setzen ist auch der falsche Weg.
Selbstverständlich.
Aber Differenzen muss es ganz einfach geben, deswegen schrieb ich
auch "(natürlich mit entsprechender Hardware)".
> die jeweiligen Daten schicken. Unbekannt ist, wer von beiden welche> Daten schickt.
Mit entsprechender Hardware kann man schon rausfinden, wer A und
wer B ist. Danach ist es auch kein grosses Problem mehr zu sehen,
ob Dominant oder Recessive verspätet kommt.
> Die Spannungsunterschiede entstehen häufiger durch unterschiedliche> Spannungen, mit denen die Transceiver betrieben werden (3.3V, 5V).
Die Spannungsunterschiede entstehen eher durch Common-Mode-Versatz, also
durch unterschiedliche Massen der Geräte/Transceiver
(https://www.gemac-fieldbus.com/de/common-mode/).
M. H. hat aus meiner Sicht Recht. Das ACK-Bit hat einen niedrigeren
Pegel, weil an der Stelle mehrere Treiber auf den Bus einwirken.
Somit könnte man auch erkennen, wann beim Plug-and-Secure Verfahren in
einem CAN-Telegramm zwei Controller gleichzeitig ein dominantes Bit
senden.
Steffen R. schrieb:> Man wird schon aufeinander abgestimmte Hardware nutzen. Ist ja Security!> Da muss man schon Aufwand und Know How reinstecken.
Das PnS bietet keine Schutz vor Hardwarezugriff. Es bietet lediglich
Schutz, sollte ein angeschlossenes Gerät gehijackt werden.
Durch Hardwarezugriff mit Oszi oder einer Schaltung deiner wahl, lässt
sich der Schlüsselaustausch entschlüsseln.
Steffen R. schrieb:> Naja, in Zeiten von CAN FD darf die Varianz nur noch gering sein. Und> bei Security auf billig-Hardware zu setzen ist auch der falsche Weg.
Das PnS Modul sendet nur Frames auf klassischen Bitraten. duch die
Laufzeit auf dem Bus ist eine sichere Überlagerung von Frames mit hoher
Bitrate nicht möglich. Aus diesem Grund fängt ja jedes CAN-FD Frame
langsam an, um die Arbitrierung durchzubekommen.
Rudolph schrieb:> Steffen R. schrieb:>> Die Spannungsunterschiede entstehen häufiger durch unterschiedliche>> Spannungen, mit denen die Transceiver betrieben werden (3.3V, 5V).>> CAN-Transceiver werden mit nominell 5V betrieben, 3,3V sind da> bestenfalls als I/O Versorgung zum µC dran.
SN65HVD233 ???
Marc V. schrieb:> "(natürlich mit entsprechender Hardware)"
Ja klar. Genau dieser Aufwand soll es ja unattraktiv machen. Von
unmöglich ist hier garnicht die Rede. Wenn du ausreichend lange Zugriff
auf das Gerät hast geht alles. Und wenn du an der Hardware rumbasteln
kannst noch mehr.
Steffen R. schrieb:> Rudolph schrieb:>> Steffen R. schrieb:>>> Die Spannungsunterschiede entstehen häufiger durch unterschiedliche>>> Spannungen, mit denen die Transceiver betrieben werden (3.3V, 5V).>>>> CAN-Transceiver werden mit nominell 5V betrieben, 3,3V sind da>> bestenfalls als I/O Versorgung zum µC dran.>> SN65HVD233 ???
Ja. Dieser Transceiver arbeitet mit 3.3V. Aber es ist so, dass alle mir
bekannten CAN Transceiver, die nur mit 3.3V arbeiten, die CANH Leitung
nicht auf das notwendige Level von 3.5V bekommen. Den meisten Empfängern
ist das jedoch egal, da die differentielle Spannung zwischen CANH und
CANL ausreicht. Ich habe jedoch auch schon gehört, dass Leute Probleme
hatten, sobald sie 3.3V CAN Tranceiver und 5V CAN Transceiver an einem
Bus verwendet haben. Es kam da zu Empfangsproblemen.
M. H. schrieb:> Steffen R. schrieb:>> Rudolph schrieb:>>> Steffen R. schrieb:>>>> Die Spannungsunterschiede entstehen häufiger durch unterschiedliche>>>> Spannungen, mit denen die Transceiver betrieben werden (3.3V, 5V).>>>>>> CAN-Transceiver werden mit nominell 5V betrieben, 3,3V sind da>>> bestenfalls als I/O Versorgung zum µC dran.>>>> SN65HVD233 ???>> Ja. Dieser Transceiver arbeitet mit 3.3V. Aber es ist so, dass alle mir> bekannten CAN Transceiver, die nur mit 3.3V arbeiten, die CANH Leitung> nicht auf das notwendige Level von 3.5V bekommen. Den meisten Empfängern> ist das jedoch egal, da die differentielle Spannung zwischen CANH und> CANL ausreicht. Ich habe jedoch auch schon gehört, dass Leute Probleme> hatten, sobald sie 3.3V CAN Tranceiver und 5V CAN Transceiver an einem> Bus verwendet haben. Es kam da zu Empfangsproblemen.
Dann hatten diese Leute andere Probleme z.B. nicht standardkonforme
Empfänger oder zu viel Common Mode Voltage. ISO11898-2 spezifiziert
keinen min Wert für CANH sondern nur einem nominellen Wert von 3,5V.
Matthias
