Hallo, ich suche nach einer Möglichkeit auf einem ARM-Board mit Linux zu arbeiten und gleichzeitig einen Schutz gegen ungewünschtes Kpieren der Software zu erreichen. Da interessiert es mich, ob es da einige etablierte Lösungen gibt (Rad nicht neu erfinden) oder ob das wirklich ein Problem ist. Ich denke an ein ARM9 oder Cortex A8 Board (z.B. Gnublin / BeagleBoard) auf dem ein debian Linux (o.ä.) mit Bootloader wie uBoot läuft. Anders als bei normalen uControllern, die die Application im internen Flash haben, und damit gegen Kopieren geschützt sind, haben die großen Prozessoren meines Wissens nach nur ein internes ROM. Damit brauchen sie sämtliche Software extern. Wie könnte man da einen Kopierschutz realisieren? Vielen Dank für eure Tips. Mischu
Michael O. schrieb: > Wie könnte man da einen Kopierschutz realisieren? Binde Dein Executable an eine eindeutige HW-ID auf dem Board (Seriennummer, HW-MAC-Adresse oder ähnliches).
Michael O. schrieb: > Anders > als bei normalen uControllern, die die Application im internen Flash > haben, und damit gegen Kopieren geschützt sind, Kommt ganz auf den Controller und die Fähigkeit des Angreifers an. Frank M. schrieb: > Michael O. schrieb: > >> Wie könnte man da einen Kopierschutz realisieren? > > Binde Dein Executable an eine eindeutige HW-ID auf dem Board > (Seriennummer, HW-MAC-Adresse oder ähnliches). Per Reverse-Engineering kann man herausfinden wo eine entsprechende Überprüfung stattfindet und das Executable dann recht leicht manipulieren.
Frank M. schrieb: > Michael O. schrieb: > >> Wie könnte man da einen Kopierschutz realisieren? > > Binde Dein Executable an eine eindeutige HW-ID auf dem Board > (Seriennummer, HW-MAC-Adresse oder ähnliches). Und denk daran, dass Du wirklich nur Dein Excecutable schützen kannst und das auch nur, solange Du keine Komponenten oder Bibliotheken einsetzt, die GPLed sind. Dank GPL mutierst Du automatisch zum Distributor der von Dir ansonsten auf dem System eingesetzten Linux-Distribution. Wenn Du tatsächlich Schutz Deiner wertvollen IP brauchst, holst Du Dir mit Linux keine wirklich guten Randbedingungen ins Haus. VG
Der absoluten Schutz ist nie erreichbar, das ist mir auch klar. Mit entsprechend Energie wird man jedes System früher oder später knacken können. Wäre es denn denkbar, die Daten verschlüsselt im Flash abzulegen, den bootloader mit einer Entschlüsselungsroutine ausstatten die die HW-ID des Controllers benötigt? Dann ist nur während des Bootvorgangs eine Enschlüsselung und Kopiervorgang in den RAM notwendig, danach läuft die Application im RAM. Oder sind die entpackten Daten im RAM ebenfalls leicht angreifbar? Michael B. schrieb: > Und denk daran, dass Du wirklich nur Dein Excecutable schützen kannst > und das auch nur, solange Du keine Komponenten oder Bibliotheken > einsetzt, die GPLed sind. Dank GPL mutierst Du automatisch zum > Distributor der von Dir ansonsten auf dem System eingesetzten > Linux-Distribution. Was bedeutet es, Distributor zu werden?
Michael O. schrieb: > Wäre es denn denkbar, die Daten verschlüsselt im Flash abzulegen, den > bootloader mit einer Entschlüsselungsroutine ausstatten die die HW-ID > des Controllers benötigt? Dann ist nur während des Bootvorgangs eine > Enschlüsselung und Kopiervorgang in den RAM notwendig, danach läuft die > Application im RAM. habe ich auch als erste mir überlegt. Aber dann tausche ich einfach die Routine die die HW-ID ausliest durch eine eigene aus und liefere die original HW id zurück.
Roger schrieb: > Per Reverse-Engineering kann man herausfinden wo eine entsprechende > Überprüfung stattfindet und das Executable dann recht leicht > manipulieren. Der Großteil der User ist dazu gar nicht in der Lage. Ich glaube kaum, dass Michael ein Programm entwickelt hat, auf welches sich Millionen von Usern stürzen werden und dieses somit irgendwelche Hacker magnetisch anzieht.
Michael O. schrieb: > Michael B. schrieb: >> Und denk daran, dass Du wirklich nur Dein Excecutable schützen kannst >> und das auch nur, solange Du keine Komponenten oder Bibliotheken >> einsetzt, die GPLed sind. Dank GPL mutierst Du automatisch zum >> Distributor der von Dir ansonsten auf dem System eingesetzten >> Linux-Distribution. > Was bedeutet es, Distributor zu werden? Nun, X stellt fest, das auf Deinem Gerät beispielsweise BusyBox oder iptables zum Einsatz kommt. Da diese Komponenten GPLed sind, hat X Anspruch darauf, dass Du für X eine Möglichkeit schaffst, an die von Dir verwendeten Quellen der GPL-Komponenten zu gelangen. Und da das auch noch exakt die Quellen sein müssen, aus denen Du Dein System kompiliert hast (siehe http://www.heise.de/open/meldung/GPL-Urteil-Quellen-und-Binaries-muessen-gleiche-Version-haben-1897161.html), reicht es auch nicht zu sagen, "Ich hab Debian X.Y.Z auf dem Gerät, schau bitte da". Linux und Kopierschutz erscheint mir irgendwie analog zu Demokratie ohne Volk. Geht zwar, ist aber mit erheblichen Einschränkungen verbunden.
Deine Beschreibung gilt allerdings nur für die LGPL. Bei der GPL müssen auch die Sourcen von allen abgeleiteten Programmen offengelegt werden.
Frank M. schrieb: > Michael O. schrieb: > >> Wie könnte man da einen Kopierschutz realisieren? > > Binde Dein Executable an eine eindeutige HW-ID auf dem Board > (Seriennummer, HW-MAC-Adresse oder ähnliches). Ist aber sehr leicht zu knacken. Man muss in der Executable nur den Schalter für die Verzweigung bei falscher HW-ID finden und durch ein NOP ersetzen. Das macht man schon seit Jahr und Tag so um Computerspiele zu cracken. Wenn dann muss die Executable verschlüsselt sein und wird zur Laufzeit per HW-Dongle entschlüsselt. Da gibts prof. und sehr teure Lösungen. Das ist der einzige Weg um halbwegs sicher zu sein. gruß cyblord
Nicolas S. schrieb: > Deine Beschreibung gilt allerdings nur für die LGPL. Bei der GPL müssen > auch die Sourcen von allen abgeleiteten Programmen offengelegt werden. Abgeleitet ist da das Schlüsselwort. Es spricht nichts dagegen, auf so einem Gerät ein proprietäres executable laufen zu lassen und dessen Quellen nicht herauszugeben, solange es nicht gegen irgendetwas GPLtes gelinkt ist. Prominentes (und ärgerliches) Beispiel dafür sind die Google Apps auf jedem Android Fon.
Frank M. schrieb: > Der Großteil der User ist dazu gar nicht in der Lage. Ich glaube kaum, > dass Michael ein Programm entwickelt hat, auf welches sich Millionen von > Usern stürzen werden und dieses somit irgendwelche Hacker magnetisch > anzieht. Er macht dazu aber keine Angaben, ergo kann man auch nicht wissen, wie hoch der Schutzbedarf ist. Zudem genügt es bei Software, wenn nur ein fähiger Angreifer einen entsprechenden Crack veröffentlicht, danach kann auch Lieschen Müller die Applikation knacken. Dewegen sind reine Software-Schutzmechanismen für sowas absolut ungeeignet. Und im Zweifel sollte man dann eben eine Nummer zu hoch ansetzen und die Sicherheitsfunktionen durch die Hardware realisieren..
Naja, oft dienen Kopierschutz und closed source eh eher dazu zu verstecken, wie stümperhaft und klein der eigene Anteil ist. (Mache ich übrigens auch so: Quelltexte und Schaltpläne nur von wirklich fertigen Projekten herausgeben).
Michael B. schrieb: > Und denk daran, dass Du wirklich nur Dein Excecutable schützen kannst > und das auch nur, solange Du keine Komponenten oder Bibliotheken > einsetzt, die GPLed sind. Dank GPL mutierst Du automatisch zum > Distributor der von Dir ansonsten auf dem System eingesetzten > Linux-Distribution. Das stimmt so glaub ich nicht. Du musst allen Endkunden die Quellen aller GPL-Konmponenten offenlegen / mitliefern (kein Problem). Bibliotheken, die der LGPL unterliegen, und gegen die dein Programm gelinkt ist, musst du ebenfalls im Source mitliefern. Für Komponenten gilt das gleiche. Wenn du allerdings eine GPL-Komponente selbst veränderst, musst du den Quellcode deiner Änderungen mitliefern. All das zwingt dich aber nicht, auch deine Quellen zu veröffentlichen, und hindert dich auch nicht, kommerzielle Projekte mit offenen Quellen zu erstellen. Schließlich gibt es genug kommerzielle Software für Linux, welche rechtlich völlig ok sind.
Michael Reinelt schrieb: > Michael B. schrieb: >> Und denk daran, dass Du wirklich nur Dein Excecutable schützen kannst >> und das auch nur, solange Du keine Komponenten oder Bibliotheken >> einsetzt, die GPLed sind. Dank GPL mutierst Du automatisch zum >> Distributor der von Dir ansonsten auf dem System eingesetzten >> Linux-Distribution. > > Das stimmt so glaub ich nicht. Doch ;-) > > Du musst allen Endkunden die Quellen aller GPL-Konmponenten offenlegen / > mitliefern (kein Problem). [...] > Schließlich gibt es genug kommerzielle Software für Linux, welche > rechtlich völlig ok sind. Genau das steht oben. In diesem Anwendungsfall ist der (anzunehmende) Liefergegenstand aber nicht nur ein Software-Exceutable, sondern ein komplettes Gerät auf dem eine Linux-Distribution installiert ist. Und da liegt die Krux - wer die Binärform der GLPten Komponenten verteilt, muss auch die Quellen verteilen.
Michael B. schrieb: > wer die Binärform der GLPten Komponenten verteilt, muss > auch die Quellen verteilen. ja, aber nur die Quellen der GPLten Komponenten, nicht die eigenen Quellen (ein häufiges Mißverständnis)
Das einzige was "günstig" ist und vor simplen 1:1 Kopien schützt, ist eine CryptoMemory, wie z.b. hier in dieser Appnote beschrieben: http://www.picoinstruments.com/how-to-implement-firmware-anti-cloning-protection.html Das schützt mal gegen einfache 1:1 Kopien, da die Kopierer normalerweise wenig Ahnung von der Applikation haben und das Vorgehen so ein System zu kopieren ist: - PCB Layout Kopieren - Flash auslesen, ins eigene Flash programmieren Wenn die Kopierer nun das o.g. Prinzip einbauen, und man es nicht so ungeschickt implementiert dass die Abfrage ob das Ergebnis des Hash richtig oder falsch ist, gleich nach dem IO Zugriff stattfindet, sondern zu einem viel späteren Zeitpunkt, dann hat man schon mal eine Hürde aufgebaut die man mit Geld/Zeit überwinden muß. Das kann je nachdem entweder die Lust am Kopieren verderben, oder die Kopie "teurer" machen. Dann gibt es die Möglichkeit, zusätzlich ARMs wie den Atmel SAMA5 mit Secure Bootloader zu verwenden, dieser Schütz schonmal davor, dass man keine neue Firmware auf dieses Board draufspielen kann. Dann, eine Stufe teurer, wären MPU mit ARM TrustZone, diese haben Anti-Tamper Implementierungen und auch einen "Hardwareschutz", normalerweise wird ein Hardware Metal Layer verwendet um den Die vor zugriffen zu Schützen. Dann kann man in so einem ARM Trustzone auch einen Schlüssel ablegen, der so mit einfachen Methoden nicht auslesbar ist. Man müsste dann schon den Metal Layer abschleifen, wenn der Hersteller es geschickt macht, ist dann aber der Die nicht verwendbar wenn der Metal Layer über sogenannte NanoWire eng mit dem Die verflochten war. Und am Sichersten wäre es, gleich einen SecureMCU zu verwenden, die min. EAL4+ Compliance besitzt und z.b. von SmartCards verwendet wird. Dies zu knacken ist schon sehr schwierig und meiner Meinung nach bietet den höchstmöglichen Schutz (aber keinen 100%). Solche Systeme haben dann z.b. einen Mechanismus, wenn jem. z.b. das Gehäuse öffnet, dann wird ein Teil des internen Speichers automatisch gelöscht in dem sich z.b. der Schlüssel zum entschlüsseln der FW aufm externen Flash befindet. Natürlich muß so ein System eine Backup Batterie haben, damit das Öffnen des Gehäuses erkannt wird selbst wenn die HauptStromversorgung gekappt ist. Dieses Prinzip ist zwar sicher, man kriegt sowas aber erst gar nicht zu kaufen, oder die Hürden sind extrem hoch (Nachweis dass man die Datenblätter im Tresor aufhebt, Nachweis wer Zugriff auf DS, Samples, Boards hat usw.) oder es gibt eine sehr hohe Abnahmemengen in Millionen Stückzahlen. Wir haben mal bei ST angefragt, sie wollten eine Minimalbestellung von 500000St! http://www.st.com/web/en/catalog/mmc/FM143/SC1192 Jetzt hast Du die Qual der Wahl :) Jetzt mußt Du entscheiden wie sicher du das ganze haben willst und wieviel du für Sicherheit zahlen kannst ;-)
Michael O. schrieb: > Wie könnte man da einen Kopierschutz realisieren? Baue einen NON-GPL Bootloader. Signiere alle Binaries mit einem kryptografischen Schlüssel. Sorge dafür, dass der Bootloader nur von Dir signierte Kernel lädt. Sorge dafür, dass der Kernel nur signierte InitRDs lädt. Sorge dafür, dass der Kernel selber nur signierte Binaries lädt. Andere Leute können vielleicht die Binaries bauen, aber sie bekommen sie nicht mit Deinem Key signiert. Sprich: Die Binaries nützen ihnen nichts. Schwachpunkt ist der Bootloader. Der muss bestmöglich geschützt werden. Aber: - XBOX ist gehackt. - PS3 ist gehackt. - HDCP ist gehackt. - GSM ist gehackt. - ... - Wenn Dein System interessant genug ist, wird es irgendwann auch gehackt sein. Ist einfach so. fchk
Frank K. schrieb: > - XBOX ist gehackt. > - PS3 ist gehackt. > - HDCP ist gehackt. > - GSM ist gehackt. Ja, weil sie alle mehr oder weniger offensichtliche Fehler oder Schwachstellen haben.
Momentan geht es mir darum auszuloten, was man machen müsste um die eigene IP unter Linux zu schützen. Bisher geht es eher um die Stückzahl 100 - 1000. Trotzdem nochmals. Wenn ich die HW ID des Prozessors nehme und mit diesem für jede Prozessor ID individuell verschlüsseltes Image generiere, dann reicht doch ein Auskommentieren oder überspringen der HW-ID Abfrage nicht aus. Ich müsste dann die Applikation oder auch das gesamte image erst mit dem korrekten Schlüssel dekodieren, bevor ich an den Inhalt komme. Frage 1: Wie sicher sind denn die Daten im RAM von einem Prozessor? Könnten diese dort auch in einer verschlüsselten RAM Sektion liegen? Frage 2: Gibt es einen Bootloader (uBoot GRUB etc) den man mit einfachen Mitteln um eine Verschlüsselung erweitern kann? Frage 3: Wie sicher ist es, wenn ich viele gleiche Images habe, die jeweils mit anderen Schlüsseln aber dem gleichen Algorithmus verschlüsselt sind?
Ich verstehe die Aufgabenstellung eher so, daß eine Applikation, und nicht das gesamte Betriebssystem geschützt werden soll. Genügt ja vollkommen, wenn die intellektuelle Eigenleistung in dieser Executable steckt. Alles andere wäre mit Kanonen auf Spatzen geschossen. Abgesehen von der Prüfung einer Seriennummer in der Hardware (z.B. in einem One-Wire-Chip) wäre es möglich, einen Smartcard-Chip in das Design mit einzubeziehen und über dessen Crypto-Funktionen die Applikation beim Ladevorgang in den Arbeitsspeicher zu decodieren. Ein solches Verfahren ist nur mit größerem Aufwand zu umgehen, da der Smartcard-Chip den darin gespeicherten Schlüssel nicht direkt preisgibt. Einfache Nachbauten verhindert dies sicher. Ambitionierte Hacker verlangsamt es nur. Letztlich könnte man noch ein "Dongle" integrieren: Ein auslesegeschützter Mikrocontroller, der über irgendeinen seriellen Bus mit der CPU kommuniziert, und eine ganz kleine, aber wichtige Teilfunktion der Applikation intern ausführt, ohne die der Rest nicht geht. Das Kosten-Nutzen-Verhältnis kann hier günstig sein, wenn im Layout noch Platz ist. Am Ende ist egal, ob die Applikation als solche kopiert werden kann, wenn sie ohne das Originalsystem nicht läuft.
Das "ganze Image" zu verschlüsseln solltest du nochmal mit deinem Anwalt besprechen, wenn in dem Image auch (L)GPL-Software vorkommt, gegen die deine Software linkt. Schliesslich musst du dem Endanwender die Möglichkeit geben, die LGPL-Softwareteile zu modifizieren, und die modifizierten Teile auch zu verwenden. d.H.: Wenn du statisch linkst, musst du von deiner Software zwar nicht den Quelltext rausgeben, aber zumindest Object-Files, die ein erneutes Linken gegen veränderte Bibliotheken erlauben. Beim Dynamisch gelinkten ".so"-Files entfällt das zwar, aber: Bei beiden Varianten braucht der Nutzer eine Möglichkeit, seine Modifikationen *in dein Image* zu integrieren, also den Schlüssel. Zwar: Wo kein Kläger, da kein Richter, aber du verwendest viel Aufwand auf einen Schutz, der anschließend sehr leicht (technisch oder juristisch) ausgehebelt werden kann. => Mach eine dumme HW-ID-Abfrage in dein Binary und gut.
> Frage 1: Wie sicher sind denn die Daten im RAM von einem Prozessor? Wenn JTAG nicht abschaltbar ist: gar nicht Bei externem RAM: Logicanalyzer anklemmen und mithören. Kein Problem. > Könnten diese dort auch in einer verschlüsselten RAM Sektion liegen? Wenn der Prozessor so etwas kann. > Frage 2: Gibt es einen Bootloader (uBoot GRUB etc) den man mit > einfachen Mitteln um eine Verschlüsselung erweitern kann? uboot ist GPL, d.h. da musst Du Deine Änderungen veröffentlichen grub ist GPL. Dito. redboot ist GPL. Dito. > Frage 3: Wie sicher ist es, wenn ich viele gleiche Images habe, die > jeweils mit anderen Schlüsseln aber dem gleichen Algorithmus > verschlüsselt sind? Schon mal was von Differentieller Cryptoanalyse und Known-Plaintext-Attacken gehört? Das wären Angriffspunkte. Ich sag mal so. Vergiss Linux. Nimm vxWorks, Greenhill integrity oder etwas anderes in der Richtung. Da hast Du es einfacher. fchk
Εrnst B✶ schrieb: > Beim Dynamisch gelinkten ".so"-Files entfällt das zwar, aber: Bei beiden > Varianten braucht der Nutzer eine Möglichkeit, seine Modifikationen *in > dein Image* zu integrieren, also den Schlüssel. Bei GPL2 ist das nicht erforderlich, erst bei GPL3. fchk
Michael O. schrieb: > Wenn ich die HW ID des Prozessors nehme und mit diesem für jede > Prozessor ID individuell verschlüsseltes Image generiere, dann reicht > doch ein Auskommentieren oder überspringen der HW-ID Abfrage nicht aus. man kann es auch so ändern, das eine gültige HW-ID geliefert wird.
Frank K. schrieb: >> Frage 3: Wie sicher ist es, wenn ich viele gleiche Images habe, die >> jeweils mit anderen Schlüsseln aber dem gleichen Algorithmus >> verschlüsselt sind? > > Schon mal was von Differentieller Cryptoanalyse und > Known-Plaintext-Attacken gehört? Das wären Angriffspunkte. Was hat das mit dem hier vorliegenden Sachverhalt zu tun? Bei differentieller Cryptoanalyse untersucht der Angreifer, welche Auswirkungen Differenzen im Plaintext auf den Ciphertext haben. Wenn du aber die gleiche Anwendung mit unterschiedlichen Schlüsseln verschlüsselst dann hast du genau 0 Differenzen im Plaintext. Noch "schlimmer", wenn eine Verschlüsselung wie AES genutzt wird und für jedes Gerät unterschiedliche Schlüssel verwendet werden so kann man ohne Kenntnis des Schlüssels nicht einmal mehr sagen, ob ein Chiffrat mit einem bestimmten Schlüssel verschlüsselt wurde oder nicht, da die Chiffrate im Idealfall nicht von Zufallstrings unterschieden werden können.
1.Findige Leute gibt es immer wieder und wenn sie z.B. Deinen Chip über den Stromverbrauch knacken. 2.Mir würde statt dem totalen Schutz was Einfaches wie iregndeine Prüfzahl prüfen erst mal gefallen. Anschließend würde ich dann aber keine Funktion ganz sperren sondern jedes Mal diese etwas länger verzögern. Irgendwann käme dann der Hinweis im Servicefall wenden Sie sich ...
Folgende Ansätze hätte ich beizusteuern: 1) Simpel, kaum aufwendig: Binde die User-Space-Software an einen simplen Key, der im U-boot-Environment gespeichert ist, aus dem Sprungtabellen generiert werden. Da sucht einer beim Reverse-Engineering schon mal ev. ein bisschen. Andere Methoden sind pure SW-Lizenzkeys. Wir haben da mal was mit eingebautem Python-Bytecode gemacht, das ist auch etwas schwieriger aufzufinden. 2) Kniffliger, und aufwendig: a) FPGA mit auf die Platine integrieren: d.h. SW an HW binden, Algorithmenteile ins FPGA verfrachten. b) CPUs mit brauchbarem Crypto-Bootloader nutzen (z.B. Freescale). Die meisten GPL-Halbwahrheiten von oben sind zweitranging und können beim Crypto-Bootloading sowieso ignoriert werden. Im Endeffekt alles eine Frage der kriminellen Energie des potentiellen Reverse-Engineers :-)
Noch eine Anmerkung: Vom OS ist die Technik unabhängig, solange man bekannte Angriffslöcher stopft. D.h. auch ein Linux ist sehr gut "sicher" zu bekommen, solange die CPU die entsprechenden Fähigkeiten (geschützter Key im OTP und wirklich funktionierende JTAG-Blockade) besitzt. Das Konzept der ADI Lockbox wäre z.B. ganz gut gewesen... bis auf die Sache mit dem JTAG.
Εrnst B✶ schrieb: > Das "ganze Image" zu verschlüsseln solltest du nochmal mit deinem Anwalt > besprechen, wenn in dem Image auch (L)GPL-Software vorkommt, gegen die > deine Software linkt. > Schliesslich musst du dem Endanwender die Möglichkeit geben, die > LGPL-Softwareteile zu modifizieren, und die modifizierten Teile auch zu > verwenden. Du musst dem Anwender nur die Quellen der verwendeten GPL-Software (inkl. Deiner Modifikationen, die ja auch GPL sind). Es ist nicht vorgeschrieben, dass Dein Closed-Source-Programm anschließend mit veränderter GPL-Software läuft (wäre ja auch zu schön, wenn man sich dann noch für vermurgste Erweiterungen der Anwender kümmern muss). Du musst nur dann den Code rausgeben, wenn Du GPL (o.ä.) Code in deinem Programm verwendest. Das Programm darf ohne weiteres GPL-Code aufrufen oder dynamisch GPL-Code linken. Teilweise geht das auch statisch, denn hierbei wird kein GPL-Quellcode verändert. Du darfst auch verschlüsseln/dongeln, obwohl Dein Code auf GPL-Software basiert. Es ist hiervon ja nur der Binärcode betroffen. Nur solltest Du hier geschickt vorgehen, da ja der Quellcode veröffentlicht werden muss. Nichts spricht aber gegen das dynamische Linken von Closed-Source-Bibliotheken, die nicht unter GPL stehen. Dein Open-Source-Programm könnte ja auch Funktionen eines Co-Prozessors nutzen, deren Quellen Du nicht veröffentlichst (eine Art Blackbox).
Christian H. schrieb: > Du musst nur dann den Code rausgeben, wenn Du GPL (o.ä.) Code in deinem > Programm verwendest. Das Programm darf ohne weiteres GPL-Code aufrufen > oder dynamisch GPL-Code linken. Teilweise geht das auch statisch, denn > hierbei wird kein GPL-Quellcode verändert. letzer Absatz der GPLv2: > This General Public License does not permit incorporating your program into > proprietary programs. If your program is a subroutine library, you may > consider it more useful to permit linking proprietary applications with the > library. If this is what you want to do, use the GNU Lesser General > Public License instead of this License. Nur die LGPL erlaubt linken, die GPL nicht.
Ich schrieb: > Nur die LGPL erlaubt linken, die GPL nicht. Und auch da ist die Rechtslage wohl unklar, ansonsten wären gesonderte Ausnahmen wie bspw. für Qt sinnlos http://qt-project.org/doc/qt-4.8/lgpl.html#digia-qt-lgpl-exception-version-1-1
Ok, das Thema scheint etwas komplexer zu sein. Die von mir geschriebene Software (kompilat) würde sowieso nicht auf open-source code basieren sondern ist meine eigene Leistung. Soweit ich verstanden habe, bringt die Modifikation eines GPL Bootloaders auch nichts, da die Modifikation offen gelegt werden muss - der potentielle Kopierer bräuchte dann nur ein funktionierendes Gerät und den Sourcecode um die Applikation zu entschlüsseln. Wenn ich im executable eine Anfrage auf die jeweilige Prozessor-ID mache, dann lässt sich wie beschrieben die Überprüfungsroutine relativ leicht finden und aushebeln. Auch externe Crypto-Bausteine kann man doch ähnlich aushebeln.... Die Verschlüsselung muss ich sicher nicht auf das gesamte Betriebssystem ausdehnen, dachte dies wäre einfacher. Wenn ich aber eine Entschlüsselungsroutine schreibe und dem Bootloader per Skript sagen kann, dass er meine Routine aufrufen soll bin ich doch wieder einigermaßen sicher, oder? Es lässt sich doch eine RAM-Disk anlegen mit einem verschlüsselten Inhalt (und ggf. dynamisch generierter Verschlüsselung). Dort könnte ich die Applikation hinkopieren, so dass sie zur Ausführung geschütz ist. Performance ist sicher nicht so gut wenn Programmteile nachgeladen werden sollen, aber wenn die Applikation nicht so ewig groß ist...? IDEE: Applikation liegt verschlüsselt im externen Flash. Bootloader setzt das System auf, startet ein Skript um eine RAM-Disk anzulegen und verschlüsselt diese mit zufälligem Schlüssel. Anschließend startet die eigene Entschlüsselungsapplikation welche mit einem HW-ID abhängigen Schlüssel die geschützte Datei im CPU-internen Speicher dekodiert und anschließend in den verschlüsselten RAM Bereich kopiert. Final startet das Skript die Applikation aus dem Crypto RAM Bereich. Comments?
Michael O. schrieb: > Final startet das Skript die Applikation aus dem Crypto RAM Bereich. ich ändere das Skript, dannn startet es nicht die Applikation sondert kopierst sie mir auf ein andere Medium.
>Comments?
Der Aufwand zum Knacken muß höher sein als sebst neu zu programmieren.
Manchmal reicht es schon, zu verschiedenen Zeiten 3 Zeichen irgendwo zu
prüfen.
Michael O. schrieb: > Soweit ich verstanden habe, bringt die Modifikation eines GPL > Bootloaders auch nichts, da die Modifikation offen gelegt werden muss - > der potentielle Kopierer bräuchte dann nur ein funktionierendes Gerät > und den Sourcecode um die Applikation zu entschlüsseln. Sofern du "echte" Kryptographie anwendest und keine security-by-obscurity wäre das doch gar kein Thema. Was ich damit sagen will: wenn dein System gescheit designed ist (z.B. Entschlüsselung der Anwendung durch den Bootloader) dann kann potenziell jeder gerne wissen, was dein Bootloader macht (Entschlüsseln). Er darf nur nicht in der Lage sein, diese Funktionalität anschließend selbst durchzuführen. D.h. dass dein Bootloader irgendeinen kryptographischen Schlüssel benötigt, der sicher im Gerät hinterlegt ist. Ist der Schlüssel nicht bekannt so kann die Anwendung auch nicht entschlüsselt werden, ob man den Bootloader kennt oder nicht. Du darfst den Schlüssel nur nicht hart in deinem Code verdrahten. Aber es sollte ja kein Problem sei den Schlüssel im Bootloader als Variable zu repräsentieren.
Je mehr "echte" Kryptographie Du einbaust, desto mehr Tücken hast Du später, wenn was nicht funktioniert. Verschlüsslung ist höchstens das Sahnehäubchen wenn andere Vernebelungsaktionen keine Wirkung zeigen. Bevor ich mir Sorgen um einen Kopierschutz machen würde, wäre mir eine sichere Funktion und Selbstdiagnose wichtiger.
Roger schrieb: > Er darf nur nicht in der Lage > sein, diese Funktionalität anschließend selbst durchzuführen. D.h. dass > dein Bootloader irgendeinen kryptographischen Schlüssel benötigt, der > sicher im Gerät hinterlegt ist. Ist der Schlüssel nicht bekannt so kann > die Anwendung auch nicht entschlüsselt werden, ob man den Bootloader > kennt oder nicht. da aber der Bootloader an den schlüssel rankommt, kommt damit jeder an den Schlüssel ran der den Bootloader selber compilieren kann. Soetwas kann man nur mit Hardware verhindert z.b. TPM chip.
oszi40 schrieb: > Je mehr "echte" Kryptographie Du einbaust, desto mehr Tücken hast Du > später, wenn was nicht funktioniert. Verschlüsslung ist höchstens das > Sahnehäubchen wenn andere Vernebelungsaktionen keine Wirkung zeigen. > Bevor ich mir Sorgen um einen Kopierschutz machen würde, wäre mir eine > sichere Funktion und Selbstdiagnose wichtiger. Ich hoffe, dies ist ein schlecht gemachter Trollbeitrag. Peter II schrieb: > da aber der Bootloader an den schlüssel rankommt, kommt damit jeder an > den Schlüssel ran der den Bootloader selber compilieren kann. > > Soetwas kann man nur mit Hardware verhindert z.b. TPM chip. Das sehe ich anders. Allein die Kenntnis des Bootloaders nützt dir exakt gar nichts, du brauchst mindestens noch einen authentischen Schlüssel. Wo der Bootloader den herkriegt steht auf einem anderen Blatt. Nur weil ich einen AES für AVR kompilieren kann heißt das noch lange nicht, dass ich jedes AES-Chiffrat knacken kann.
Roger schrieb: > Wo der Bootloader den herkriegt steht auf einem anderen Blatt. das ist doch aber genau der Punkt. Wenn der Bootloader da rankommt, dann kommt auch jeder andere da ran.
Peter II schrieb: > Roger schrieb: >> Wo der Bootloader den herkriegt steht auf einem anderen Blatt. > > das ist doch aber genau der Punkt. Wenn der Bootloader da rankommt, dann > kommt auch jeder andere da ran. Zumal im Open-Source-Quelltext des Bootloaders ja drinsteht, wie man an den Schlüssel kommt. Einziger Ausweg: der Schlüssel steckt im Prozessor selbst, und der Prozessor bootet auch nichts anderes außer den vorgesehenen Bootloader (insbesondere kein Schlüsselverrateprogramm). Womit wir wieder in der Kategorie Spielkonsolen- und Handyprozessoren wären, die man nur in großen Stückzahlen und gegen NDA bekommt. Und das NDA verhindert dann die Verwendung von Open Source. Ich denke, das Grundproblem ist, daß ein Schlüssel und der Prozessor(+Software), der ihn benutzt, nicht voneinander getrennt sein dürfen, sonst bleibt der Schlüssel nicht geheim. Also braucht man so etwas wie eine Chipkarte, d.h. einen lesegeschützten µC, der den Schlüssel (oder ein sonstiges Geheimnis) enthält und bei Bedarf benutzt, aber nicht herausgibt. Solange dieser µC nicht auszulesen geht, geht er auch nicht zu kopieren. Jetzt muß man nur noch die Applikation von diesem µC abhängig machen, dann ist sie auch kopiergeschützt. Dazu kann man allerlei Verschlüsselung zu verwenden versuchen, aber einfacher ist es, wenn zentrale Teile des Algorithmus (eine wichtige Formel oder Tabelle z.B.) im µC ablaufen.
Michael O. schrieb: > Die von mir geschriebene Software (kompilat) würde sowieso nicht auf > open-source code basieren sondern ist meine eigene Leistung. Inklusive aller Libs? wendelsberg
Michael O. schrieb: > und gleichzeitig einen Schutz gegen ungewünschtes Kpieren der > Software zu erreichen. Und zu welchem Zweck, bittesehr? a) du willst damit Geld machen? b) du tust was Verbotenes und willst nicht erwischt werden? Im ersten Fall: mach deine Hardware so preisgünstig, daß einer eventuellen Konkurrenz keine Lust aufkommt, dich zu unterbieten. Verkauft wird das Gerät und nicht die Bits im Speicher. Falls du aber glaubst, daß dein selbstgeschriebenes Programm so unsäglich wertvoll ist, dann irrst du halt. Alles kostet eigentlich ein bissel weniger, als es die Konkurrenz anbietet. Im zweiten Falle: laß es einfach bleiben. W.S.
W.S. schrieb: > Und zu welchem Zweck, bittesehr? > a) du willst damit Geld machen? Mir geht es um die prinzipielle Machbarkeit mit dem Hintergedanken ein Produkt zur erstellen. Ein gedachtes Produkt z.B. würde aus mehreren fertigen Geräten plus einem Controllerboard (z.B. auf Linux Basis) mit der Steuerungsintelligenz bestehen. Da die Fertigteile frei beziehbar sind, ist mein Wunsch wenigstens die Steuerungssoftware (die das wesentliche KnowHow darstellt) gegen Kopieren zu schützen. W.S. schrieb: > Im ersten Fall: mach deine Hardware so preisgünstig, daß einer > eventuellen Konkurrenz keine Lust aufkommt, dich zu unterbieten. Dann bleibt aber auch nichts übrig und ich müsste direkt mit gigantischen Stückzahlen anfangen. Stichwort Risiko...
Ein Kopierschutz bringt noch keine Kunden. Mehr Kunden bekommt man durch besseren Service. Daher scheint es mir wichtiger, eine funktionierende Serviceadresse anzuzeigen, als irgendwelche Kopierschutzversuche, die einen selbst noch ein Bein stellen können.
oszi40 schrieb: > Ein Kopierschutz bringt noch keine Kunden. Mehr Kunden bekommt man durch > besseren Service. Daher scheint es mir wichtiger, eine funktionierende > Serviceadresse anzuzeigen, als irgendwelche Kopierschutzversuche, die > einen selbst noch ein Bein stellen können. Absolut richtig. Aber die dumm-dreiste Kopie möchte ich gerne verhindern. Wenn jemand das nachentwickeln möchte ist für mich kein Thema. Beim uController packe ich die Applikation in den internen Flash und verbiete das Zurücklesen. Das reicht mir als Schutz. Hier geht es mir darum auszuloten, wie das bei einem Prozessorsystem mit Linux geht, was ich dafür tun müsste und welche Fallstricke da lauern können.
Parallelen Flash nutzen und die Datenleitungen (eventuell auch die Adressleitungen) verdrehen. Beim Auslöten und Auslesen kommt Kauderwälsch raus.
Mikkael schrieb: > Parallelen Flash nutzen und die Datenleitungen (eventuell auch die > Adressleitungen) verdrehen. Beim Auslöten und Auslesen kommt > Kauderwälsch raus. und wen soll das stören? dann schreibt man den Kauderwälsch in einen neuen Flash und baut die schaltung 1:1 nach und schon geht wieder alles.
Peter II schrieb: > und wen soll das stören? dann schreibt man den Kauderwälsch in einen > neuen Flash und baut die schaltung 1:1 nach und schon geht wieder alles. Das geht aber nur wenn er wirklich 1:1 nacbaut! Dazu muss er die Multilayer (anderst macht ARM keinen Sinn) mindestens röntgen. Warscheinlicher ist aber er designt das Board nach als die Leitungen 1:1 nachzuzeichnen...
Mikkael schrieb: > Warscheinlicher ist aber er designt das Board nach als die Leitungen 1:1 > nachzuzeichnen... Faule Leute machen das 1:1, andere überlegen 5 Minuten nachdem sie den Chip ausgelesen haben, daß dieser Code so nicht funktionieren kann und suchen ein paar Zeichen nach der Häufigkeit...
> Aber die dumm-dreiste Kopie möchte ich gerne verhindern.
Wenn ich das so richtig sehe, möchtest du dummdreist die Arbeit von
tausenden Linux Entwicklern als Kopie verwenden ohne irgendetwas dafür
zurückzugeben.
Aber ein eigenes Betriebssystem zu entwerfen und zu schreiben ist dir zu
viel Arbeit, du hast keinen Respekt vor der Arbeit anderer und willst
die nur abziehen.
Typisches gieriger Saftsack, die asozialen Abzocker die unsere
Gesellschaft so hervorbringt.
Vielen Dank an eure - fast immer - konstruktiven Beiträge. Da ich bisher mit Linux noch nicht gearbeitet habe, kenne ich auch die typischen Fallstricke und Probleme des OpenSource nicht. Mir scheint die Prozessorarchitektur mit externem Speicher ist ungeeignet, um einen vernünftigen IP-Schutz zu erreichen. Die Klimmzüge mit irgendwelchen externen HW-Bausteinen scheinen auch nur partiell sicher zu sein. Ich denke es wird aussreichen meine eigene Applikation mit einem Lizenzschlüssel gebunden an die HW ID zu sichern. Mehr macht viel Aufwand und bringt aber nicht deutliche Sicherheit. Damit ist für mich das Thema abgeschlossen. @MaWin Deine erfrischende Art habe ich sehr vermisst.
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.