Hi, hab von nem Freund was mitbekommen, dass gewisse Elektronikchips vor unbefugtem Softwarezugriff mittels Ver-/Entschlüsselung geschützt werden. Also dass quasi in einem EEPROM ein schlüssel liegt, welcher der Chip anwendet um seine Software zu entschlüsseln. Hab noch was mitbekommen, dass eine Primzahl verwendet wird, da diese nur mit auspröbeln und nicht mathematisch ermittelt werden kann. Ich würde gerne mehr darüber erfahren und würde auch gerne wissen, ob sowas mit einem Raspberry Pi und einem externen EEPROM oder so möglich ist, also dass der Code auf dem Raspberry vor unbefugtem Zugriff geschützt ist. Bin blutiger Anfänger und kenne die Regeln/Gesetze dazu nicht, aber falls es möglich wäre hätte ich bock sowas selbst mal auszutesten. Falls mir jemand mehr darüber erzählen kann, oder mir einen Begriff nennen kann, mit welchem ich im Netz ein wenig googeln kann, würde ich mich freuen. Danke
Manuel N. schrieb: > EEPROM oder so möglich ist, also dass der Code auf dem Raspberry vor > unbefugtem Zugriff geschützt ist. Wenn man also an den Raspberry bzw. die SD-Karte und den EEPROM ran kommt, hat man alles um das binary selbst zu entschlüsseln. Ich glaube nicht dass das das ist was du wolltest... Vielleicht hilft dir z.B. das hier: https://de.m.wikipedia.org/wiki/Asymmetrisches_Kryptosystem mfg mf
Kurz: der Raspberry Pi kann das nicht bzw. Broadcom hat die Teile nicht dokumentiert, falls sie doch enthalten sind. Zutat 1 wäre Secure Boot. Denn wenn du nicht dafür sorgen kannst, dass nur vertrauenswürdiger Code auf dem Gerät läuft, könnte ein Angreifer Code ausführen, der deinen geheimen Code auf die gleiche Weise entschlüsselt wie der vertrauenswürdige Code es tun würde. Ein übliches Verfahren ist, dass ein Hash eines RSA Public Keys in Fuses gebrannt wird und das ROM dann prüft, ob die nächste Boot Stage mit dem zugehörigen Private Key signiert ist. Den Public Key für die Verifikation muss die Boot Stage aus Platzgründen auch mitbringen, aber dass der stimmt, wird über seinen Hash geprüft. Zutat 2 wäre ein Ablageort für einen geheimen Schlüssel. Der Ort darf allerhöchstens von vertrauenswürdigem Code aus erreichbar sein. Bei manchen Chips darf der laufende Code den Schlüssel zwar in der Crypto Engine benutzen, kann ihn sich aber nicht ansehen. Manche Chips haben einen vom Hersteller vergebenen individuellen Schlüssel, manche habe Fuses damit man seinen eigenen einbrennen kann. Manche haben einen Modus in dem zwar weiterhin nicht vertrauenswürdiger Code ausgeführt werden darf, dieser aber dann nicht den geheimen Schlüssel benutzen kann. Zutat 3 wäre eine Möglichkeit Debugging von außen zu deaktivieren oder einzuschränken. JTAG Pins einfach nur unter dem Chip zu vergraben, reicht nicht. Manche Chips haben Fuses um JTAG abzuschalten, manche haben ein Verfahren, damit der Zugriff mit einem Passwort geschützt wird.
Ich verwende am Raspi den Cryptochip ATSHA204. https://www.microchip.com/en-us/product/ATsha204a Damit werden dann bestimmte Teile freigeschaltet oder gesperrt. Es gibt sogar Raspi-Shields dafür https://learn.sparkfun.com/tutorials/crypto-shield-hookup-guide/all Ist allerdings alles nichts für Anfänger. Hat mich ein paar bezahlte Wochen gekostet.
PittyJ schrieb: > Ich verwende am Raspi den Cryptochip ATSHA204. > https://www.microchip.com/en-us/product/ATsha204a > > Damit werden dann bestimmte Teile freigeschaltet oder gesperrt. > > Es gibt sogar Raspi-Shields dafür > https://learn.sparkfun.com/tutorials/crypto-shield-hookup-guide/all > > Ist allerdings alles nichts für Anfänger. Hat mich ein paar bezahlte > Wochen gekostet. Danke für deine Antwort. Ziehe das im Moment in Erwägung ;). Da ich eh zu wenige GPIO's auf meinem Raspberry habe, möchte ich einen Raspberry Pi Pico als i2c-Slave zur GPIO erweiterung verwenden. Gibt es da evt. andere möglichkeiten zum Codeschutz? Hat ja dort keinen SD-Kartenslot sondern einen internen Flash-Speicher. Ich möchte möglichst wenige Bauteile und wenn der Raspberry Pico den Cryptochip vollständig ersetzen kann, wär das natürlich toll.
Manuel N. schrieb: > Raspberry Pi Pico der hat m.W. keinen Chip-Internen Speicher, sondern ein extern drangeflanschtes Flash. Für deine Anwendung problematisch, weil sich das auch ohne Mithilfe es RP2040 auslesen und kopieren lässt. => µC mit internem Flash & entsprechendem Ausleseschutz wär vmtl. besser.
:
Bearbeitet durch User
PittyJ schrieb: > Ich verwende am Raspi den Cryptochip ATSHA204. > https://www.microchip.com/en-us/product/ATsha204a > > Damit werden dann bestimmte Teile freigeschaltet oder gesperrt. Zur sicheren Kommunikation mit dem Chip muss zuerst (einmalig) mit ihm ein Schlüssel vereinbart werden, der dann die Kommunikation verschlüsselt. Und dann weiß man mit dem RPi wieder nicht, wo man diesen Schlüssel ablegen soll, ohne dass andere da dran kommen.
Manuel N. schrieb: > Danke für deine Antwort. Ziehe das im Moment in Erwägung ;) Security entsteht nicht dadurch, dass man ein Stück Security Software oder Hardware kauft, welche die Ver- und Entschlüsselung macht sondern es benötigt ein vollständiges Systemkonzept welches alle Schwachstellen absichert. Dem Eingangspost nach zu urteilen hast du wenig Erfahrung mit Security und wirst das ohne professionelle Hilfe nicht selbst hinbekommen. Spätestens wenn das Programm läuft kann jemand sich das Programm kopieren und ggf. den Schlüssel aus dem Speicher kopieren, d.h. er kann das Programm auch dann wieder starten, wenn der Security Key nicht mehr gesteckt ist. PittyJ schrieb: > Ist allerdings alles nichts für Anfänger. Hat mich ein paar bezahlte > Wochen gekostet. Das würde ich ernst nehmen. Wenn das nicht nur für den Heimgebrauch als Hobby ist, wird das aufwändig und teuer. Du schreibst nicht, welchen Zwecke die Verschlüsselung hat, ob es um Lizenzierung geht oder was anderes. Für Lizenzierung gibt es spezielle Lösungen, z.B. Dongles (siehe https://www.wibu.com/). Michael
Manuel N. schrieb: > Da ich eh > zu wenige GPIO's auf meinem Raspberry habe, möchte ich einen Raspberry > Pi Pico als i2c-Slave zur GPIO erweiterung verwenden. Gibt es da evt. > andere möglichkeiten zum Codeschutz? Das ist gleich doppelt unsinnig. Wennschon GPIO-Extension über I2C, dann natürlich eher was wie AVR128DA64. Da hast du doppelt so viele GPIOs und erheblich weniger Schaltungsaufwand als beim Pico. Und selbst für sowas wie Crypto-Support ist er besser geeignet als der Pico. Mit seinem externen Flash ist der ja praktisch vollkommen offen, während der AVR durch internen Flash und Lockbits wenigstens einen gewissen Grundschutz gegen Hobby-Cracker mitbringt.
PittyJ schrieb: > Ich verwende am Raspi den Cryptochip ATSHA204. > https://www.microchip.com/en-us/product/ATsha204a > Damit werden dann bestimmte Teile freigeschaltet oder gesperrt. > Es gibt sogar Raspi-Shields dafür > https://learn.sparkfun.com/tutorials/crypto-shield-hookup-guide/all > Ist allerdings alles nichts für Anfänger. Hat mich ein paar bezahlte > Wochen gekostet. Bekommt man damit wirklich eine sinnvolle Verschlüsselung hin oder fällt diese spätestens sobald ein Sniffer am I2C hängt oder man den Kernel/etc manipuliert? Damit die ganze Kette funktioniert müsste doch der Pi mittels zuvor geschriebenen Fuses die Signatur des Bootloaders verifizieren können, ansonsten kann ein Angreifer praktisch alles laden und dein ganzes HSM/TPM aushebeln...
Ich frage mich die ganze Zeit, was für eine schützenswerte Software das wohl sein mag, wenn derjenige hier so eine Frage stellt. Es gibt ein paar Mikrocontroller, die in besonderem Maße gegen Auslesen und Manipulation geschützt sind, wie z.B. der TI Piccolo, welche OTP-Bereiche besitzen, die nur mit bestimmten Rechten im Controller gelesen werden können, von außen jedoch gar nicht. Hier liegen dann secret keys zur Entschlüsselung und Checksummen, mit denen der Code verifiziert wird. Gruß Jobst
Jobst M. schrieb: > Es gibt ein paar Mikrocontroller, die in besonderem Maße gegen Auslesen > und Manipulation geschützt sind, wie z.B. der TI Piccolo, welche > OTP-Bereiche besitzen Spontan fällt mir kein mir geläufiger Controller mit internen Flash ein, der nicht die Möglichkeit bietet, den Readout zu deaktivieren. Die Philosophie kann aber je nach Controller unterschiedlich sein, bei einigen im Automotive Bereich verbreiteten Controllern ist ein Readout dann weiterhin mit Kennwort möglich (NXP MPC, , Infineon Tricore) andere verbieten den Readout abhängig von Fuses vollständig und lassen sich nur mit einem vollständigen Erase wieder entsperren.
Peter Schnapsnase schrieb: > PittyJ schrieb: >> Ich verwende am Raspi den Cryptochip ATSHA204. >> https://www.microchip.com/en-us/product/ATsha204a >> Damit werden dann bestimmte Teile freigeschaltet oder gesperrt. >> Es gibt sogar Raspi-Shields dafür >> https://learn.sparkfun.com/tutorials/crypto-shield-hookup-guide/all >> Ist allerdings alles nichts für Anfänger. Hat mich ein paar bezahlte >> Wochen gekostet. > > Bekommt man damit wirklich eine sinnvolle Verschlüsselung hin oder fällt > diese spätestens sobald ein Sniffer am I2C hängt oder man den Kernel/etc > manipuliert? Der Cryptochip kann einmal beschreiben werden. Danach wird er gelockt, und die internen Schlüssel sind nicht mehr lesbar. Über I2C werden nur Zufallswerte hingeschickt. Diese werden vom Cryptochip mit dem internen Schlüssel verarbeitet und das Ergebnis zurückgeschickt. Das Enwendungsprogramm muss intern das gleiche machen und dann vergleichen, ob das Ergebnis stimmt. Dann ist die Authentifizierung gelungen. I2C Sniffen bringt gar nichts. Kernel manipulieren ist möglich. Ist eben eine Frage des Aufwandes. Irgendwann wird der Angreifer die Lust verlieren, wenns zu kompliziert wird. 100% sicher ist nur der Tod.
PittyJ schrieb: > Der Cryptochip kann einmal beschreiben werden. Danach wird er gelockt, > und die internen Schlüssel sind nicht mehr lesbar. > Über I2C werden nur Zufallswerte hingeschickt. Diese werden vom > Cryptochip mit dem internen Schlüssel verarbeitet und das Ergebnis > zurückgeschickt. > Das Enwendungsprogramm muss intern das gleiche machen und dann > vergleichen, ob das Ergebnis stimmt. Dann ist die Authentifizierung > gelungen. > > I2C Sniffen bringt gar nichts. > Kernel manipulieren ist möglich. Ist eben eine Frage des Aufwandes. > Irgendwann wird der Angreifer die Lust verlieren, wenns zu kompliziert > wird. > > 100% sicher ist nur der Tod. https://blog.scrt.ch/2021/11/15/tpm-sniffing/ "Sniffen bringt nichts". Da du keine Möglichkeit hast in dem Image auf deiner SD Karte ein Geheimnis sicher abzulegen würde ich behaupten sind das alles maximal Unannehmlichkeiten für einen Angreifer, aber ein richtiges Secure Boot mit Secure Storage hast du nicht wirklich. Dazu müsstest du den Bootloader authentifizieren und bräuchtest einen Secure Storage direkt im SoC... TPM am Desktop Computer wird auch erst dadurch sicher, dass man den Nutzer zur Eingabe einer Pin/etc. auffordert. Ansonsten ist ein derartiges System immer anfällig für Attacken wie die oben verlinkte.
Peter Schnapsnase schrieb: > Da du keine Möglichkeit hast in dem Image auf deiner SD Karte ein > Geheimnis sicher abzulegen Du weißt, wofür das "S" in "SD" steht? Auch wenn es praktisch niemand nutzt, SD-Karten lassen sich mit einem "card password" schützen, siehe https://en.wikipedia.org/wiki/SD_card#Card_security
DerEinzigeBernd schrieb: > Peter Schnapsnase schrieb: >> Da du keine Möglichkeit hast in dem Image auf deiner SD Karte ein >> Geheimnis sicher abzulegen > > Du weißt, wofür das "S" in "SD" steht? Auch wenn es praktisch niemand > nutzt, SD-Karten lassen sich mit einem "card password" schützen, siehe > https://en.wikipedia.org/wiki/SD_card#Card_security Ah jetzt gibt der Nutzer auf einmal einen zweiten Faktor bei dem Start des Gerätes ein? Der Nutzer kann nie der Angreifer sein? Gut dass wir das geklärt haben!
Peter Schnapsnase schrieb: > > Da du keine Möglichkeit hast in dem Image auf deiner SD Karte ein > Geheimnis sicher abzulegen würde ich behaupten sind das alles maximal > Unannehmlichkeiten für einen Angreifer, aber ein richtiges Secure Boot > mit Secure Storage hast du nicht wirklich. > > Dazu müsstest du den Bootloader authentifizieren und bräuchtest einen > Secure Storage direkt im SoC... > > TPM am Desktop Computer wird auch erst dadurch sicher, dass man den > Nutzer zur Eingabe einer Pin/etc. auffordert. Ansonsten ist ein > derartiges System immer anfällig für Attacken wie die oben verlinkte. Nein, ein wirklich sicheres System habe ich nicht. Und da es ein Raspi ist, ist dort auch kein TPM mit dabei. Aber die Komplexität wird Gelegenheitshacker davon abhalten auf den verschlüsselten Bereich zuzugreifen. Und auch Profi-Hacker aus China oder Russland würde da >4 Wochen brauchen. Und das reicht in dem Fall aus.
DerEinzigeBernd schrieb: > Du weißt, wofür das "S" in "SD" steht? Auch wenn es praktisch niemand > nutzt, SD-Karten lassen sich mit einem "card password" schützen, siehe > https://en.wikipedia.org/wiki/SD_card#Card_security Da lese ich zunächst mal: "This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2016)" Also Info seit 2016 nicht verifiziert?
Marc X. schrieb: > Spontan fällt mir kein mir geläufiger Controller mit internen Flash ein, > der nicht die Möglichkeit bietet, den Readout zu deaktivieren. Davon rede ich aber nicht. Das ist ja nur nach außen. Ich rede davon, dass, egal auf welche Weise (Legal per Update oder illegal per Bufferoverflow), Code in das System kommt und dort ausgeführt wird, dieser dennoch keinen Zugriff auf diese Bereiche hat. Gruß Jobst
Mit einem atecc508/608 kann man auch Daten sicher ver-/entschlüsseln, aber nicht zur Laufzeit. Das dürfte das entscheidende Problem sein. Es gibt auch verschlüsselnde SD Karten, die sich sperren, sobald der Strom weg ist: https://www.swissbit.com/de/produkte/security-produkte/ishield-camera
Das wichtigste bei solchen Dingen ist, ein klares Bild von den Szenarien zu haben gegen die diese "Code-Verschlüsselung" gerichtet ist, und welche Resourcen (Leute, Rechner, Gummiwurst, Söldner, ...) man den "Angreifern" zutraut. Ohne zu wissen wogegen man sich "wehrt" wird eine "Verteidigung" schwierig.
Jester schrieb: > Also Info seit 2016 nicht verifiziert? Medienkompetenz? Wer spezifiziert, was eine SD-Karte ist, Wikipedia oder die "SD Card Association"?
Manuel N. schrieb: > Gibt es da evt. andere möglichkeiten zum Codeschutz Wozu ? Du nutzt open hardware, und kommst mit closed source ? Wie widersinnig ist das denn. Manuel N. schrieb: > Bin blutiger Anfänger Das ist das Problem. Du darfst versichert sein, dass das Programm welches du mit Ach und Krach und viel Zeitaufwand zusammengehackt bekommst, für einen erfahrenen Programmierer ein Witz ist das er viel besser in kurzer Zeit nachbaut an statt was von dir zu übernehmen.
PittyJ schrieb: > Peter Schnapsnase schrieb: >> >> Da du keine Möglichkeit hast in dem Image auf deiner SD Karte ein >> Geheimnis sicher abzulegen würde ich behaupten sind das alles maximal >> Unannehmlichkeiten für einen Angreifer, aber ein richtiges Secure Boot >> mit Secure Storage hast du nicht wirklich. >> >> Dazu müsstest du den Bootloader authentifizieren und bräuchtest einen >> Secure Storage direkt im SoC... >> >> TPM am Desktop Computer wird auch erst dadurch sicher, dass man den >> Nutzer zur Eingabe einer Pin/etc. auffordert. Ansonsten ist ein >> derartiges System immer anfällig für Attacken wie die oben verlinkte. > > Nein, ein wirklich sicheres System habe ich nicht. Und da es ein Raspi > ist, ist dort auch kein TPM mit dabei. Man kann eines nachrüsten, etwa dieses: [1]. [1] https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module > Aber die Komplexität wird Gelegenheitshacker davon abhalten auf den > verschlüsselten Bereich zuzugreifen. Und auch Profi-Hacker aus China > oder Russland würde da >4 Wochen brauchen. Und das reicht in dem Fall > aus. Im Zweifelsfall geht es ja ohnehin immer darum, die Aufwände für den Angreifer zu vergrößern, bis er sich ein leichteres Ziel sucht. Leichtere Ziele könnten zum Beispiel das Entwicklungssystem oder die SCM-Repositories des Entwicklers sein.
MaWin schrieb: > Manuel N. schrieb: >> Gibt es da evt. andere möglichkeiten zum Codeschutz > > Wozu ? Du nutzt open hardware, und kommst mit closed source ? Wie > widersinnig ist das denn. > > Manuel N. schrieb: >> Bin blutiger Anfänger > > Das ist das Problem. Du darfst versichert sein, dass das Programm > welches du mit Ach und Krach und viel Zeitaufwand zusammengehackt > bekommst, für einen erfahrenen Programmierer ein Witz ist das er viel > besser in kurzer Zeit nachbaut an statt was von dir zu übernehmen. Aber sein Hello World ist so viel... besser, wichtiger, und vor allem: so viel mehr seins... jetzt nimm' einem Anfänger doch nicht gleich alle Hoffnung. ;-)
Ein T. schrieb: > Im Zweifelsfall geht es ja ohnehin immer darum, die Aufwände für den > Angreifer zu vergrößern, bis er sich ein leichteres Ziel sucht. > Leichtere Ziele könnten zum Beispiel das Entwicklungssystem oder die > SCM-Repositories des Entwicklers sein. Oder die soziale Umgebung des Entwicklers. Bei einer schönen 6stelligen Summe, oder einer attraktiven Blonden könnte ich schwach werden.
PittyJ schrieb: > > Nein, ein wirklich sicheres System habe ich nicht. Und da es ein Raspi > ist, ist dort auch kein TPM mit dabei. > Aber die Komplexität wird Gelegenheitshacker davon abhalten auf den > verschlüsselten Bereich zuzugreifen. Und auch Profi-Hacker aus China > oder Russland würde da >4 Wochen brauchen. Und das reicht in dem Fall > aus. Na dann, aber immerhin etwas Mühe gegeben. Finde ich persönlich schade bei den Pi. Das CM4 ist eigentlich eine tolle Sache, gerade für kleinere Unternehmen oder Mittelständler, damit bekommst relativ gute Konditionen wenn man ein SOM möchte im Gegensatz zu den anderen Herstellern, da zahlst teils ähnlich viel für ein SOM wie bei einem CM4, bekommst dafür aber nur einen Single Core und 1GB RAM... Ich habe das komplette Programm hier - SoC mit Secure Boot mit Signatur des Bootloaders (und die komplette Kette bis hin zum Kernel), JTAG dicht, UART dicht, TPM, ATF mit Trusted Application und das System wird mittels LUKS mit eigenem Key für jedes Gerät geschützt. Dazu verschlüsselte Updates mit Signatur usw. Und natürlich liegt nirgendwo ein Key in der Build Umgebung, diese sind auf Hardware Dongles. Was das personell und hinsichtlich der Toolchain allein schon an Aufwand verursacht ist immens und vermutlich schon für einen Mittelständler grenzwertig hinsichtlich Wirtschaftlichkeit bei 0815 Kram. Und wenn man dann bedenkt, dass immer noch Attacken über den Arbeitsspeicher möglich sind und früher oder später eh eine Sicherheitslücke im SoC gefunden werden wird ist dieser Aufwand dann doch manchmal etwas fraglich. Wobei ich hier auch die Schuld bei den SoC Herstellern hinsichtlich des Aufwandes sehe, die sollten das eigentlich selbst liefern für ihre SoC. Mit Glück wird für ein paar Anwendungen eine entsprechende Umsetzung geliefert, aber eigentlich nie für das komplette Programm und jeder Kunde muss das dann selbstständig implementieren, verifizieren und testen muss man es dann eh noch. Sprich ich würde von einem Buildroot/Yocto BSP erwarten, dass mir der Hersteller das ganze Programm auch liefert wie er es im Datenblatt stehen hat, sprich ich binde nur meine eigenen Keys/Dongle/Signing Server ein und hätte dann ein komplettes System mit Secure Boot stehen mit Recovery Boot und Rollback Schutz usw. Bei einem Build fällt dann ein verschlüsselte Update Datei und Fertigungsimage heraus usw. Aber man merkt hier schnell, dass die Hersteller die Features insbesondere in Kombination meist selbst noch nicht ausgereizt haben, schon den einen oder anderen Bug entdeckt im Bootloader usw. welche dann aber zügig vom sehr kooperativen SoC Hersteller behoben wurden. Insgesamt ist das aber nichts für Einsteiger da man sehr viel falsch machen kann und dann der ganze Aufwand umsonst war. Da brauchst schon 1-2 Senior Linux Entwickler mit Erfahrung in Bootloader/ATF/OP-TEE usw. und Security Experten (und damit meine ich keine Cyber Security Anti Virus Dampfplauderer). Und die Kohle für richtiges CI mit Tests und Pentestern muss auch locker sitzen.
Peter Schnapsnase schrieb: > Wobei ich hier auch die Schuld bei den SoC Herstellern hinsichtlich des > Aufwandes sehe, die sollten das eigentlich selbst liefern für ihre SoC. Für eine professionelle Nutzung der SOCs wird es das vermutlich wohl auch geben, aber der RasPi ist immerhin ein quelloffener Bastelrechner und nicht dazu gedacht, professionelle Geräte damit zu entwickeln und damit -- oder mit der installierten Software -- Geld zu verdienen. Da finde ich es schon ganz nachvollziehbar, wenn diese Komponenten nicht öffentlich dokumentiert werden, schließlich ist das ein Alleinstellungsmerkmal, mit dem der Hersteller des SOC seine Brötchen verdient.
Peter Schnapsnase schrieb:
[...]
Ich bin praktisch sicher, dass das Programm des TO auch nichtmal
näherungsweise einen derartigen Aufwand rechtfertigen könnte.
Es ist nämlich so (du weißt das sicher): der Aufwand findet sich
letztlich im Preis des Endprodukts wieder.
Und wer will schon ein bissel verschissenes Bitgeklingel oder ähnliche
Trivialitäten für den Preis eines modernen Kampfflugzeugs erwerben?
c-hater schrieb: > Und wer will schon ein bissel verschissenes Bitgeklingel oder > ähnliche Trivialitäten für den Preis eines modernen > Kampfflugzeugs erwerben? Na da würden sich sicherlich ein paar Politiker finden, sofern es nur schön genug klingelt.
Die Nicht-Hackbarkeit von IoT Geraeten ist ein grosser Hype heutzutage. Deswegen haben Anbieter auch den Drang etwas dazu zu sagen. Auch wenn's um einen Controller geht, welcher nie am Internet haengen wird. Oder nie dazu gedacht war.
Purzel H. schrieb: > Die Nicht-Hackbarkeit von IoT Geraeten ist ein grosser Hype heutzutage. > Deswegen haben Anbieter auch den Drang etwas dazu zu sagen. Auch wenn's > um einen Controller geht, welcher nie am Internet haengen wird. Oder nie > dazu gedacht war. Und jedes mal wenn mal jemand genauer hin schaut wird festgestellt, dass grobe Fehler im Design sind. Sicher + Komfortabel geht nämlich nicht. Versucht wird meist: Sicher + Komfortabel + Billig. Der geht noch weniger.
Purzel H. schrieb: > Die Nicht-Hackbarkeit von IoT Geraeten ist ein grosser Hype heutzutage. Dann wirst du die GPL V3 lieben wenn dir eine Firma ihr Produkt als Privatanwender verkauft...
Ein T. schrieb: > Da finde ich es schon ganz nachvollziehbar, wenn diese Komponenten > nicht öffentlich dokumentiert werden, schließlich ist das ein > Alleinstellungsmerkmal, mit dem der Hersteller des SOC seine Brötchen > verdient. Deswegen haben NXP und Xilinx so einen unglaublich großen Nachteil seit sie die Verfahren ihrer i.MX und Zynq SoCs in ellenlangen frei verfügbaren PDFs dokumentiert und den Quellcode von CST und Bootgen offengelegt haben...
Daniel schrieb: > Deswegen haben NXP und Xilinx so einen unglaublich großen Nachteil seit > sie die Verfahren ihrer i.MX und Zynq SoCs in ellenlangen frei > verfügbaren PDFs dokumentiert und den Quellcode von CST und Bootgen > offengelegt haben... Ja Xilinx hat auch nicht überlebt, und wurde von AMD aufgekauft. Das lag wohl am offenen Quellcode.
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.