Hallo liebe Leser, ich habe eine Aufgabe gestellt bekommen, mit der ich nicht klarkomme... daher brauche ich eure Hilfe! Beschreibung: Ein ARM Cortex M3 wird zu einer Motorsteuerung (Elektromotor) verwendet (Drehzahlregelung). Die Steuerung soll ein Upgrade enthalten, dass Freigeschaltet werden muss (Ergebnis des Upgrades: Motor bringt mehr Leistung). Um nicht die Steuereinheit tauschen zu müssen und um die Produktion einfach zu halten, soll die verbesserte Version der Motorsteuerung also implementiert, aber gesperrt sein. Die Freischaltung soll so erfolgen, dass man von einem PC (oder Smartphone) einen Freischaltcode an den Controller sendet (per Bluetooth oder USB, das soll vorerst mal egal sein). Die Kommunikation soll AES verschlüsselt sein. Ich hab gesucht, gelesen aber nichts wirklich brauchbares zu stande gebracht Probleme/Fragen: Wie bringe ich den Controller dazu eine AES verschlüsselte Übertragung zu machen? Wie sieht diese Übertragung dann aus? Wie verhindere ich, dass jemand durch auslesen des Speichers entweder die Verschlüsselung knackt oder auf einem anderen Weg das Upgrade freischaltet? (Codeschutz) Helft mir bitte (irgendwie) ich verzweifle daran und auch an mir selbst lese auch nochmal Seitenweise Material, also können auch links nützlich sein. Falls Fragen offen sind, fragt nur Grüße ein verzweifelter Student
>Wie bringe ich den Controller dazu eine AES verschlüsselte Übertragung >zu machen? Ein Programm schreiben, dass AES entschlüsseln kann. Evtl. gibt es Prozessoren die als Peripherieeinheit einen AES En-/Decoder haben. >Wie sieht diese Übertragung dann aus? Etwas schwierig zu beantworten. Eigentlich ganz normal. Auf welche Eigenschaft einer Übertragung bezieht sich Deine Frage? >Wie verhindere ich, dass jemand durch auslesen des Speichers entweder >die Verschlüsselung knackt oder auf einem anderen Weg das Upgrade >freischaltet? (Codeschutz) Solche eine Absicherung kann immer nur graduell sein. Absoluten Schutz gibt es nicht. Das martkübliche, gegen den Durchschnittsprogrammierer sicherste ist ein Prozessor, der sich mittels einer elektrisch zu setzenden Sicherung so einstellen lässt, dass das Programm nicht mehr auslesbar ist.
Das ich ein Programm schreiben muss das habe ich mir gedacht eine open source "ase.c" und "ase.h" habe ich ich habe nur noch nie uC programmiert :( Empfehlungen für Software bräuchte ich also auch noch. Zur Übertragung: das war wohl schlecht formuliert von mir. gemeint ist, welche Informationen ausgetauscht werden zwischen einem Host (PC oder iPhone), um eine Software die bereits auf der Steuerung sitzt, zu aktivieren kein Schutz ist perfekt, keine Frage^^ Ich frage mich nur, wenn ein Programm gegen auslesen sicher sein muss (es soll ja nicht jeder die nicht bezahlte bessere Motorsteuerung nutzen), kann ich es trotzdem "verändern" um es zu aktivieren. vielleicht ist nun mein Problem/Aufgabe etwas klarer
Moment. Nicht ganz so schnell. Die Verbindung kann abgehoert werden. Wenn man also den verschluesselten Block abfangen kann und anderswo identisch einspielen kann, darf es nicht funktionieren. Dh der verschluesselte Block muss mit Informationen aus dem Geraet verschluesselt werden, zB der Seriennummer.
Vom Prinzip her muss der M3 einen Parameter (z.B. aus Flash) abfragen, ob die normale oder die verbesserte Steuerung ausgeführt werden soll. Dieser Parameter muss über eine geeignete Steuersequenz von aussen gesetzt werden können. Wenn das mal funktioniert, muss die Steuersequenz verschlüsselt werden.
Ruediger W. schrieb: > ich habe nur noch nie uC programmiert :( > Empfehlungen für Software bräuchte ich also auch noch. Dann solltest du dich jetzt nicht mit AES beschäftigen, sondern dir die Frage stellen, wie du deine erste LED am Mikrocontroller zum Laufen bringst. Ist nicht böse gemeint, aber andersherum ist das Projekt von Beginn an zum Scheitern verurteilt. Um welchen Prozessor geht es denn überhaupt?
So weit bin ich jetzt auch StinkyWinky allerdings will ich erst einmal das mit der AES Verschlüsselung richtig hinbekommen, bevor ich mich mit dem Setzen eines Parameters beschäftige. Pico Oschi, daran habe ich bisher nicht gedacht, danke für den Hinweis. hab nachgesehen und jede Motorsteuerung verfügt über eine Seriennummer, welche im Speicher abgelegt ist. Wenn ich nun an die Zockergemeinde denke, dann ändern die eine Seriennummer eines Games und geben dann den passenden Freischaltcode ein. Ist die Seriennummer in einem "lesesicheren" (und damit schreigeschützen) Bereich, kann sie dann überhaupt genutzt werden? @ Christoph (und alle anderen) •ARM Cortex M3 (STM32F107VCT, 32Bit,72MHz, 256KB Flash, 64KB RAM) keine Ahnung wie relevant das ist es handelt sich um eine Motorsteuerung wie sie ähnlich zB in 1-Personen-Mini-Elektro-Fahrzeugen verwendet wird Trotzdem soll das so geschützt werden. Über den Sinn/Unsinn machen wir uns mal keine Gedanken. Danke schon mal für die Anregungen bisher!
>Ist die Seriennummer in einem "lesesicheren" (und damit
schreigeschützen) Bereich, kann sie dann überhaupt genutzt werden?
Es geht nicht um die Zockergemeinde. Es geht um den industriellen
Anwender, der soll Geld fuer etwas bezahlen. Wieviel kostet das Upgrade,
wieviel bringt es, und wie schwer ist es zu knacken. Ist die Aenderung
wesentlich ? Ist die Aenderung nachweisbar ? Gibt es Kunden, die 30
Stueck oder mehr aufs mal am Lager haben ? Kommt an diesen Anlagen mal
ein Servicetechniker vorbei ?
Man kann auch die Hackversuche aufzeichnen, und dann spaeter mal
basierend darauf die Garantie ablehnen, wenn man vorher darauf
hingewiesen hat.
Du willst nicht verschlüsseln, Du willst signieren. Die Signatur sollte die Seriennummer oder ein anderes eineindeutiges unveränderliches Merkmal der Motorsteuerung berücksichtigen. Thorsten
Ruediger W. schrieb: > Die Steuerung soll ein Upgrade enthalten, dass > Freigeschaltet werden muss (Ergebnis des Upgrades: Motor bringt mehr > Leistung). Wieso macht man sowas? Als Hersteller hat man doch gewisse Kosten für ein Gerät, welche man durch den Verkaufspreis decken will. Ein leistungsfähiges Gerät künstlich zu verkrüppeln und dann billiger anzubieten macht doch keinen Sinn. Die Gesamtkosten über alle Geräte müssen ja dennoch gedeckt werden. Es handelt sich also quasi um Quersubventionierung auf Kosten der Kunden die sich das teurere Gerät kaufen, was ja total daneben ist.
Schau dir mal die CryptoAuthentication Module von Atmel an. ATSHA204 dient genau dazu. Du hast Platz für 16 (private) Schlüssel. Schickst eine Challenge and den Chip, dieser generiert mit einem der integrierten Schlüsseln einen 256-Bit SHA. Dieser Output (Hash) wird vergliechen mit den vorab berechneten Hashes von der Authentifizierungsstelle - also z.b. das Gerät welches per USB angeschlossen wird. Wenn die beiden Hashes sich gleichen, hast Du Dich erfolgreich authentifiziert und kannst z.b. einen weiteren Schlüssel zur Dechiffrierung (AES) verwenden. Zusätzliche Sicherheit bringt der aus den SmartCards bekannten Metal-Shield Layer der mit dem Die verbunden ist. Damit ist auch extrem schwierig z.b. durch abschleifen des Packages an die privaten Schlüssel durch Micro-Probing zu kommen (und wenn dann nur mit sehr teuren Mitteln). Im Datenblatt und App NOtes werden verschiedene Methoden beschrieben (wie z.b. Password Protection, Firmware upgrade etc.). Wenn Du einen Chip mit HW Crypto Engine suchst, würd ich einen Xmega (128Bit AES) oder z.b. wenn es 32Bit sein sollen: AT32UC3A3256S Im Atmel Studio 5 gibt es fertige Library zur AES Anwendung wenn ich mich nicht täusche.
Johannes G. schrieb: > Wieso macht man sowas? > > Als Hersteller hat man doch gewisse Kosten für ein Gerät, welche man > durch den Verkaufspreis decken will. Ein leistungsfähiges Gerät > künstlich zu verkrüppeln und dann billiger anzubieten macht doch keinen > Sinn. Die Gesamtkosten über alle Geräte müssen ja dennoch gedeckt > werden. Es handelt sich also quasi um Quersubventionierung auf Kosten > der Kunden die sich das teurere Gerät kaufen, was ja total daneben ist. machen doch die Chiphersteller genauso ;-) der Die ist z.b. mit 256KB Flash ausgestattet oder mit CAN und Ethernet und daraus aus demselben Chip macht man eine Variante mit CAN, eine mit CAN + Ethernet, eine mit 128KB Flash statt 256 ... meistens rentiert es sich nicht für jede Variante einen eigenen Prozess zu starten
Pico so war eben mein Gedankengang und der war nicht richtig genaue Daten, wie die Veränderung aussieht habe ich nicht. Vielleicht lässt es sich mit Tuning bei normalen Autos vergleichen. Nur hier muss nichts umgebaut werden sondern nur freigeschaltet. Preis ist mir nicht bekannt. Ein Kunde hat normal nur ein Gerät. Ihm soll ermöglicht werden auch irgendwann nach dem Kauf des Gefährts das Upgrade durchzuführen. Thorsten, die Person, die die Arbeit nachher haben will, ist aber scharf auf eine AES Verschlüsselung... wenn du (oder andere) mir ein schlüssiges Konzept mit Signatur erklärt, dann könnte ich versuchen den Auftraggeber umzustimmen. Johannes gehen wir einfach mal davon aus, dass der Quellcode für beide Versionen bis auf Zahlenwerte zur Bestimmung der Motorleistung identisch ist. Also ein minimaler Mehraufwand (Hardware ist die gleiche, das ist sicher) Danke Sven, leider ist das nicht hilfreich in meinem Fall. Denn die Hardware der Steuerung ist gegeben.
Ein STM32F4xx kann das In Hardware.. z.B. mit dem STM32F4DISCOVERY - Board (15-20 Euro) das ist auch für Studenten erschwinglich.... Eine Übersicht aller Software - Module und aller Codebeispiele findest du hier: http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&SubClassID=1376 Titel STM8 and STM32 Emebedded Software Solutions Die Lib mit codebeispielen findest du in diesem Beispiele-Pool: http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&FamilyID=141 Filename: stm32f4_dsp_stdperiph_lib.zip Gruß Thilo
Überlegt euch erstmal ein gutes Konzept - "scharfsein auf AES" ist keins. Ich gebe dem Thorsten recht. Überleg Dir wie der Freischaltvorgang genau erfolgen soll. Eine AES-Verschlüsselung des gesamten Datenverkehrs muss gar nicht notwendig sein. Dann müsste es eine Datenbank geben, in der unter der Seriennummer des Motors der geheime Schlüssel abgelegt wird, der auch im Controller steht. Damit kann dann der Freischaltcode verschlüsselt werden, an die Steuerung gesendet und dort entschlüsselt werden.
Ruediger W. schrieb: > Johannes gehen wir einfach mal davon aus, dass der Quellcode für beide > Versionen bis auf Zahlenwerte zur Bestimmung der Motorleistung identisch > ist. Also ein minimaler Mehraufwand (Hardware ist die gleiche, das ist > sicher) Davon rede ich ja. Du beantwortest meine Frage damit überhaupt nicht. Welche Existenzberechtigung hat die "verkrüppelte" Version?
Vielen Dank Thilo muss ich erstmal durcharbeiten, hört sich aber vielversprechend an was die Signatur angeht, die lässt sich doch fälschen und so die Freischaltung ermöglichen oder irre ich mich, bzw wie wird das verhindert? Existenzberechtigung: verkrüppelte Version fährt mit max 30km/h bessere mit 50km/h (Zahlen sind jetzt mal ausgedacht) um mit dem kleinen e-car zum Einkaufen zu fahren reichen Oma und Hausfrau die 30km/h Nun entscheidet sich der Mann im Haus ein halbes Jahr nach dem Kauf, dass er ab jetzt das Gefährt nutzen will um zur Arbeit zu fahren. Ihm sind die 30km/h zu langsam. Also investiert er jetzt nochmal Geld für das Upgrade. (oder die Familie hatte beim Kauf einfach nicht genug) für die Krüppel version reicht der Führerschein den man mit 15 macht, die normale, da braucht man den fürs Auto (könnte doch sein) oder man braucht für die schnelle Version ein Nummernschild oder andere Steuern... irgendwas bürokratisches halt reicht das für euch als Existenzberechtigung? (wenn nicht, dann sorry, aber so ist die Sachlage eben) Ich hab die Entscheidung, dass es 2 Versionen geben soll nicht getroffen. Ich bin nur ein Student, der als Studienarbeit diese Aufgabe erfüllen soll. Daher hab ich mir über den Sinn dahinter einfach keine Gedanken gemacht
Ruediger W. schrieb: > reicht das für euch als Existenzberechtigung? (wenn nicht, dann sorry, > aber so ist die Sachlage eben) Ist ok, du musst mir ja nicht "Red und Antwort stehen". Ich dachte nur ich frag mal, wenn hier schon jemand in so ein Projekt involviert ist. Allerdings ist genau das eben keine Existenzberechtigung. Wenn ein Hersteller ein Fahrzeug baut das 50 km/h fahren kann, soll er es auch so verkaufen und den Preis so gestalten, dass seine Kosten gedeckt sind. Wenn ein Kunde dieses Fahrzeug haben will, aber nur mit 30 km/h fahren will (z.B. aus rechtlichen Gründen), kann man ihm die Möglichkeit geben, eine Begrenzung einzustellen, die er aber auch jederzeit wieder rausnehmen kann. Wenn der Hersteller (oder ein Konkurrent) ein Fahrzeug mit billigeren Mitteln bauen kann, das nur 30 km/h fährt, kann er das auch billiger anbieten. Oder vom Nutzer her gesehen: ich zahle doch das was ich bekomme, nicht das was ich nutze. Sonst könnte ich ja zum nächsten BMW Händler gehen und sagen dass ich den M3 nur alleine oder zu zweit fahren werde und deshalb für die hinteren Sitze nichts zahle, ausserdem wohne ich in der Schweiz, wo wir 120 km/h Höchstgeschwindigkeit auf der Autobahn haben und deshalb zahle ich auch nicht für die volle Leistung des Motors.
Johannes G. schrieb: > Als Hersteller hat man doch gewisse Kosten für ein Gerät, welche man > durch den Verkaufspreis decken will. Ein leistungsfähiges Gerät > künstlich zu verkrüppeln und dann billiger anzubieten macht doch keinen > Sinn. Die Gesamtkosten über alle Geräte müssen ja dennoch gedeckt > werden. Es handelt sich also quasi um Quersubventionierung auf Kosten > der Kunden die sich das teurere Gerät kaufen, was ja total daneben ist. Du bietest dem Kunden ein Gerät mit geringerer Leistung zum günstigeren Preis an, die Leistung ist aber für ihn mehr als ausreichend. Nun merkt der Kunde irgendwann, dass es schön wäre etwas mehr Leistung zu haben. Also erwirbt er bei dir das Upgrade und ohne aufwändige Installationsarbeiten o.ä. wird ihm anschließend die höhere Leistung freigeschaltet. Für beide Seiten ist das günstiger, der Hersteller muss nur ein Gerät produzieren und der Kunde bezahlt zunächst nur die Leistung, die er wirklich benötigt, kann jedoch im Falle eines Upgrades das bestehende Produkt direkt weiter nutzen ohne irgendwelche Produktionsausfälle befürchten zu müssen. Zum Thema: Man kann die Lösung eigentlich beliebig kompliziert aufbauen. Einfache Variante: Code ist fest im Gerät hinterlegt und wird einfach AES-verschlüsselt an das Gerät gesendet. Bei Übereinstimmung erfolgt die Freischaltung. Komplexere Variante: Code ist "variabel" und wird aus Geräteeigenschaften wie z.B. der Seriennummer usw. generiert. Diese wird (verschlüsselt) ausgelesen, daraus der Code generiert und (verschlüsselt) ans Gerät gesendet. Das Gerät prüft anschließend, ob der Code auch wirklich zu seiner Seriennummer passt. "Premium"-Variante: Zunächst authentifiziert man sich gegenüber dem Gerät mittels eines Zertifikats und handelt darüber einen AES-Schlüssel aus. Mit diesem wird anschließend die Kommunikation abgewickelt so wie in der kompleren Variante. Nun zum Thema Replay-Angriff: Diese lassen sich mittels der zweiten Variante abwehren indem z.B. ein interner Counter in die Generierung des Codes mit einfließt welcher nur für die aktuelle Kommunikation gültig ist. Bei einem Replay-Angriff würde der gesendete Code dann nicht mehr stimmen da sich in der Zwischenzeit der interne Counter geändert hat. Beispiel: Code = AES(Counter|Serial) => AES(0|Serial) != AES(1|Serial) Den Counter könnte man seinerseits auch wieder gegen Manipulation absichern indem Message Authentication Codes verwendet usw.. Man hat also eine gewaltige Bandbreite an Möglichkeiten, für den Anfang würde ich mit der ersten Variante anfangen und mich dann langsam vorarbeiten.
Johannes ich verstehe deine Einwände und dein Beispiel ist super hätten mein Auftraggeber und ich nicht so ein super hust Verhältnis, würde ich ihm das wohl genauso weitersagen allerdings hat Daniel eine (fast) perfekte Antwort geliefert! zu den Varianten die 2. reicht vollkommen aus für meine Arbeit jetzt muss ich mit dem Material umgehen lernen und das umsetzen werden arbeitsintensive Tage wenn mir noch jemand eine "Entwicklungsumgebung" empfehlen könnte :) Keil uVision oder was anderes? von meiner Seite wars das vorerst bei neuen Problemen melde ich mich werde euch auf dem laufenden halten, wie das Projekt vorranschreitet vielen vielen Dank
Wenn es denn unbedingt AES sein muss, würde ich folgendermaßen vorgehen. Voraussetzung ist eine eineindeutige (durch den Kunden) unveränderbare Seriennummer in den Steuergeräten. Dann baut man sich ein Datenpaket aus Seriennummer, Freischaltkommando und Prüfsumme (CRC o.ä.) über Seriennummer und Freischaltcode und verschlüsselt das alles mit dem geheimen AES-Key und schickt die verschlüsselten Daten zum Kunden. Der spielt die verschlüsselten Daten via USB/Bluetooth etc. auf das Steuergerät. Das Steuergerät entschlüsslt die Daten mit dem dort ebenfalls hinterlegten geheimen AES-Key, prüft die Seriennummer gegen seine eigene und die Prüfsumme (CRC) auf Übereinstimmung und führt dann das Freischaltkommando aus. Will man das alles noch sicherer machen ersetzt man AES durch ein asymmetrisches Verschlüsselungsverfahren (z.B. RSA) und speichert im Steuergerät nur den öffentlichen Schlüssel. So kann der geheime Schlüssel zum Verschlüsseln der Daten selbst dann nicht geklaut werden, wenn das Steuergerät ausgelesen werden kann. Thorsten
Ich habe leider eine Korrekur zu machen: >>> Ein STM32F4xx kann das In Hardware.. >>> z.B. mit dem STM32F4DISCOVERY - Board (15-20 Euro) >>> das ist auch für Studenten erschwinglich.... in den entsprechenden Beispielen zum Thema "Crypto" fand ich folgende Sätze: ---------- snip ------------- This example runs only on STM32F41x Devices (Cryptographic acceleration not embedded in STM32F40x Devices). This example has been tested with STM324xG-EVAL RevB and can be easily tailored to any other development board. ---------- snap -------------- somit fällt das STM32F4Discovery flach, da es "nur" einen STM32F407 hat... Man benötigt einen STM32F417 oder STM32F415... Gruß Thilo
Daniel H. schrieb: > Du bietest dem Kunden ein Gerät mit geringerer Leistung zum günstigeren > Preis an, die Leistung ist aber für ihn mehr als ausreichend. Nun merkt > der Kunde irgendwann, dass es schön wäre etwas mehr Leistung zu haben. > Also erwirbt er bei dir das Upgrade und ohne aufwändige > Installationsarbeiten o.ä. wird ihm anschließend die höhere Leistung > freigeschaltet. Für beide Seiten ist das günstiger, der Hersteller muss > nur ein Gerät produzieren und der Kunde bezahlt zunächst nur die > Leistung, die er wirklich benötigt, kann jedoch im Falle eines Upgrades > das bestehende Produkt direkt weiter nutzen ohne irgendwelche > Produktionsausfälle befürchten zu müssen. Ruediger W. schrieb: > allerdings hat Daniel eine (fast) perfekte Antwort geliefert! Da bin ich anderer Meinung. Das beschreibt zwar ein "schönes" Szenario, geht aber überhaupt nicht auf Tatsachen ein. Wie funktioniert denn die Preisgestaltung? Der Hersteller hat ja den exakt selben Produktionsaufwand für Gerät A (top) und Gerät B (eingeschränkte Variante). Wenn ich als Kunde jetzt nicht so hohe Ansprüche habe, kaufe ich mir das günstige B. Weil es eben günstig ist, aber der Hersteller doch hohe Produktionskosten hatte, verdient er (fast) nichts daran. Damit er trotzdem Gewinn macht, schlägt er einfach eine saftige Marge auf Gerät A. Weil aber von A viel weniger verkauft werden als von B, muss die Marge deutlich höher sein als bloss der "fehlende" Gewinn von einem verkauften B. Aber das funktioniert erstmal, weil A-Käufer Wert auf top Leistung legen und nicht so preisbewusst sind. Wenn jetzt aber Konkurrenzfirma X kommt und die Billigsparte ins Visier nimmt, kann sie mit entsprechend weniger Aufwand ein Gerät B bauen. Das können sie zum selben billigen Preis verkaufen wie der erste Hersteller, aber sie machen dabei einen Gewinn, weil sie nicht so hohe Kosten hatten. Dann kommt noch Konkurrenzfirma Y und will in die High-End-Sparte. Also baut sie ein A-Produkt. Weil sie aber nicht so eine hohe Marge draufschlagen muss, ist ihr A bei gleicher Leistung deutlich billiger zu haben als das von der ersten Firma (oder sie bauen ein A+ Gerät zum selben Preis). In beiden Fällen sieht der erste Hersteller alt aus. Sowas kann meiner Meinung nach nur (temporär) funktionieren, weil die A-Käufer sich über den Tisch ziehen lassen. Um auf das Beispiel von Daniel zurückzukommen: Der Kunde zahlt in dem Fall eine zusätzliche "Gebühr" für seine Option, später zu entscheiden. Will er dann nämlich Gerät A (freigeschaltet), muss er den überteuerten Preis zahlen. Umsteigen auf Gerät A eines Konkurrenzherstellers ist dann auch nicht mehr billiger, weil er schon Gerät B hat und nur noch die Differenz zahlen muss. Hätte er sich von Anfang an für ein Gerät A entschieden, hätte er es günstiger bei Firma Y gekauft. So, genug Vortrag. Ich hoffe das stimmt etwa so. Ein Beispiel (unter vielen) für so einen Hersteller ist übrigens Rigol mit ihrem DS1052E Oszilloskop, das sich mittlerweile viele Besitzer selber von 50 MHz auf 100 MHz umprogrammiert haben.
Johannes G. schrieb: > Der Kunde zahlt in dem Fall eine zusätzliche "Gebühr" für seine Option, > später zu entscheiden. Will er dann nämlich Gerät A (freigeschaltet), > muss er den überteuerten Preis zahlen. Jaja, Geld verdienen ist böse, besser wäre es doch, die Firmen würden alles verschenken. Dass die Entwicklung der "High-End"-Version auch Geld kostet, ist hier noch niemandem gekommen, oder? Und wenn eine Firma irgendwo Geld verdienen kann, das dann wieder in die Entwicklung neuer Produkte fließt (und Ingenieure beschäftigt), ist das dann auch noch böse? Egal, erst mal zur Sache: am sinnvollsten ist ein Challenge-Response-Verfahren. Sprich: der µC hat intern einen Wert (Seriennummer, Zufallswert oder Kombination aus beiden). Diesen Wert ("Challenge") schickt er dann an das Freischaltprogramm. Parallel dazu rechnet er daraus über ein geeignetes kryptographisches Verfahren die zu erwartende Antwort ("Response") aus. Falls du nur die Seriennummer verwendest, kannst du den Wert auch gleich fest einprogrammieren. Das Freischaltprogramm rechnet aus der Challenge ebenfalls die korrekte Response aus. Diese wird dann zurück an den µC übertragen. Dieser vergleicht dann die selbst berechnete Sollantwort und die erhaltene miteinander. Wenn´s stimmt -> Freischaltung. Wenn nicht, dann eben nicht. Das Programm zur Berechnung der Response sollte allerdings auf einem Rechner beim Herstellers laufen. Sonst kursieren irgendwann die Knackanleitungen im Netz, wenn das Programm herausgegeben wird. HW-Unterstützung für AES im µC erscheint mir völlig übertrieben, das Fahrzeug muss die Berechnung in seinem Fahrzeugleben ja genau einmal machen. Gruß, Max
Johannes G. schrieb: > Da bin ich anderer Meinung. Das beschreibt zwar ein "schönes" Szenario, > geht aber überhaupt nicht auf Tatsachen ein. Wie funktioniert denn die > Preisgestaltung? Verzeihung, aber welche Tatsachen? Du setzt z.B. wieder voraus, dass die Kosten für die Einrichtung getrennter Fertigungen für High- und Low-End keine oder nur vernachlässigbare Kosten entstehen. Und du gehst davon aus dass es genügend gleichwertige Konkurrenz gibt und der Kunde zwischen den Anbietern wechseln kann wie er will, was spätestens dann nicht mehr funktioniert wenn wir z.B. von großen Industrieanlagen sprechen bei welchen kein Produktionsausfall auftreten darf. Im Endeffekt haben wir hier keine Tatsachen da es sich um ein (richtig erkannt) fiktives Szenario handelt zu dem uns der Markt und die Konkurrenzsituation nicht bekannt ist. Wenn man strikt nach dem geht was du schreibst dürfte es freizuschaltende Features überhaupt gar nicht geben weil sie sich für den Anbieter gar nicht lohnen.
Daniel H. schrieb: > Du setzt z.B. wieder voraus, dass die > Kosten für die Einrichtung getrennter Fertigungen für High- und Low-End > keine oder nur vernachlässigbare Kosten entstehen. Ich bin nicht ganz sicher was du damit meinst. Was ich sagen will ist dass es gar keinen Grund geben sollte ein Low-End Gerät zu bauen, wenn man es nicht billiger bauen kann. Dann bietet man eben nur High-End Geräte an. Daniel H. schrieb: > Und du gehst davon > aus dass es genügend gleichwertige Konkurrenz gibt und der Kunde > zwischen den Anbietern wechseln kann wie er will, Da hast du recht. Ich hab so eine Art absolute Konkurrenz angenommen die es so idealisiert nie gibt. Deshalb wird es auch nie ideal funktionieren. Das Prinzip gilt aber trotzdem in einer (relativ freien) Marktwirtschaft. Daniel H. schrieb: > Wenn man strikt nach dem geht was du schreibst dürfte es > freizuschaltende Features überhaupt gar nicht geben weil sie sich für > den Anbieter gar nicht lohnen. So würde ich mir das auch wünschen. Ich versuche ja gerade zu verstehen weshalb es das trotzdem gibt. Wenn das jemand aufklären kann wäre ich froh.
Ich kann aus eigener Erfahrung sagen, dass unterschiedliche Varianten durchaus Sinn machen und im Bereich von Software das schon seit Jahren üblich. Die Entwicklungs- und Wartungskosten für den Funktionsumfang des Top-Produkt fallen ohnehin an und würde man nur dieses vertreiben, würde man potentielle Kunden, die nicht den vollen Funktionsumfang benötigen an die Konkurrenz verlieren, die ein vergleichbares Produkt mit zwar weniger Funktionen als das eigene Top-Produkt anbieten, aber zu einem günstigeren Preis. Das abgespeckte Produkt bringt einem also zusätzliche Kunden ein und auch wenn dort die Margen vielleicht kleiner sind, verteilen sich die Entwicklungs- und Wartungskosten trotzdem noch auf mehrere Schultern, als wenn man nur das Top-Produkt vermakten würde. Dabei profitieren sowohl die Nutzer des Top-Produktes, als auch die Nutzer des abgespreckten Produktes. Die Entwicklungs- und Wartungskosten des Funktionsumfangs der abgespeckten Variante wird so von beiden Nutergruppen getragen, der die Kosten für den zusätzlichen Funktionsumfang nur von den Nutzern des Top-Produktes. Thorsten
Danke Thorsten. Ok es handelt sich also um Marktabschöpfung. Ich muss sagen bei Software find ich es nicht tragisch. Da verkauft man ja eh nur Lizenzen für die Nutzung. Software kopiert sich ja ohne wirklich Resourcen zu verbrauchen. Aber wenn Hardwareprodukte eben künstlich verkrüppelt werden, das find ich einfach pervers. Eigentlich sollte man ja keinen Unterschied machen zwischen Hard- und Software in diesem Fall, weil es das selbe Prinzip ist, aber mir ist es zuwider.
Johannes G. schrieb: > Ich muss sagen bei Software > find ich es nicht tragisch. Da verkauft man ja eh nur Lizenzen für die > Nutzung. Software kopiert sich ja ohne wirklich Resourcen zu > verbrauchen. Aber wenn Hardwareprodukte eben künstlich verkrüppelt > werden, das find ich einfach pervers. Eigentlich sollte man ja keinen > Unterschied machen zwischen Hard- und Software in diesem Fall, weil es > das selbe Prinzip ist, aber mir ist es zuwider. Johannes G. schrieb: > Sonst könnte ich ja zum nächsten BMW Händler gehen > und sagen dass ich den M3 nur alleine oder zu zweit fahren werde und > deshalb für die hinteren Sitze nichts zahle, ausserdem wohne ich in der > Schweiz, wo wir 120 km/h Höchstgeschwindigkeit auf der Autobahn haben > und deshalb zahle ich auch nicht für die volle Leistung des Motors. Auch bei BMW ist es schon soweit.z.B.: der 116d 118d und der 120d haben den gleichen Motor, aber nicht die gleiche Leistung und auch nicht den gleichen Preis. sind dir 200 km/h genug nimmst du den günstigeren 116d und wenn es mal zuwenig wird macht dir ein Chiptuner" gerne einen 120d draus.
Mach's wie Millionenfach bewährt und nehme eine Smartcard mit entsprechender Applikation. Dort kannst du entsprechende Schlüssel hinterlegen, mit der ein Bootloader zur Laufzeit entweder das Standardprogramm entschlüsselt oder dein Erweitertes. Um den Schlüssel auszutauschen bedienst du dich Diffie Hellman und stellst einen sicheren Kanal zwischen der Karte selbst (also ohne deine evtl kompromitierte Hardware) und der freischaltenden Software her. Nun kannst du das erweiterte Image auf jedem System mit einem anderen Schlüssel hinterlegen und kannst es fest mit der Smartcard verbinden. Kann die Karte kopiert werden hast du natürlich weiterhin ein Problem. Dagegen sind entsprechende Karten allerdings ausgelegt und es ist ihr Hauptzweck.
Bei den angesprochenen ICs kann es aber sehr wohl sein dass die 128KB Variante zwar ein 256KB Die hat, aber in der oberen Hälfte des Speichers DEFEKT ist. Keine ungewöhnliche Praxis. ... Bei einem Motor kann ich es sogar nachvollziehen dass sich ein Hersteller die softwaremäßig freigeschaltete Mehrleistung bezahlen lässt, solang dieser irgendeine Gewährleistung/Garantie/Wartungsvertrag für die Maschine trägt. Höhere Motorleistung kann höheren Verschleiss bedeuten, und damit höhere Wartungskosten!
Ich verstehe nicht, wozu man hier eine verschlüsselte Übertragung benötigt... Es soll nur eine Aktion hiermit ausgeführt werden: Update auf mehr Leistung - oder? Die Freischaltung muß beim Hersteller gekauft werden. Also wandere ich mit meiner Seriennummer zum Hersteller und bekomme von diesem einen Freischaltcode. Diesen schiebe ich irgendwie in das Gerät. Das Gerät vergleicht den Code mit seinem Ergebnis und schaltet bei Übereinstimmung frei. Möglich wäre z.B. Code = md5sum(SN + Secret) Alternativ könnte man den Code auch schon neben der SN im Gerät speichern. Oder habe ich irgendetwas übersehen? Gruß Jobst
Jobst M. schrieb: > Oder habe ich irgendetwas übersehen? Jepp. Der TE geht davon aus, dass der Speicher ausgelesen werden kann. Damit fällt ein permanentes Update schon raus.
max schrieb: > Jobst M. schrieb: >> Oder habe ich irgendetwas übersehen? > > Jepp. Der TE geht davon aus, dass der Speicher ausgelesen werden kann. > Damit fällt ein permanentes Update schon raus. Da der TE auch meinte, daß die 'Pro-Steuerung' nur mit anderen Parametern betrieben wird, würde ich die Parameter austauschen. Grundsätzlich jedoch bei meiner Vorgehensweise bleiben. Denn eine verschlüsselte Übertragung nützt nichts. Die Daten müssen verschlüsselt bzw. signiert abgelegt werden. Also: Mit Geld + Seriennummer bekommt man eine Zahlenkolone vom Hersteller. Diese übergibt man dem Fahrzeug und sie wird so z.B. im EEPROM des Controllers abgelegt. Bei jedem Start wird die Zahlenkolonne dekodiert und auf Gültigkeit geprüft. Sind die Daten gültig, werden die Defaultparameter im RAM mit den neuen Parametern überschrieben. Die Zahlenkolone darf sich zwar mit dem im ROM befindlichen Code decodieren lassen, jedoch nicht erzeugen lassen. Also Diffie-Hellman-Schlüsselaustausch. Public-Key im ROM. AES für die Daten muss da nicht sein. Bzw. die Daten können sogar im Klartext übertragen werden. Nur die Prüfsumme dieser muß sich mit dem Schlüssel in Verbindung bringen lassen. Denn die Daten hat ein potenzieller Angreifer sowieso. Sein Problem ist vor allem, einem anderen Fahrzeug diese Daten unterschieben zu können. Aber egal wie der TO das Problem löst, wird es nicht lange dauern, bis das System geknackt ist - sofern es genug Interesse daran gibt. 1. Ansatz: Den Schlüssel knacken. 2. Ansatz: Neuen Programmcode in den Controller schreiben. Defaultparameter = Pro-Parameter. Der Controller ist bekannt und dokumentiert. Die Pro-Parameter hat man, wenn man Zahlencode und Programmcode hat. Gruß Jobst
Johannes G. schrieb: > Danke Thorsten. > Ok es handelt sich also um Marktabschöpfung. Bei Fahrzeugen ist das ganze ja auch eine Frage der Fahrerlaubnis, und da macht das dann wieder Sinn. Bei motorisierten Zweirädern ist das ja normal, da gibts die Vollversioen für Leute mit Klasse 1, die 50'er für Klasse 3 Fahrer und die auf 25 km/h gedrosselten Gefährte für den Nachwuchs. Ohne Begrenzung dürfte der Senior ohne Führerschein gar kein Elektromobil fahren. Also wirds auf 6km/h begrenzt, damit auch der noch mobil ist. Und solche zulassungsrechtlichen Begrenzungen müssen halt sicher sein, damit nicht das gleiche passiert wie bei den Mofas, wo jeder zweite Idi seine Gurke auf 60 km/h getunt hat, wo Bremsen und Fahrwerk nur bis 30 ausgelegt sind. fchk
Jobst M. schrieb: > Aber egal wie der TO das Problem löst, wird es nicht lange dauern, bis > das System geknackt ist - sofern es genug Interesse daran gibt. Glaube ich nicht, wenn es gescheit umgesetzt wird. 1. Controller gegen Re-Programmierung schützen (Fuses) 2. Starke, symmetrisch verschlüsselte Kommunikation (AES) wobei der Schlüssel mittels Public-Key-Zertifikaten (X.509) ausgehandelt wird 3. Speicherung der Parameters z.B. im internen EEPROM Lässt man Side-Channel-Angriffe außen vor bliebe damit nur ein Angriff gegen das Zertifikat übrig. Dass ein erfolgreicher Angriff trivial wäre möchte ich dann doch bezweifeln ;)
Wegen Seriennummer: Der STM32Fxxx hat eine 96 Bit Seriennummer fest im Chip eingebrannt, damit hättest Du eine Weltweit eindeutige Nummer. Der STM32F217 / F417 hat eine AES Einheit mit drin. Der STM32F4xx hat ein OTP Speicherbereich, den Du einmal programmieren kannst, wenn du eine eigene Seriennummer oder andere Produktionsdaten ablegen willst. (Ob das der STM32F2xx auch hat musst du im Datenblatt nachlesen)
Ich melde mich nun auch nochmal. Der AES Ansatz ist Schrott. Denn AES ist ein Block chiffre, dh ein symmetrischer Chiffre. Der 256bit Schluessel wird ueblicherweise per asymmetrischem chiffre uebertragen, zB einem 1024Bit Diffie Hellman. Und der Datentransfer geschieht nachher per AES, in Bloecken, fuer ein paar Konfigurationsbits totaler Overkill. Ich wuerd mir den Aufwand sparen und das Ganze per LFSR verschluesseln. Dabei davon ausgehen, dass irgend ein Kunde vielleicht 30 Stueck analysieren und korrelieren kann.
Daniel H. schrieb: > 1. Controller gegen Re-Programmierung schützen (Fuses) Neuen Controller nehmen. Ist ja kein ASIC > 2. Starke, symmetrisch verschlüsselte Kommunikation (AES) wobei der > Schlüssel mittels Public-Key-Zertifikaten (X.509) ausgehandelt wird Die Kommunikation ist überhaupt kein Problem! Da der Angreifer sowieso zumindest Lesezugriff auf den Controller hat, hat er auch die entschlüsselten Daten! Es geht darum, sicherzustellen, daß er die Daten aus einer vertrauenswürdigen Quelle bekommt. Also geht es um Signatur! > 3. Speicherung der Parameters z.B. im internen EEPROM Möchte der TO nicht. Gruß Jobst
Pico Oschi schrieb: > Ich wuerd mir den Aufwand sparen und das Ganze per LFSR > verschluesseln. Würde 0 Punkte geben weil die Aufgabenstellung AES verlangt ;) Ich würde AES in dem Fall auch nicht als Schrott bezeichnen, es kommt auf den jeweiligen Anwendungsfall und die gewünschte Sicherheit an. Jobst M. schrieb: > Neuen Controller nehmen. Ist ja kein ASIC Setzt aber voraus dass man den neuen Controller auch entsprechend programmieren kann, d.h. der Quellcode muss vorliegen bzw. ausgelesen werden können. Jobst M. schrieb: > Die Kommunikation ist überhaupt kein Problem! Da der Angreifer sowieso > zumindest Lesezugriff auf den Controller hat, hat er auch die > entschlüsselten Daten! > Es geht darum, sicherzustellen, daß er die Daten aus einer > vertrauenswürdigen Quelle bekommt. Also geht es um Signatur! Korrekt, danke. Jobst M. schrieb: > Möchte der TO nicht. Hm, den Einwand habe ich wohl überlesen, ok. Ruediger W. schrieb: > was die Signatur angeht, die lässt sich doch fälschen und so die > Freischaltung ermöglichen oder irre ich mich, bzw wie wird das > verhindert? Nicht wenn du digitale Signaturen wie z.B. nach X.509 verwendest.
Die Signatur reicht nicht. Es ist ein Leichtes die Signaturprüfungen auszuhebeln ohne die Signatur nachzuahmen. Das ist das kleine 1x1. Manchmal sogar dann, wenn man nicht einmal Lesezugriff auf den (Maschinen-)Code hat. Beispiel hier sind Boot-Signaturen von XBox und PS3, die sich per spurious brownout/reset wunderbar umgehen lassen. Der Aufwand für diese Art Attacken ist nicht besonders groß. Sich dagegen zu schützen jedoch sehr und meist nicht in der Hand des Programmierers. Es ist inhärent unsicher, da Bob == Mallory.
Bei der PS3 ist Sony selber schuld da sie für alle digitale Signaturen die gleiche Zufallszahl verwendet haben. Bei der Xbox scheint es sich um einen Bug der CPU zu handeln, welcher zudem etwas mehr Aufwand in Form von Lötarbeiten usw. benötigt. In beiden Fällen sind nicht die Signaturen die Schwäche sondern die Umsetzung bzw. Bugs. Das bedeutet aber nicht, dass sich digitale Signaturen generell leicht brechen lassen. Was ich meine ist, dass der Controller beim Aufbau/während des Bestehens der Verbindung den Kommunikationspartner authentifizieren kann. Schlägt dies fehl so wird die Kommunikation verweigert. Sofern bei der Generierung der Signaturen alles richtig gemacht wurde (größtmögliche Schlüssellänge, "echte" Zufallszahlen usw.) halte ich das für ziemlich sicher. Dass das allein nicht vor Side-Channel-Angriffen, wie eben z.B. bei der Xbox, schützt ist klar, aber das darum scheint es bei der ursprünglichen Aufgabenstellung auch gar nicht zu gehen.
Daniel H. schrieb: > In beiden Fällen sind nicht die > Signaturen die Schwäche sondern die Umsetzung bzw. Bugs. Das bedeutet > aber nicht, dass sich digitale Signaturen generell leicht brechen > lassen. Nein, aber dass es unzählige Möglichkeiten gibt sie zu Umgehen. Und diese sind nicht aufwendig. In der Zielhardware reduziert sich die Signatur an irgend einer Stelle auf ein einzelnes conditional Junmp. Eine Hardware, die nicht in deiner Kontrolle bei einer Signaturprüfung zu vertrauen führt die Signatur ad absurdum. > Was ich meine ist, dass der Controller beim Aufbau/während des Bestehens > der Verbindung den Kommunikationspartner authentifizieren kann. Das kann sie aber leider so nicht. Das wäre schön.
> Eine Hardware, die nicht in deiner Kontrolle bei einer Signaturprüfung > zu vertrauen führt die Signatur ad absurdum. Du kannst eine Checksumme mit im Flash ablegen, die dann vom Bootloader geprüft wird. Wenn geflashtes Image und Checksumme nicht zusammenpassen, verweigert der Bootloader die Arbeit. Wichtig ist dabei, dass der Bootloader nicht überschreibbar ist und nicht übergangen werden kann. Auslesbar ist weniger tragisch, der Public Key zur Signatur kann ja ruhig öffentlich sein. Verriegelbares Flash gibt es, ich meine mindestens von Infineon. Klar kann man auch das irgendwie knacken, mit einem FIB-Schnitt geht viel. Das wird aber dann sicher deutlich teurer als der Freischaltcode. Letztlich kann man ein Knacken nie ganz verhindern, sondern nur den Aufwand so hoch treiben, dass es sich nicht mehr lohnt. Max
Du brauchst nichtmal sowas. In den meisten Locks reicht ein Full-Erase. Dann kannst ihn wieder schön beschrieben. Sollte das nicht reichen setzt man einen frischen uC ein und setzt dort den lock eben nicht. Nach Prämisse ist das Auslesen möglich. Somit auch das Kopieren ... Es hängt in der chain of trust ein offenes Ende unverankert in der Gegend rum. Alles was diesen Umstand für die kryptographischen Wurzeln nicht behebt ist Gefrickel. Sorry.
Hallo! Noch eine Idee: EFM32 mit AES und PW protection im FLash: http://www.energymicro.com/products/ Natürlich bietet dies "Basic Security". Nach oben hin gibt es keine Grenzen ... Es gibt de facto keine Sicherheit bei IT-Systemen, sondern nur die Berechung wieviel Zeit und Aufwand jemand spendieren möchte, um einen wirtschaftlichen Vorteil aus dem Ideenklau zu erhalten. Hat Dein Professor die Aufgabe vollständig gestellt (welchem Angriff soll Dein System standhalten)? Sonst wird es schnell philosophisch ... Viel Erfolg und gute Noten wünscht TK
Bei der Suche nach Mustern vom STM32F4x7 bin ich auf die ..F417 gestoßen, die bei einem Anbieter billiger sind als die ..F407 obwohl dort eine AES-Einheit eingebaut ist. Also habe ich diese bestellt. Aus USA bekomme ich diese aber nur, wenn ich irgendwelche Erklärungen unterschreibe und vermutlich den Verbleib jedes einzelnen Stückes sorgfältig dokumentiere. Null Bock! Das noch zum Thema, wenn man unbedingt AES haben möchte. Vielleicht weiß ja jemand Genaueres dazu.
Willi schrieb: > Aus USA bekomme ich diese aber nur, wenn ich irgendwelche Erklärungen > unterschreibe und vermutlich den Verbleib jedes einzelnen Stückes > sorgfältig dokumentiere. Null Bock! Die Erklärung mußt Du aber auch für Controller ohne AES abgeben. > Das noch zum Thema, wenn man unbedingt AES haben möchte. Wenn DAS ein Hindernis sein soll, dann implementiert man es eben in SW ... Gruß Jobst
Nabend 1. Signaturverfahren sind sicher wenn sich richtig implementiert worden sind. Sonst währen PGP bei E-mails ja auch schwachsin. bzw gewisse Signaturferfahren auch nicht gerichtlich anerkannt / verwertbar. 2.Und was sicher heisst, kann sich von Tag zu Tag ändern. Denn der Stand der Technik entwickelt sich weiter. 3. Jedes vernünftige Verschlüsslungsverfahren kann auch zum signieren verwendet werden. Aber zurück zum Thema. Man sollte sich erst einmal klar werden, welchen Antriffen man sich erwehren will. z.B. 1. einfachen Aufzeichnen der Kommunikation und wieder abspielen 2. Analyse der Aufzeichnung und Manipulation (selbstgeschriebenes freischalt tool) 3. auslesen der FW und wieder einspielen auf anderen Geräten. ( Klonen ) Ob sich dabei die serien no des gerätes ändert intersiert denjenigen ja unter umständen ja auch gar nicht. 4. Sich mitels JTAG oder anderer DebugProbs in die Laufende MCU einzuklinken. um z.B. die Verschlüsslungs keys aus dem RAM zu extrahieren. 5 das ganze auch wenn er die MCU auslötet um an die FW zu kommen? 6. Modifizierte FW stände in der HW einspielen 7. Auslesen der gespeicherten KEYs auch bei JTAG zugang verhindern? und zu guter letzt, vor angriffen, die anfangen ICs abzuschleifen und das flasch mit elektronen raster microskopen auslesen. Sebst gegen sowas kann man sich schützen, nur dann wirds richtig teuer. und aufwendig (eigene ICs, und meist nur krypto keys und nicht die FW) Ab einem bestimmten Punkt muss die HW einen dabei unterstützen. z.B. Fuse Bits / Bauteil varianten bei denen man den DebugProbe abklemmen kann / nicht vorhanden ist. Eine separaten OTP Key speicher, auf den nur die Crypte HW des Bausteins zugriff hat und sonst niemand mehr. Speicherplatz für nicht veränderbare SerienNo, ... Wie seiht die Angreifbarkeit des Freischalttools aus? Windows Anwendung, Smartphone anwendung? wie leicht kann die ausgehebelt werden? wird der Key online errechnet und dann übertragen, oder erfolgt das in der Anwendung, wer hat zugriff auf die Anwendung. Eine auf einem PC laufende Software lässt sich um einiges einfacher aushebeln als eine Embedded software. Mann muss nicht nur einen teil betrachten, sondern eigentlich das ganze system.
Ruediger W. schrieb: > Wie verhindere ich, dass jemand durch auslesen des Speichers entweder > die Verschlüsselung knackt oder auf einem anderen Weg das Upgrade > freischaltet? (Codeschutz) In Deinem Szenario? Das ist einfach: Gar nicht!
Ruediger W. schrieb: > Die Steuerung soll ein Upgrade enthalten, dass > Freigeschaltet werden muss (Ergebnis des Upgrades: Motor bringt mehr > Leistung). Kapitalismus in Reinkultur: Dem Kunden ein künstlich verkrüppeltes Produkt verkaufen und doppelt abkassieren. Scheint mitlerweile ja gang und gäbe zu sein. Moralisch allerdings... na ja...
> Aus USA bekomme ich diese aber nur, wenn ich irgendwelche Erklärungen > unterschreibe und vermutlich den Verbleib jedes einzelnen Stückes > sorgfältig dokumentiere. Null Bock! Bestelle doch bei Mouser !
zum bescheidenen Stand... habe mir mehrere AES Anwendungen angesehen und schließlich eine gefunden mit der ich arbeiten konnte verstehe da zwar nicht alles, aber fast alles derzeit als Konsolenanwendung kann tasttaturtexte ver/entschlüsseln ebenso .txt dateien habe ein STM3210C-Eval von der Hochschule bekommen um es mal einfach auszudrücken... vollkommen nutzlos kein JTAG Adapter und auf anderen wegen will das irgendwie nicht kommunizieren ja ich hab das richtige RS232 Kabel zum Thema nochma meine idee wäre, dass alles was auf die Schnittstellen geht an Datenverkehr vorher mein "Programm" durchläuft und verschlüsselt wird nur der Server des Herstellers kann mit den Daten was anfangen (davon ausgehend, dass das System nicht geknackt ist) einkommende daten werden entschlüsselt Ich danke nochmal für jede Idee und Anregung irgendwie amüsiert es mich, wie über die künstliche verkrüppelung hergezogen und diskutiert wird es ist fragwürdig, aber hier eben nicht das entscheidende Thema in meinem Fall
find ich auch, Ob nun sinn oder unsinn, ist ja egal, es geht hier darum, eine Software Funktion freizusachalten. Ob das nun eine Lizenz für eine Sauteure weiterentwicklung ist, oder nur ein geänderter Parametersatz, ... ist doch egal. Bei BMW bzw Daimler bei den Dieselmotoren. 3 mal der gleiche Motorblock mit dem gleichen Hubraum, aber unterschiedliche PS Leistung. (ok es gibt mechanische unterschiede an den Anbauteilen wie z.B. Turbolader, ... aber der block ist der gleiche) Fahrer assistenz systeme / Komfor funktionen. Tempomat, ist zum grossen teil Software, die HW für die Regelung haben neue autos sowieso schon on bord, E-Gas, es fehlt eigentlich nur der Hebel zum steuern, und der Key um es zu benutzen. ABS ESP ASR basieren zum grossen teil alle auf den gleichen sensorwerten, Drehgeber in den Rädern und erkennung der drehbewegung des Fahrzeuges um die eigene achse, alles andere ist software. Begrenzung der Höchstgeschwindigkeit, BMW macht z.B. seit langem bei 250 dicht obwohn loch mehr möglich wäre. Ein franzoe z.B. bei der im Fahrzeugschein eingetragenen höchstgeswindigkeit. TV geräte, wie oft hab ich da alternativ bestückungen gesehen für z.B. Mono Stero Dolby, und nur eine war bestückt, Heute wirds warscheinlich per software gemacht, da es warscheinlich nur noch einen bausteim gibt / in stückzahlen billiger ist als 2 versionen vorzuhalten. Autoradio, kann der nun MP3 oder nur CD? meist nur ein flag in der FW. Und kann er auch MP3 über USB? warscheinlich bauteile im cent bereich die fehlen. und was auch hier ganz vergessen wird, eine - HW die mehrere Produkte abdeckt läst sich in grösseren Stückzahlen Produziehren, was die Kosten senkt. - Entwicklunskosten fallen geringer aus, Ich muss nicht mehr 2 mal das rad neu erfinden. - ich kann einfacher und schneller auf den Markt reagieren, ich kann erst in der auslieferung entscheiden was das ding nun kann oder nicht. - Ersatzteilversorgung wird einfacher, Ich hab nur noch ein Produkt siehe oben, Und bei den teuren OSZI, ich kann klein einsteigen, und kann aufrüsten, wenn ich das will, ggf auch nur für einen begenzten zeitraum. Spart dem Anwender ggf Kosten. Hier ist generell die Denkweise bei manchen leuten auch falsch. Das High end produckt kosten sein geld in der Entwicklung und Produktion. was der käufer auch zahlen wird. Daraus durch künstliche begrenzung ein günstigeres zu machen läst die Entwicklungskosten für ein LowKost gerät weg fallen / reduzieren. Ich kann mehr bauteile einkaufen und produzieren, was wieder die Kosten senkt. aber das ganze ist hier nicht zeilführend.
123 schrieb: > Ob nun sinn oder unsinn, ist ja egal Das scheint leider die Meinung der breiten Masse zu sein. Den Erfolg dieser Denkweise kann man ja gerade auf der ganzen Welt sehen...
Manfred Freise schrieb: > Kapitalismus in Reinkultur: Dem Kunden ein künstlich verkrüppeltes > Produkt verkaufen und doppelt abkassieren. Scheint mitlerweile ja gang > und gäbe zu sein. Moralisch allerdings... na ja... Ja, was ist mit "moralisch"? Moralisch verwerflich finde ich auch, dass wir hierzulande unser Fressen in den Müll schmeißen während woanders Kinder verhungern, also komm mir bitte nicht mit "Moral" in Bezug auf elektronische Produkte. Niemand zwingt den Kunden ein Upgrade durchzuführen. Womöglich reicht dem Kunden sogar die "verkrüppelte" Version und er ist froh, dass er sie so günstig kriegen konnte? Vielleicht reicht ihm irgendwann die verkrüppelte aber auch nicht mehr und er ist froh, dass er mit verhältnismäßig geringen Kosten ein Upgrade durchführen kann? Ganz davon ab dass dadurch weniger Schrott produziert wird weil ein Produkt nicht gegen ein neues Produkt ausgetauscht werden muss? Komisch dass die Heulerei immer nur bei solchen Produkten kommt, die potentiell ein Upgrade ermöglichen. Ich glaube, dass es in solchen Fällen auch gar nicht um den bösen Kapitalismus und die "Moral" geht, sondern dass sich da einfach jemand ärgert, dass er nicht so einfach mehr Leistung zum billigen Preis abgreifen kann. Nennt sich dann "Geiz ist geil" o.ä..
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.