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.
Hier eine mögliche Methode mit herkömmlichen CAN Controllern: http://www.esacademy.com/blog/2016/02/26/cancrypt-functionality/
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?
@Marcus: Gehört zu den dir bekannten Controllern auch der AT90CAN? Das würde mein Setup ja direkt für das Vorhaben ausschließen.
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.
:
Bearbeitet durch User
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. Nicht alle http://www.ti.com/product/SN65HVD234 https://www.maximintegrated.com/en/products/interface/transceivers/MAX3051.html Matthias
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.
05_CANFDSymposium_Mutter_Bosch.pdf https://vector.com/portal/medien/cmc/events/CFD17/presentations/05_CANFDSymposium_Mutter_Bosch.pdf Als Zusatz zum oben erwähnten Artikel zu sehen: Beitrag "Re: Zeitgleiches Versenden von Nachrichten mit dem AT90CAN"
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
Μαtthias W. schrieb: >> CAN-Transceiver werden mit nominell 5V betrieben, 3,3V sind da >> bestenfalls als I/O Versorgung zum µC dran. > > Nicht alle > http://www.ti.com/product/SN65HVD234 > https://www.maximintegrated.com/en/products/interface/transceivers/MAX3051.html Okay, wieder was gelernt, die gibt es bei TI sogar auch als Automotive Version. Dann bin ich mal gespannt, ob es für die Dinger auch eine Freigabe geben wird, im Moment könnte ich die Teile jedenfalls nicht einsetzen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.