Hallo, ich schreibe derzeit meine Diplomarbeit. Das Thema ist die Entwicklung eines Kopierschutzes für Entwicklungsbibliotheken. Diese wurden von der Firma, bei welche ich die Dipl. Arbeit schreibe, erstellt, und sollen nun zusammen mit einer Hardware verkauft werden. Damit sollen die Käufer in der Lage sein auf Basis dieser Hardware und der Bibliotheken eigene Entwicklungen durchzuführen. Die Hardware ist im wesentlichen ein AT91SAM7A3 (+ zusätzliche Beschaltung). Der Kopierschutz soll sicherstellen, dass die Bibliotheken wirklich nur auf der Hardware funktionieren. Mein Ansatz ist einen zusätzlichen IC auf die Leiterplatte zu bringen, welcher von der Bibliothek abgefragt wird. Jedoch können diese Abfragen durch disassembling leicht entfernt werden. :-( Eine zweite Idee ist, z.B. Berechnungen in diesen IC auszulagern, welche für die Funktionalität der Bibliotheken wichtig sind. Jedoch verlangsamt sich dadurch die Programmausführung so stark, dass auch diese Idee inakzeptable Nachteile mit sich bringt. :-( Die dritte Idee war dann, Teile der Bibliothek verschlüsselt abzulegen und diese durch den Dongle entschlüsseln zu lassen. Die entschlüsselten Teile wollte ich dann im RAM des AT91 ablegen. Dies bringt mich aber auch nicht weit, weil sich dies durch debuggen leicht erkennen lässt und ein auslesen des RAM auch problemlos möglich ist. :-( ----------- Hat vielleicht jemand schonmal eine ähnliche Aufgabe gehabt, oder noch eine Idee? Vielen Dank schonmal und viele Grüße rahu
die bib einfach opensource machen und gut is 8) immer diese geheimnistuerei...
naja, ganz so einfach ist das auch nicht immer. Es gibt tatsächlich Software, in die Mannjahre Entwicklungsarbeit geflossen sind. Und es gibt Unternehmen, die müssen ihre Softwareentwickler dafür bezahlen. Ebenso gibt es Unternehmen, die müssen diese vorgestreckten Kosten irgendwie wieder hereinbekommen, sonst trägt sich das Geschäftsmodell nicht oder man geht sogar pleite. OpenSource ist ne schöne Sache, geht aber nicht immer und überall. Ne gute Idee habe ich im Moment aber auch nicht.
> die bib einfach opensource machen und gut is 8) > immer diese geheimnistuerei... danke für diese super idee! aber wenn du bedenkst, dass in diesen Bibliotheken viele Jahre Arbeit stecken, wirst du verstehen, dass die Firma daran auch etwas verdienen will...
Wäre es nicht sinnvoller, erstmal eine Diplomarbeit über die Unsinnigkeit eines solchen Vorhabens zu schreiben? Z.B. worin siehst Du den Kundenkreis für so ein Produkt? Wenn es ein Entwicklungsboard sein soll, worauf jemand entwickeln soll, dann hilft es nichts, Du mußt alle Quellen offenlegen. Ansonsten kauft das einfach keiner. Oder es soll ein ausgereiftes Produkt sein, wie z.B. eine SPS, wo der Anwender nur seine Applikationen darauf entwickelt. Peter
Hallo Peter, der vergleich zu einer SPS ist nicht schlecht. Es handelt sich um eine universelle Steuerungseinheit, welche vorangig im Landmaschinensektor eingesetzt werden soll. Landmaschinen unterhalten sich über einen ISOBUS (Protokoll), und dieser Standart ist in einer Bibliothek implementiert (viele Jahre arbeit). Der Kundenkreis sind somit vorallem Landmaschinenhersteller. Der Kundenkreis besteht auch, da die Firma auf Messen immer wieder danach gefragt wird. Viele Grüße
Du versuchst dieselbe Quadratur des Kreises zu lösen wie die Musikindustrie: man soll eine CD/DVD ja bitteschön auslesen können, um sie sich abzuspielen, aber man soll sie auf keinen Fall auslesen können, wenn man die Absicht hat, die Daten zu duplizieren. Das kann nicht funktionieren. Ansonsten kannst du gucken, was all die Leute mit ihren Kopierschutz- Dongles seinerzeit so schon durch hatten.
Man kann übrigens selbst Opensource verkaufen. Gerade kommerzielle Anwender kommen um den Kauf von Lizenzen nicht auf Dauer herum, da ansonsten ihre eigenen Produkte ja rechtlich auf wackeligen Füßen stehen würden. Verkauf von Supportleistungen ist ein anderes Gebiet. Du musst es dem Kunden einfach unattraktiv machen, mit einer nur geklauten Version zu arbeiten. Letztlich kostet den Kunden ja eine Stunde eigener Arbeit auch ein nicht unerhebliches Sümmchen. Das Problem derartiger Kopierschutzmethoden hat sich schon bei den berüchtigten Dongles seinerzeit gezeigt: die Kunden, die deine Software legal erworben haben, müssen Aufwand dafür in Kauf nehmen (finanziell, bspw. in Form von Zusatzgeräten, erhöhter Supportbedarf durch Probleme mit dem Kopierschutz etc.), nur damit diejenigen ausgebremst werden können, die sowieso keine müde Mark für die Software bezahlen wollen. Das ist einfach ungerecht, und es kann einem Kunden ein ansonsten gutes Produkt gehörig vermiesen.
> Du versuchst dieselbe Quadratur des Kreises zu lösen wie die > Musikindustrie: Nun ja, was soll ich machen? Hab das Thema nun mal. Das Ziel ist auch nicht unbedingt die Bibliotheken 100% zu schützen. Es soll dem 'Feind' lediglich so viel Aufwand gemacht werden, dass er mit den gekauften Bibliotheken billiger produzieren kann. > Ansonsten kannst du gucken, was all die Leute mit ihren Kopierschutz- > Dongles seinerzeit so schon durch hatten. Hast du da vielleicht eine gute Seite (außer google) / Buch? Finde leider nur Informationen zu Dongles im PC - Bereich. zu deinem 2. Beitrag: kein schlechter Ansatzpunkt. Klar gibt es das Urheberrecht, nur wie soll man es einem Nutzer einer nichtlizenzierten Betrieb nachweisen, dass a) sein Produkt Funktionen aus der Bibliothek verwendet b) er wirklich keine Lizenz besitzt (eine Lizenz muss er ja kaufen) Bei meinen bisherigen Überlegungen habe ich natürlich auch darauf geachtet, wie stark es einen zahlenden Kunden einschränken würde. Ist durch ein Sicherungsverfahren eine starke Einschränkung zu erwarten, z.B. weil eben kein Debugging mehr möglich ist, wird dieses nicht eingesetzt. Wie schon gesagt, das Ziel ist es maximalen Schutz bei minimaler Beeinträchtigung zu erreichen. Wenn dieser maximale Schutz dann eben darin besteht, dass der Bibliothek beim Initialisieren mal "Hallo Dongle" sagt, und der Dongle mit "Hallo Bib" antwortet,...
Ralf H. wrote: > Hallo, > > ich schreibe derzeit meine Diplomarbeit. Das Thema ist die Entwicklung > eines Kopierschutzes für Entwicklungsbibliotheken. Diese wurden von der > Firma, bei welche ich die Dipl. Arbeit schreibe, erstellt, und sollen > nun zusammen mit einer Hardware verkauft werden. Naja... halte ich wenig davon. Moeglich ist es allerdings schon. Das geht dann aber in den Bereich Kryptographie hinein. Und so einen Schutz wirklich effektiv zu machen ist schwierig. Da finde ich gibt es wesentlich interessantere Themen auf dem Gebiet. Durch die enorm gesteigerte Komplexitaet der Software fuehrst Du auch zusaetzliche Fehlerquellen ein, die schnell zum Kompletten Erliegen des Systems fuehren koennen => Quaelitaetsproblem, Wartungsaufwand. Wenn die Maschine sowieso komplett verkauft wird, wieso dann auf das Schliessen von Bibliotheken konzentrieren, das ist doch dann sowieso Unsinn. Das wuerdest Du machen wenn Du die Bibliothek verkaufen willst. Wenn ich als Hersteller die Wahl zwischen einer OSS-Loesung und einer proprietaeren habe, suche ich auch erstmal bei den offenen. Das liegt oft auch daran, dass die schlicht und ergreifend besser gepflegt werden, zumindest bei den grossen Projekten wie z.B. Apache. Die Loesung wuerde in einem Challenge-Response-Verfahren und public key cryptography liegen. Solange der geheime Schluessel sicher verwahrt ist (z.B. in einem nicht auszulesendem EEPROM), hilft auch das debuggen nichts. Das ganze muss man dann ab und zu wiederholen. Naja wie gesagt... Wie oben schon geschrieben wurde: Ich glaube nicht, dass es bisher ein wirklich effektives Kopierschutzverfahren gegeben hat. Du vermiest lediglich dem Kunden, der das Produkt benutzen soll, die Arbeit damit. Das ist ein Pro und Kontra. Ausserdem denke ich dass gerade heute solche Aktionen generell nicht mehr auf sehr positive Resonanz stossen werden, man denke an die "kopiergschuetzten" Audio-CDs usw., die lachhaften versuche, BlueRays zu schuetzen. Was hat man davon? Man braucht drei mal mehr Rechenleistung als noetig waere durch den starken Cipher, geknackt war das Ding durch falsche Anwendung schon bevor das Zeug auf dem Markt war. Michael
@Ralf: Das geht nur, wenn der Controller einen Schlüssel sicher speichern kann und die Firmware mit einem sicheren Verfahren verschlüsselt wird. Und das kann der Controller nur, wenn er internes ROM hat, das man gegen auslesen sichern kann. Alles was irgendwie extern angebunden ist, kann man abhören und leicht knacken.
> Hat vielleicht jemand schonmal eine ähnliche Aufgabe gehabt, oder noch > eine Idee? Du hast zwei Probleme: 1. Leute die auf unterster Systemebene faehig sind kannst du nicht auf diese Art gaengeln weil die zuviel Ahnung haben. Das klappt nur mit Windowsprogrammierern. 2. Solche Art Libaries fuer spezielle Systeme werden nur in sehr kleinen Stueckzahlen genutzt. Da wuerde ich es als Kunde einfach erwarten das da auch noch Fehler drin sind, einfach weil die Anwenderbasis zu gering ist als das jede Eventualitaet mal getestet wurde. Daher lege ich als Entwickler Wert drauf den Source zu haben, oder kaufe was anderes. Ich sehe also keine Loesung fuer dein Problem. Olaf
Man könnte das anders angehen, wenn man die Hardware ändern kann: Von einem Controller auf zwei umstellen. Einer, der die Bibliotheken enthält und auslesegeschützt ist, sozusagen als reiner Kommunikationscontroller, und einer, der vom Benutzer programmiert wird. Die Bibliotheken liegen dem Benutzer dann nur als über ihre Schnittstellen dokumentierte Black Box vor.
Eben. Source-Lizenz ausgeben gegen einen entsprechenden Preis. Firmen koennen es sich garnicht leisten, gegen solche Lizenzen zu verstossen, das koennte den Ruin bedeuten. Und warum auch tun. Und wer fuer die Software nichts bezahlen will, wird es auch nicht tun. Koperschuetze sind generell recht sinnlos und nur fuer Laien irgendwie brauchbar, z.B. bei Zockern oder sowas. Wir haben fuer unsere Software auch keinen Kopierschutz. OK wir machen teilweise sowas wie Code-Obfuscation das macht schon Probleme genug. Aber mit Dongels machen wir nicht rum, es gibt auch ueberhaupt keinen Grund dazu.
@Michael und thyristor: mit den Möglichkeiten der Kryptographie habe ich mich auch schon (ein wenig beschäftigt). Das Problem ist, das der SAM7 keinerlei Schutz gegen das auslesen von irgendwas bietet.... Somit ist alles was irgendwie ver- und entschlüsselt wird früher oder später zu lesen. :-( @Olaf: das erste Problem ist mir bekannt, das zweite interessiert mich eigentich nicht wirklich. wenn die chefs entschieden haben, dass es diese bibliotheken nur mit kopierschutz geben soll dann sollen sie einen kopierschutz bekommen. wenn sie dann keine verkaufen ist das primär nicht mein problem.
@Sebastian: Die Hardware kann (und soll) ich ändern. (denn den Dongle gibts noch nicht) Dein Vorschlag hat zwei Nachteile, welche man aber möglicherweise lösen kann: 1) er verlangsamt die Ausführung (10Byte brauchen auch über SPI ne weile) 2) wie updaten? @Michael: Sie können es sich vielleicht nicht leisten komplett gegen diese Lizenz zu verstoßen. Aber mal angenommen sie lizenzieren jeden zweiten. Wie willst du denen das Nachweisen? Das Ding fährt im Traktor übers Feld...
Früher hat man bei einer Diplomarbeit den Stand der Technik recherchiert und dann seine Strategie entwickelt (was durchaus ein paar Wochen Arbeit bedeuten kann). Dann hat man die praktischen Arbeiten durchgeführt und anschliessend alles zusammengeschrieben und bewertet. Dann hat man eine Erklärung dazu verfasst, dass man die Arbeit selbstständig ausgeführt hat und alle Quellen ordnungsgemäß angegeben hat. Heute postet man das Thema anscheinend in einem Forum raus und lässt sich Stand der Technik von anderen zusammensuchen und Strategie von anderen entwickeln ;-(
Dann fang doch mal mit der Definition von "Kopierschutz" an. Was soll erreicht weden? Soll das Ding geheimdienstmässigen Entschlüsselungsmaßnahmen widerstehen, oder soll ein einfaches Kopieren auf eine andere Hardware zumindest etwas erschwert werden? Oliver
Ralf H. wrote: > @Michael und thyristor: > > mit den Möglichkeiten der Kryptographie habe ich mich auch schon (ein > wenig beschäftigt). Das Problem ist, das der SAM7 keinerlei Schutz gegen > das auslesen von irgendwas bietet.... Dann ist er fuer diese Anwendung auch nicht geeignet. Das wundert mich allerdings wenn ich bedenke dass sowas sogar bei den kleinen AVRs moeglich ist.
@ Stefan: Ich kann dir gerne die meine bisherirgen Recherchen zuschicken. Sind so etwa 30 DIN A4 Seiten, schriftgröße 10. Vielleicht verstehst du aber, dass ich diese 30 Seiten hier nicht als einleitenden Text posten kann! Und ich sehe auch nix verwerfliches daran, über die Realisierungsmöglichkeiten mit mehr als 2 Leuten zu diskutieren! @ Oliver: Das Ziel ist, zu 'verhindern', dass die Bibliotheken auf einer anderen Hardware funktionieren.
Michael G. wrote: > Dann ist er fuer diese Anwendung auch nicht geeignet. Das wundert mich > allerdings wenn ich bedenke dass sowas sogar bei den kleinen AVRs > moeglich ist. Er ist aber nun mal drin. Und daran kann (und will) ich nicht unbedingt was ändern. Da soll es lieber ein geringerer Schutz sein.
Ralf H. wrote: > Das Ziel ist, zu 'verhindern', dass die Bibliotheken auf einer anderen > Hardware funktionieren. Da hilft nur das verdongeln mit einem geheimen Schluessel. Wenn man den Schluessel nicht geheim halten kann brauchst hier garnicht weiterdenken.
Michael G. wrote: > Da hilft nur das verdongeln mit einem geheimen Schluessel. Wenn man den > Schluessel nicht geheim halten kann brauchst hier garnicht weiterdenken. Man könnte ja den Schlüssel geheim halten: Wenn die Bibliotheken auf dem Entwickler-PC verschlüsselt und vom Dongle entschlüsselt werden. Das blöde ist halt nur, dass die dann trotzdem irgendwo im Klartext im RAM rum liegen und sich jeder auch noch so unfähige Windows - Nutzer davon ein Abbild ziehen kann.
Ich glaube Du hast mich nicht ganz verstanden... das, was im RAM rumliegt, ist fuer die Entschluesselung nicht wesentlich. Dass natuerlich auf Prozessorebene Code nicht verschluesselt sein kann sollte Dir klar sein, hoffentlich.
Scheinbar habe ich dich wirklich nicht verstanden. Ich habe verstanden: 1) Bibliothek wird als (teilweise) verschlüsselter Maschinencode ausgeliefert 2) Bei der Ausführung verschlüsselter Funktionen, werden diese vom Dongle entschlüsselt und zurück zum Hauptrechner gesendet, wo sie im RAM, Flash abgelegt werden 3) Jeder kann sich fröhlich die Entschlüsselten Funktionen ansehen.
Hi, sieh' zu, daß Du eine Softcoreversion des Controllers (oder eines kompatiblen) bekommst und alles in einem FPGA u.ä. unterbringt. Dann gibt es keine externen Schnittstellen, die abhört werden können und der Aufwand an die Innereien zu kommen ist schon recht hoch. Letztlich ist auch das zu knacken. In der letzten ct kannst Du nachlesen, wie ein Chip zerlegt und analysiert wird. mfg Nucor
Besorg dir die aktuelle c't (Nr. 8/08) und lies den Artikel Bezahlkarten geknackt Dann weißt du, auf wie verlorenem Posten man selbst bei Hardware-Implementierung solcher Schutzmechanismen kämpft... Aber zum Problem selbst: 1. Die Lib ist für Entwickler gedacht. Daraus folgt, daß es - selbst wenn das Geschäft brummt - nur eine ganz beschränkte Zahl von Nutzern gibt. Und die haben zumindest potentiell die Mittel, auch den besten Kopierschutz zu knacken. Da hilft auch die Kryptographie nicht viel, denn es wird sich für den Experten immer eine Möglichkeit bieten, verschlüsselte Code-Teile irgendwann im entschlüsselten Zustand abzugreifen - verschlüsselt laufen die nun mal nicht. (Von - noch so raffinierten - Dongles, die letztlich irgenwo im Programm das entscheidende Bit 'Du darfst' setzen, brauchen wir gar nicht zu reden...) 2. Konsumenten der mit Hilfe der Lib produzierten Geräte sind Nicht-Fachleute auf dem Gebiet der Computerei. Für die reicht meistens schon die Schar am Pflug als Dongel für den Controller aus. Daraus folgt: Selbst wenn die Landwirtschaftscontroller der Renner werden - die Karten des Kopierschützers sind extrem schlecht. Allerdings solltest du dir mal folgende Idee genauer durchdenken:
1 | Die Kopien der Lib, die an Kunden verkauft werden, werden markiert - |
2 | z.B. indem man gewisse Codeblocks in Funktionen permutiert und eine |
3 | Möglichkeit schafft, diese Permutationen in eine Zahl umzucodieren, |
4 | die eindeutig einer Kopie der Lib zugeordnet ist. (Das läßt sich |
5 | sehr elegant über ein Zahlensystem mit der Stellenwertigkeit n! |
6 | bewerkstelligen, aber das nur am Rande...) |
Man könnte dann zumindest Endprodukte der Lib untersuchen und herausfinden, auf welchem Weg die Entwickler zu ihrer Kopie gekommen sind. Der Preis wäre allerdings, daß jede Kopie einzeln generiert werden muß.
Ralf H. wrote: > Sie können es sich vielleicht nicht leisten komplett gegen diese Lizenz > zu verstoßen. Aber mal angenommen sie lizenzieren jeden zweiten. Wie > willst du denen das Nachweisen? Das Ding fährt im Traktor übers Feld... Andere Lizensierungsmodelle suchen. Für jeden Kunden einen Preis nach seinem Produktionsvolumen oder sowas.
@ Nucor: Aha... man hat also bei einem FPGA keine Möglichkeit an die Innereinen zu kommen?? Das ist mir sehr neu. Der 'Inhalt' eines FPGA ist doch was relativ flüchtiges, muss also beim starten aus einem Flash o.ä. geladen werden. Einfach den Flash kopiert und schon juhu hat man ganz umsonst das Hardwarlayout umgestellt, einen teureren FPGA verbaut,... @ Uhu Uhuhu: Vielen Dank für diesen Denkansatz. Das Problem, ist allerdings nach wie vor folgendes: - es wird eine Lib gekauft, dazu vielleicht 100 Hardwarerohlinge. - nun baut der Kunde die Hardware 1:1 nach und spielt die selbe Software drauf. - wie soll man nun unterscheiden, ob die Lib die man da gerade eindeutig dem kunden zugeordnet hat, eine von denen ist, die lizenziert sind? man müsste diesen test bei allen geräten machen, die er in den letzten jahren ausgeliefert hat, und zählen ob er nicht mehr gaubt hat, als er lizenzen besitzt. (das sie zu dem Kunden gehört ist recht eindeutig auch daran zu erkennen, dass sein Name draußen dran steht)
Jörg Wunsch wrote: > Andere Lizensierungsmodelle suchen. Für jeden Kunden einen Preis nach > seinem Produktionsvolumen oder sowas. Ich habe aber leider keine BWL studiert. Sollte schon eine technische Lösung werden...
Ralf H. wrote: > Das Problem, ist allerdings nach wie vor folgendes: > - es wird eine Lib gekauft, dazu vielleicht 100 Hardwarerohlinge. > - nun baut der Kunde die Hardware 1:1 nach und spielt die selbe Software > drauf. > - wie soll man nun unterscheiden, ob die Lib die man da gerade eindeutig > dem kunden zugeordnet hat, eine von denen ist, die lizenziert sind? > (das sie zu dem Kunden gehört ist recht eindeutig auch daran zu > erkennen, dass sein Name draußen dran steht) Ich glaube, da hilft nur eins: Sich über Krümelkram nicht den Kopf zerbrechen - bringt eh nichts ein - und bei erfolgreichen Produkten Stichprobenweise prüfen. Volumenlizenzen werden eigentlich nur in solchen Bereichen so interessant, daß sich Überwachung in klingender Münze lohnt. Ich hatte mal einen Kunden, der sein Softwarepaket absichtlich mit einem relativ einfach knackbaren Lizenzschlüsselsystem versehen hatte. Der Hintergedanke war pfiffig: Diejenigen, die die Software knackten, wollten meistens eh nicht das Geld ausgeben, das sie kostete. Wenn sie aber beim knacken Erfolg hatten und zusätzlich dann vom Programm begeistert waren, war das letztlich eine hervorragende Werbung, denn diese Vögel behielten das natürlich nicht für sich. Landwirte denken da aber sicher etwas anders.
> Die Kopien der Lib, die an Kunden verkauft werden, werden markiert Was man digitales Wasserzeichen nennt. Eine der vielen Ideen, die in der Praxis durchgefallen sind. > Man könnte dann zumindest Endprodukte der Lib untersuchen und > herausfinden, auf welchem Weg die Entwickler zu ihrer Kopie gekommen > sind. Was potentiellen, legalen Käufern Angst macht, da sie befürchten müssen, dass wenn ihre legal erworbene Bibliothek ohne eigenes Zutun in fremde Hände gerät, sie dafür haftbar gemacht werden. Nur kann man im normalen Betrieb nicht 100% ausschließen, dass etwas mal abhanden kommt. Dinge verschwinden auf dem Transportweg, es gibt Einbrüche, Diebstahl, Computer werden geklaut oder geknackt. Vom bösen, bösen Mitarbeiter, der eine "Sicherheitskopie" mitnimmt ganz zu schweigen. Da bereits eine Kopie ausreicht um eine ganze Kopierindustrie zu füttern, ist der theoretische Schaden beim Verlust einer legalen Kpie extrem hoch. Das Risiko möchte kein Kunde eingehen. Fünf Minuten nicht aufgepasst und eine 50 Millionen Klage am Hals? Nein danke. Gib das Thema zurück, und denk beim beim nächsten Thema vorher nach, ob es sinnvoll ist. Ehrlich gesagt, wie kann man heutzutage durch ein Studium kommen und noch so blauäugig sein, wenn es um Kopierschutz geht?
Eine moeglich Loesung : Einen Bootloader, wobei die Bibiothek teil davon ist schon zu beginn weg reinpacken. Bootloadercode kann von der Applikation her nicht gelesen werden. Wobei ich solche Bibliotheken nicht benutzen wuerde. Was macht man im Fehlerfall ? Anrufen ? Emailsupport ? - Bei uns laeuft es. Ja, ja.
Ralf H. wrote: > @ Nucor: > > Aha... man hat also bei einem FPGA keine Möglichkeit an die Innereinen > zu kommen?? Das ist mir sehr neu. > > Der 'Inhalt' eines FPGA ist doch was relativ flüchtiges, muss also beim > starten aus einem Flash o.ä. geladen werden. Einfach den Flash kopiert > und schon juhu hat man ganz umsonst das Hardwarlayout umgestellt, > einen teureren FPGA verbaut,... Stand der Technik... http://www.google.de/search?hl=de&q=%22ip-schutz%22+fpga&meta= Dass du bereits 30 Seiten recheriert hast, geht aus deinem OP nicht direkt oder indirekt hervor. Sorry, wenn ich dir Unrecht getan habe.
>Das Problem, ist allerdings nach wie vor folgendes: >- es wird eine Lib gekauft, dazu vielleicht 100 Hardwarerohlinge. >- nun baut der Kunde die Hardware 1:1 nach und spielt die selbe Software >drauf. Wenn der Kunde die Hardware 1:1 nachbaut, verstösst er sowieso gegen Urheber- und sonstige Rechte. Wer so etwas kann, knackt auch jeden praktikablen Kopierschutz. Macht eine Mischkalkulation, und fertig. Oder verkauft ein Entwicklungssystem, welches den größten Teil der Softwarentwicklung abdeckt, und macht die lib so billig, daß es sich nicht lohnt, die zu knacken. Oder, oder. Nur blöd für deine Diplomarbeit :-) Oliver
@ Uhu Uhuhu : Wie stellst dir das denn vor? Ich steh da bei der Verteidigung, der Prof fragt mich genau das und ich antworte "auch über sonen krümelkram hab ich mir nicht den kopf zerbrochen" ??? Und ich denke auch, das Kunden jetzt schon danach fragen obwohl sie noch nicht eine funktion verwendet haben spricht dafür, dass dieses produkt keine werbung benötigt. @ Norgan: deswegen soll es auch ein kopierschutz und keine kopierüberwachung werden @ 6644: BL kann beim dem Controller genauso ausgelesen werden wie alles andere auch. und was hilft das überhaupt? der kunde bekommt ja dann auch den Bootloader geliefert, kann ihn also auch auf seine eigene Hardware spielen. @ Stefan: da ich bisher (absichtlich) noch nicht daran gedacht habe den SAM7 auszutauschen, habe ich auch noch nicht über einen fpga nachgedacht. allerdings bin ich mir ziemlich sicher, dass die firma a) kein interesse hat die hardware zu ändern b) kein interesse hat für viel geld einen IP-Core zu kaufen c) kein interesse hat einen teuren FPGA einzusetzen
Norgan wrote: >> Die Kopien der Lib, die an Kunden verkauft werden, werden markiert > > Was man digitales Wasserzeichen nennt. Eine der vielen Ideen, die in der > Praxis durchgefallen sind. Offensichtlich hast du nicht verstanden, was ich gemeint habe. > >> Man könnte dann zumindest Endprodukte der Lib untersuchen und >> herausfinden, auf welchem Weg die Entwickler zu ihrer Kopie gekommen >> sind. > > Was potentiellen, legalen Käufern Angst macht, da sie befürchten müssen, > dass wenn ihre legal erworbene Bibliothek ohne eigenes Zutun in fremde > Hände gerät, sie dafür haftbar gemacht werden. Nur kann man im normalen > Betrieb nicht 100% ausschließen, dass etwas mal abhanden kommt. Dinge > verschwinden auf dem Transportweg, es gibt Einbrüche, Diebstahl, > Computer werden geklaut oder geknackt. Vom bösen, bösen Mitarbeiter, der > eine "Sicherheitskopie" mitnimmt ganz zu schweigen. Sorry, aber das ist doch blanker Unsinn. Da man aus prinzipiellen Gründen sowieso keine Möglichkeit hat, so ein Entwicklungswerkzeug gegen Kopie zu schützen, schafft man sich wenigstens die Möglichkeiten, hinterher illegalen Gebrauch der Lib nachweisen zu können. > Gib das Thema zurück, und denk beim beim nächsten Thema vorher nach, ob > es sinnvoll ist. Ehrlich gesagt, wie kann man heutzutage durch ein > Studium kommen und noch so blauäugig sein, wenn es um Kopierschutz geht? Die Idee hat allerdings durchaus was für sich, denn das Thema, das er da bekommen hat, ist fast so ergiebig, wie Bauen Sie ein Perpetuum Mobile
Du sagst, Du schreibst die Diplomarbeit "bei der Firma". Ich dachte immer, Diplomarbeiten schreibt man an Hochschulen? Interessant ist auch der Aspekt, bei wem spaeter die Rechte fuer die entwickelte Hard- und Software liegen. Bei uns (Uni Kiel) ist das die Hochschule. Aber das kann von Bundesland zu Bundesland verschieden sein, Hochschulrecht ist Landesrecht.
Oliver wrote: > Wenn der Kunde die Hardware 1:1 nachbaut, verstösst er sowieso gegen > Urheber- und sonstige Rechte. Wer so etwas kann, knackt auch jeden > praktikablen Kopierschutz. Uhu Uhuhu wrote: > Die Idee hat allerdings durchaus was für sich, denn das Thema, das er da > bekommen hat, ist fast so ergiebig, wie Bauen Sie ein Perpetuum Mobile Zusammengenommen heißt das für mich jetzt das was ich mir auch schon dachte. Hilft mir aber nicht, da ich jetzt schon 3 wochen dran arbeite und keine Lust habe was neues anzufangen. Außerdem bietet dieses Thema viel Freiraum, und wenn ich als Ergebniss einen kopierschutz habe, bei dem ich begründen kann warum der so ist reicht mir das eigentlich auch. Wer sich jetzt fragt warum ich hier dann schreibe: Ich wollte einfach mal hören ob es nicht eine ganz einfache Lösung gibt, auf die ich nur nicht gekommen bin
Ich sehe bei der ganzen Kopierschutzdebatte um Software-Entwicklungswerkzeuge eine Contradictio in adjecto : Einerseits will man sein Werk so schützen, daß man selbst in den Genuß der Früchte seiner Arbeit kommt, andererseits hat dieses Schutzbestreben im frühen Stadium eines später hoffentlich einmal weit verbreiteten Produkts die Folge, daß der gewünschte Endzustand nie erreicht wird. Eagle ist ein schönes Beispiel: Zuerst versuchten sie, das Programm zu verdongeln - und verärgerten aus bekannten Gründen nur die Kunden, die zum Deckungsbeitrag beitrugen, während die unehrlichen auch noch kübelweise Spott über Cadsoft ausleerten. Dann gingen sie dazu über, beschränkte Freeware-Versionen bereitzustellen und plötzlich konnte jeder jugendliche Bastler mit dem Teil spielen - was mit ziemlicher Sicherheit bei ihm bleibende Eindrücke hinterläßt und womöglich sein späteres Kaufverhalten beeinflußt. Ich denke, so ein Modell ist das einzig sinnvolle für derlei Werkzeuge.
>Die Idee hat allerdings durchaus was für sich, denn das Thema, das er da >bekommen hat, ist fast so ergiebig, wie Bauen Sie ein Perpetuum Mobile In der Tat, das Thema ist ergibeig. Da wird ja auch immer noch gewerkelt. Da kommen die Leute auf einen Wirkungsgrad von 40% und glauben wenn sie die Maschine 10 mal groesser bauen waeren sie bei 400%. Dasselbe mit dem Kopierschutz. Ein Teilloesung anbieten, der Rest ist eine Kleinigkeit, machen wir spaeter. Das wird dann nie...
Oliver Rother wrote: > Du sagst, Du schreibst die Diplomarbeit "bei der Firma". Ich dachte > immer, Diplomarbeiten schreibt man an Hochschulen? Studiert habe ich an der HTW - Dresden, was eine Fachhochschule ist. Da kann man seine Diplomarbeit bei einer Firma schreiben. > Interessant ist auch der Aspekt, bei wem spaeter die Rechte fuer die > entwickelte Hard- und Software liegen. Beim Verfasser, wie immer, es sei denn der Diplomant wird bezahlt oder tritt freiwillig seine Rechte ab.
@ Uhu: freeware ist gut und toll, wenn man kunden locken will - aber wie locke ich einen kunden ist nicht mein thema. @ 6644: wahrscheinlich fehlen mit nen paar synapsen um zu verstehen was du da gerade von dir gegeben hast.
Ich wiederhole mal meine Frage von oben: Was soll der Kopierschutz denn eigentlich leisten? Soll er Bauern Hinrich davon abhalten, seinen zweiten Trecker per Notebook, aber ohne weiteres Hintergrundwissen, aufzurüsten, oder soll sich selbst ein Geheimdiesnt die Zähne dran ausbeissen? Um welche Stückzahlen geht es denn überhaupt? Oliver
Der Kopierschutz interessiert den Bauern überhaupt nicht. Der Kopierschutz soll verhindern, dass Landmaschinenhersteller, welche auf Basis der von meiner Firma entwickelten Hard und Software eigene Entwicklungen machen, diese in rauen Mengen produzieren und nur eine Lizenz besitzen. Stückzahl ist eine gute Frage :-) Jedoch sind es sicher nicht soviele, dass es sich für die Firma lohnt, mittels schwerer technik den rom eines dongles auszulesen um selber einen bauen zu können.
@ Ralf Ich kenne mich mit deiner speziellen Problematik nicht gut aus. Wenn du was über meiner Meinung nach gut kopiergeschützte FPGA lesen willst, solltest du dir mal den UG 332 von Xilinx reinziehen, speziell die Ausführungen zu Spartan 3A und Spartan 3AN. Damit sollte sich auf jeden Fall etwas machen lassen, was den Anforderungen deiner Diplomarbeit gerecht wird. Sinnvoll oder nicht, das Diplom muß gerettet werden!
Komische, wissenschaftliche Arbeitsweise hast Du da... Eine normale wissenschaftliche Arbeitsweise sieht so aus, dass das Ergebnis einer Forschung prinzipiell offen ist, da noch gar nicht bekannt ist, ob das Ziel überhaupt erreicht werden kann. Wenn Dein Brötchengeber einen Kopierschutz unbedingt will, soll er sich diesen Blödsinn selbst ausdenken und nicht noch öffentliche Gelder in Form einer Diplomarbeit dafür vergeuden. Mein kurzer Tip aus über 20 Jahren Softwareentwicklung zum Thema: Vergiss es!
wieso meinst du "öffentliche Steuergelder verbrauchen"? Die Firma hat ein (sinnvolles, aus der Praxis kommendes) Thema, benötigt einen Betreuer (in der Firma) und sorgt für die Ausstattung des Studenten. Die Hochschule hat den Professor, der gelegentlich mal drauf schaut, und den Prüfungsausschuss. Wo sind da öffentliche Mittel für die Firma verbraucht? Ausserdem hilft es auch der Hochschule, wenn dadurch andere Forschungsaufträge an den Prof herangetragen werden und damit einige Lehrmittel angeschafft werden, die sonst durch das Budget rutschen würden. Am Ende sind diese Industrieaufträge absolut wichtig für die Hochschulen und die Studenten.
jl wrote: > Ausserdem hilft es auch der Hochschule, wenn dadurch andere > Forschungsaufträge an den Prof herangetragen werden und damit einige > Lehrmittel angeschafft werden, die sonst durch das Budget rutschen > würden. > > Am Ende sind diese Industrieaufträge absolut wichtig für die Hochschulen > und die Studenten. Das alles sollte den Herrn Prof. aber nicht daran hindern, sich die Themen, die er an seine 'Schützlinge' weitergibt, vorher auf Plausibilität zu prüfen. Oder wollte er Ralf mobben?
Ohne wirklich jeden Beitrag gelesen zu haben: Schau doch mal bei "wibu" und "marx" rein, die machen Dongles und Kopierschutz. Vielleicht findest Du hier einen interessanten Hinweis / Idee.
> Gib das Thema zurück, und denk beim beim nächsten Thema vorher nach, ob > es sinnvoll ist. Ehrlich gesagt, wie kann man heutzutage durch ein > Studium kommen und noch so blauäugig sein, wenn es um Kopierschutz geht? Also mir hat einer meiner Profs mal gesagt, dass wenn man ein Thema hat und es nach Anwendung wissenschaftlicher Methoden nachweislich keine Lösung für das Thema gibt (kann auch mal vorkommen), muss man das nur in der Dokumentation (Schriftlichen Ausarbeitung) entsprechend Darstellen und hat die Aufgabe "Diplomarbeit" trotzdem gelöst. Wenn ein Forscher in der Realität an einer Problemlösung forscht und es nachweislich keine Lösung gibt, wird der ja auch nicht abgesägt. Man erwartet nur, dass diese Tatsache nachvollziehbar dokumentiert wurde. Bei FPGAs werden externe Flashspeicher mit Verschlüsselung eingesetzt, wenn der Inhalt wertvoll ist. Glaub das ist AES. Eine Dekoderhardware im FPGA und der Schlüssel in einem kleinen FLASH/ROM im FPGA erledigen die Decodierung der Konfiguration. Was digitale Wasserzeichen betrifft: Man muss ja nicht die Firma deren Name als Wasserzeichen kodiert wurde vor Gericht zerren (macht auch keinen Sinn - wie schon erwähnt "böser Mitarbeiter, etc.") Aber die Leute, die dann die Bibliothek einsetzen kann man dann eindeutig als "Unlizenziert" identifizieren! Und die haben dann ein kleines Problem. Das Frauenhofer Institut hat glauch ich ein Wasserzeichen entwickelt, dass man wohl nicht tot bekommt (allerdings für den Video/Audio bereich. Vielleicht lässt sich der für Programmcode zweckentfremden.
> Das Frauenhofer Institut hat glauch ich ein > Wasserzeichen entwickelt, dass man wohl nicht tot bekommt So ein Blödsinn. Es fordert nur etwa 5 Sekunden nachdenken um das als Marketinggewäsch zu entarnen und etwa 5 Minuten Arbeit um den Beweis dafür aus Papier zu schreiben.
So wie ich das sehe, wirst du nicht um einen zweiten Controller herum kommen der als Schnittstellenbaustein (Black Box) arbeitet. In den sauren Apfel musst du dann leider reinbeissen muessen, dass die Uebertragung von und zu diesem zweiten Controller etwas Zeit in Anspruch nimmt.
Ralf H. wrote: > Scheinbar habe ich dich wirklich nicht verstanden. > 3) Jeder kann sich fröhlich die Entschlüsselten Funktionen ansehen. Natuerlich kann man das. Das kannst Du aber auch nicht verhindern, weil die CPU Maschinentext nur im Klartext versteht. Und letztlich ist jeder Kopierschutz knackbar. Dein Argument mit dem "in Mengen produzieren" ist recht sinnlos. Das wird keine Firma tun. Und wenn doch kann sich Deine Firma freuen, die Schadenersatzsummen stehen dann naemlich in keinem Verhaeltnis zum tatsaechlichen Schaden.
sry hatte gerade mittagspause :-) danke an willi - ich werd mal sehen ob ich da was finde. @ Matthias: danke für die erklärung der verschlüsselung bei fpgas. wasserzeichen halte ich nach wie vor für wenig sinnvoll. ich glaube nicht dass ich irgendwann in einer tauschbörse die lib finde.... @ Christoph R.: die idee eines zweiten Controllers erscheint mir auch immernoch als die einzig wirklich sinnvolle. @ Michael: naja ich denke freuen wird sich meine firma dann auch nicht :-) (es bedeutet nämlich auch erstmal eine menge stress und (anwalts) kosten)
Wie wäre es mit einem Seriennummernbaustein? Die kann man mit fortlaufenden, individuellen Nummern kaufen. Die Bibliothek (oder ein weiterer kleiner Mikrocontroller auf der Platine) lässt dann nur einen bestimmten Nummernbereich zu. Von Maxim gibt es da einige ziemlich stark abgesicherte ICs.
Hmm die Beschreibung von dem Einsatzgebiet erinnert mich an eine SPS bzw an sowas wie C-Control... Gut wenn da jemand eigenen code auf die CPU schieben soll dann vergiss das mit dem FPGA erstmal... Nimm eine CPU mit einer MMU, spiel dort ein "Betriebssystem" drauf, und mach deine Library-Funktionen nur über SysCalls verfügbar.. dann konfigurierst du die MMU so, dass der User-Prozess (das Programm, das der Kunde einspielt) nicht auf den Kernel-Space(also dein Mini-OS und die Library) zugreifen darf.. wenn ers doch tut gibts eine Access-Violation und Reboot :) Dem Kunden musst du dann "nur" mehr sagen wie er seinen code zu generieren hat (linker scripts,...) und wie er auf deinen SysCalls zugreifen kann... Anders bekommst du das ganze sicher nicht halbwegs "sicher" und konfortabel für den Kunden hin... Aja wehe du klaust mir die Idee und schreibst in die Dipl-Arbeit nicht rein von wem sie ist g 73
> naja ich denke freuen wird sich meine firma dann auch nicht >:-) (es bedeutet nämlich auch erstmal eine menge stress und (anwalts) >kosten) Vielleicht fügst du deiner Diplomarbeit ein Kapitel an, in dem du darlegst, daß JEDER Kopierschutz knackbar ist, und sowieso keinen Sinn macht, wenn der Verkäufer nicht auch willens und in der Lage ist, einen unlizensierten Einsatz seiner Software zu überwachen und konsequent und in aller Härte dagegen vorzugehen. Und ja, das bedeutet jede Menge Stress und Anwaltskosten. Oliver
@ Hans: wenn mein Mikrocontroller eine MMU hätte würde ich hier nicht fragen -> hatter aber nicht ein zweite problem ist, dass die geschützen bereiche ja auch mal ein update bekommen sollen / müssen @ Mitbastler: wenn die lib dann disassembliert, der 'stimmt_die_sn_test' entfernt, und das ganze wieder in ein lib file verwandelt wird ist der 'schutz' schon weg @ Oliver: steht in kapitel 1, was ich glaub am 3. tag geschrieben hab :-) @ all: danke für eure ideen
Ein Kopierschutz, auch wenn er knackbar ist, macht Sinn. Zum einen wird der Knackende deutlich darauf hingewiesen, dass er etwas Verbotenes tut und man sich das nicht gefallen lassen wird. Zum anderen kostet das Knacken Geld und dann muss es billiger sein, die Bib zu kaufen (wurde bereits erwähnt). Und wenn das dann einer aus Spaß an der Freud knackt, dann soll er seine Freude haben, mit den Daten wird er eh nichts anfangen können.
Was hältst du denn von der Sache im Anhang? Nur um mal eine Anregung in den Raum stellen. Michael
Nö, du bist der Autor und hast alle Rechte eines Autors.
@ michael: danke für den tip. leider passt das aber nicht :-) mein µC kann die mac nicht kontrollieren, d.h. er kann es schon, aber da nimmst mal kurz nen disassebler löscht nen paar zeilen und übersetzt das wieder...
>aber da nimmst mal kurz nen >disassebler löscht nen paar zeilen und übersetzt das wieder... Dann lass es doch. Es gibt keine Möglichkeit, 100% zu verhindern, daß jemand mit Fachlkenntnissen, Disassembler, Logikanalysator, Real-Time-Emuluationshardware und unbegrenzter Zeit auf der angedachten Hardware jeden erdenklichen Kopierschutz knackt. Wenn ein 100% sicherer Kopierschutz deine Aufgabenstellung ist, gib die Arbeit zurück. Wenn du aber solche Sicherungen an so viele Stellen in deinem Programm einbaust, daß sich der Aufwand für den Hacker nicht lohnt, reicht das doch. Immerhin reden wir hier von angestellten Programmierern einer Firma. Das ist schon anders, als im PC-Bereich üblich. Da sind Hacker mit unbegrenzter Zeit am Werk, die das zum Teil als sportliche Herausforderung sehen. Die interessieren sich aber nicht für eine Trecker-ISO-Dingens-Lib. Oliver
@ Oliver: da hast du mich falsch verstanden (vielleicht hab ich mich auch falsch ausgedrückt) ich habe bereits eine reihe von möglichkeiten, welche ich in die bibliothek zum schutz einbauen kann (und werde). ich wollte damit nur sagen, dass die von michael vorgestellte lösung so angepriesen wird als wäre das unknackbar, was es jedoch in meinem fall nicht ist.
>@ Oliver: da hast du mich falsch verstanden (vielleicht hab ich mich >auch falsch ausgedrückt) Wird das hier jetzt zum Running-Gag? >ich habe bereits eine reihe von möglichkeiten, welche ich in die >bibliothek zum schutz einbauen kann (und werde). Was willst du denn noch mehr? >ich wollte damit nur sagen, dass die von michael vorgestellte lösung so >angepriesen wird als wäre das unknackbar, was es jedoch in meinem fall >nicht ist. Dreh dich doch nicht im Kreis, unknackbar gibts nicht. Da kannst du noch Jahre hier weiterbohren, viel mehr als das schon Geschriebene schaut dabei wohl nicht raus... Es soll eine Diplomarbeit sein, mit wissenschaftlichem Anspruch, oder? Also wäre sinnvoll, zu akzeptieren dass es keine ideale Kopierschutzmöglichkeit gibt. Man kann Vor- und Nachteile erörtern, das ist aber deine Aufgabe.
> Was willst du denn noch mehr? ich wollte einfach sichergehen, dass es nicht eine total billige lösung (setz doch einfach das compiler flag sowieso) gibt, auf welche ich einfach bisher nicht gekommen bin > Dreh dich doch nicht im Kreis, unknackbar gibts nicht. Da kannst du noch > Jahre hier weiterbohren, viel mehr als das schon Geschriebene schaut > dabei wohl nicht raus... das ist eigentlich auch schon alles was ich wissen wollte > Es soll eine Diplomarbeit sein, mit wissenschaftlichem Anspruch, oder? > Also wäre sinnvoll, zu akzeptieren dass es keine ideale > Kopierschutzmöglichkeit gibt. hab ich bereits seit langem akzeptiert _____ ich danke allen die sich beteiligt haben. von mir aus kann das thema geschlossen werden
bau ne GSM-Verbindung ein und lass Teile des Codes auf deinem Server laufen. :-)
und was mach ich wenn der traktor in hintersibiren fährt? in die faq schreiben dass er in soeinem fall auch ein netzwerkkabel nutzen kann?? :D
Hab ich das richtig verstanden: Du willst eine Softwarelösung die verhindert, das man sie Hardware nachbaut? Eigentlich sollte blos verhindert werden das die mit den Entwicklungswerzeugen erzeugter Code auf nachgebauter Hardware läuft oder?
> Du willst eine Softwarelösung die > verhindert, das man sie Hardware nachbaut? Nein. > Eigentlich sollte blos verhindert werden das > die mit den Entwicklungswerzeugen erzeugter Code > auf nachgebauter Hardware läuft oder? Ja.
Ein auch nicht wasserdichter Weg bestünde darin, daß ein Teil des genutzten Codes als verschlüsselter Binär-Block erst zur Laufzeit im Prozessor entschlüsselt wird, um danach aus dem RAM ausgeführt zu werden. Zur Entschlüsselung wird ein extern angeschlossener 1-Wire-Seriennummernbaustein von Dallas verwendet. Ohne diesen nur über Deine Firma zu beziehenden Baustein kann der Code nicht entschlüsselt werden (mal angenommen, der verwendete Algorithmus ist ausreichend wasserdicht). Sicherlich kann jemand mit ausreichend "krimineller" Energie den im Prozessor entschlüsselt vorliegenden Code aus diesem extrahieren, andererseits wäre es ja durchaus denkbar, daß zur Ansteuerung des Seriennummernbausteins just und nur Pins verwendet werden, die sonst das JTAG-Interface des Controllers zur Verfügung stellen; das dürfte das Debuggen zumindest ein kleines bisschen erschweren. Ein ganz anderer Ansatz: Der Code wird auf einer entsprechend geschützten SD-Card ausgeliefert, die im Zielgerät verwendet werden muss. Bei Vorliegen der korrekten Seriennummer wird der Code aus der SD-Card in das RAM des Zielprozessors geladen um dort ausgeführt zu werden. Um die Schutzmechanismen von SD-Karten nutzen zu können, muss man zwar Mitglied der SD-Card-Association werden, einen Haufen NDAs unterschreiben und auch sicherlich einiges an Kohle für Lizenzgebühren abdrücken, aber das dürfte den Code auch als Binärcodeblock nur denen zugänglich machen, die eine entsprechende SD-Card gekauft haben. Kopieren lassen sich geschützte SD-Karten nicht, jedenfalls ist das so vorgesehen. Das alles ist natürlich nicht wasserdicht, solange vorgesehen ist, daß auch fremder Code mit dem schützenswerten Code interagieren kann. Damit lässt sich immer ein Loch finden. Allerdings beschränkt dies die Verwendbarkeit des Codes auf die vom Codeersteller verwendete Hardware - verwenden denn alle Landmaschinenhersteller die gleichen ARM-Derivate? So eine Library für irgendein Protokoll ist für Entwickler eigentlich nur im Sourcecode wirklich interessant. Und den lieferst Du ja sowieso nicht aus.
Hallo Rufus. danke für deinen ausführlichen Beitrag! Rufus t. Firefly wrote: > Ein auch nicht wasserdichter Weg bestünde darin, daß ein Teil des > genutzten Codes als verschlüsselter Binär-Block erst zur Laufzeit im > Prozessor entschlüsselt wird, um danach aus dem RAM ausgeführt zu > werden. > Zur Entschlüsselung wird ein extern angeschlossener > 1-Wire-Seriennummernbaustein von Dallas verwendet. Dies entspricht einer Lösung, welche ich so ählich bereits kenne. (Nur die Dallas 1 Wire - Dinger kenne ich nicht). Das Problem ist, dass diese Entschlüsselung sicherlich Zeit benötigt, und dass bei diesem blöden ARM Ding auch der RAM debuggt werden kann. Die Keil IDE disassembled das dann auch gleich mit. > Ohne diesen nur über Deine Firma zu beziehenden Baustein kann der Code > nicht entschlüsselt werden (mal angenommen, der verwendete Algorithmus > ist ausreichend wasserdicht). > Sicherlich kann jemand mit ausreichend "krimineller" Energie den im > Prozessor entschlüsselt vorliegenden Code aus diesem extrahieren, > andererseits wäre es ja durchaus denkbar, daß zur Ansteuerung des > Seriennummernbausteins just und nur Pins verwendet werden, die sonst das > JTAG-Interface des Controllers zur Verfügung stellen; das dürfte das > Debuggen zumindest ein kleines bisschen erschweren. Ich weiß nicht in wie weit das Debuggen dann überhaupt noch möglich ist. Diese Funktionalität sollte jedoch erhalten bleiben. Aber der Gedanke ist gut - werde ihn mal weiter verfolgen. ;-) Die SD - Karten variante gefällt mir nicht wirklich. Bei alle dem muss dieses Gerät dann ja trotzdem noch diverese Tests bestehen (EMV, Temperatur, Vibration), sodass da eigenltich nix mechanisches verwendet werden kann. > Das alles ist natürlich nicht wasserdicht, solange vorgesehen ist, daß > auch fremder Code mit dem schützenswerten Code interagieren kann. Damit > lässt sich immer ein Loch finden. Naja das Loch muss nur so klein sein, dass die Lizenz billiger ist als das zu finden und zu nutzen. > Allerdings beschränkt dies die Verwendbarkeit des Codes auf die vom > Codeersteller verwendete Hardware - verwenden denn alle > Landmaschinenhersteller die gleichen ARM-Derivate? Sicherlich nicht, aber müssen sie dann wohl :-)
> Aber der Gedanke ist gut - werde ihn mal weiter verfolgen. ;-)
Noe, isser nicht. Wenn ich eine Libary in ein von mir geschriebenes
Programm einbinden kann, dann kann mein Programm auch eine Routine
enthalten die jederzeit mal ein komplettes Speicherabbild irgendwo
hin schickt. Man muss sich nicht die Muehe machen einen Debugger
anzuwerfen.
Olaf
Olaf wrote: > Noe, isser nicht. Wenn ich eine Libary in ein von mir geschriebenes > Programm einbinden kann, dann kann mein Programm auch eine Routine > enthalten die jederzeit mal ein komplettes Speicherabbild irgendwo > hin schickt. Man muss sich nicht die Muehe machen einen Debugger > anzuwerfen. > > Olaf wohl wahr. aber wohler willst du wissen, was von dem ganzen müll ist und was entschlüsselte routinen?
>> Eigentlich sollte blos verhindert werden das >> die mit den Entwicklungswerzeugen erzeugter Code >> auf nachgebauter Hardware läuft oder? >Ja Der weiss selber nicht, was er eigentlich will. Weiter oben schreibt er, das auch verhindert werden soll, daß jemand 100 mal die original Hardware kauft, aber nur eine lib Lizenz, und die dann auf allen 100 Steuerungen einsetzt. >Die SD - Karten variante gefällt mir nicht wirklich. Bisher gefiel dir gar kein Vorschlag. Also lass es doch einfach. Langsam wird es wirklich zu blöd. Also: 1.) Die Chinesen werden das Ding so oder so kopieren. 2.) Der Bauer in Sibirien kauft sowieso chinesisches Gerät. 3.) Am sichersten ist es, die Software gar nicht aus der Hand zu geben. 4.) Am besten vor Auslieferung löschen. Oliver
@Ralf: irgendwo werden die Routinen doch mal angesprungen, oder? Die einzige wasserdichte Möglichkeit wäre eine VM. Allerdings musst du dir bei der ganzen Sache eine unbequeme Frage stellen: warum sollte ein Entwickler Geld für eine Bibliothek ausgeben die ihn mit Kopierschutzmaßnahmen terrorisiert, wenn es doch sogar eine kostenlose Open Source-Bibliothek für die selbe Aufgabe gibt (http://www.isoaglib.org)? Ich sehe die Gefahr dass die Anforderungen für deine Aufgabe völlig an der Realität vorbei gehen und du für die Tonne entwickelst.
> warum sollte ein Entwickler Geld für eine Bibliothek ausgeben
Hehe..du darfst hier jetzt nicht mit Logic ankommen.
Ich wuesste sogar keinen Grund warum man sich nicht ein
Protokoll selber schreiben sollte. Ich hab bis jetzt noch nichts
gesehen das so kompliziert das man es nicht besser selber macht.
Sowas harmoniert dann naemlich viel besser mit dem eigenen Programm,
als wenn man sich den Zwaengen einer fremden Lib unterwerfen muss.
Garnicht davon zu reden das man sonst bei ernsten Problemen mit dem
Debugger vor dem geschlossenen Source steht und die Fehler nicht
findet, aber soweit waren wir ja schonmal....
Olaf
Mal abgesehen davon, ob es Sinn macht oder nicht: Es gibt moderne und preiswerte Speichermedien wie SD oder xD Speicherkarten, die eben genau dafür bereits Techniken implementiert haben, auch wenn diese keiner nutzt. Man muss also in Seiner Software ein Session-Key Verfahren implementieren, diesen Key mit der Karte austauschen und dann erst werden die Daten verschlüsselt übertragen und können in der CPU entschlüsselt werden. Weiterhin gibt es FLASH-Speicher, die die Informationen verschlüsselt ablegen oder welche, die sie sogar auf zwei Bausteine verteilen und nur diese beiden Bausteine zusammen funktionieren miteinander. ATMEL hat in einigen ARMx Systemen auch CryptoEngines implementiert, dazu gibt es die Option bei ATMEL Chips mit besonderen Seriennummern fertigen zu lassen. Diese können als Hash und Key bei z.B. AES verwendet werden. Damit kann der Bootloader im Klartext im Flash stehen, der Angreifer kommt an die Schlüssel nicht heran, da sie in der CPU sind. Der Rest der Software ist AES Verschlüsselt im FLASH. Paart man die Verschlüsselung bei der Produktion noch mit einer Verknüpfung aus Hash, Key und Seriennummer, dann bekommt jedes Board sogar binär unterschiedliche FLASHes. Letztendlich geht bei solchen Schutzmechanismen aber nie darum etwas wirklich geheim zu halten, sondern den Aufwand des Entschlüsselns so hoch zu treiben, dass es für Angreifer unrentabel wird. In Bezug auf Software ist es halt so, dass ich für 200.000 Euro Kosten Aufwand für Messmittel, Analyzer, Chipabschliff oder Platinen-Analyse auch 2 Entwickler ein Jahr lang beschäftigen kann, die etwas bauen dass vielleicht sogar besser ist als das super geschützte Konkurrenzprodukt. Der Vorteil ist dann, dass es völlig legal ist. Gruß, Ulrich
@ oliver: bitte lern (genau)lesen, dich zwingt keiner hier zu schreiben. außerdem solltest dich informieren bevor du hier was abläst. @Andreas: was meinst du wie es in bezug auf verwendbarkeit und vollständigkeit der opensource lib aussieht, wenn es bei meiner firma anfragen nach der lib gibt? @olaf: es ist ja nicht so, dass die lib in 5min mal eben schnell zusammengeschrieben werden kann. @ulrich: das es das alles gibt ist schön. nur leider kann ich den controller nicht wechseln :-) ich darf nur 'was dran bauen' und dass mit der bibliothek verflechten, sodass der aufwand das rückgänig zu machen entsprechend groß wird.
Wie wäre eine verschlüsselte Übertragung mit einem Key vom PC aus in nen zusätzlichen Flashspeicher. Der AVR enthält ein Minimalprogramm, welches zu Beginn den Flash mit dem verschlüsselten Programm ausliest und decodiert. Ist er fertig, führt er das Programm aus. Dabei sind im AVR die LOCK-Bits gesetzt. Nun die Frage: Kann der AVR selber in den Flash speichern, selbst wenn die Lock-Bits gesetzt sind??? Wäre ja optimal, da man die Decodiervorschrift nicht auslesen könnte und der Programmcode vollkommen Codiert in den AVR gelangt. Zudem kann der Key beliebig groß sein (mit entsp.Rechenzeit), da er die Daten bei Systemstart decodiert. P.S. Sorry, hab mir nicht alles durchgelesen. Nur ne Idee halt. Gruß Alexander
ohne oben alles gelesen zu haben: Es gibt ARMs mit secure core drin, da kommt man nicht an die libs ran. Ich weiss nciht, obs das auch schon bei arm9 gibt, auf jeden fall bei ARM11. VG, /r.
@ Alexander Liebhold: es ist ein arm. der hat keine securitybits @ random: es ist ein arm7, der hat sowas nicht :-) trotzdem danke euch beiden
Ralf: wenn ihr jetzt anfangt das Debugging zu erschweren und die Software an eine spezielle Hardware zu koppeln kann sich das ganz schnell ändern.
das debugging bleibt so wies ist - von den forderungen die ich mir gestellt habe ist dies eine. derzeit gehen meine überlegungen in die richtung, das weniger zeitkritische funktionen im dongle ausgeführt werden sollen. das ergebniss davon wird für den weiteren ablauf verwendet außerdem überlege ich, definierte werte, welche in botschaften benötigt werden zu verschlüsseln und den arm eine total sinnlose nachricht an den dongle senden zu lassen. erst der entschlüsselt das dann und schickst auf den isobus. das selbe andersrum.
>und den arm eine total sinnlose nachricht an den >dongle senden zu lassen. erst der entschlüsselt das dann und schickst >auf den isobus. >das selbe andersrum. Das ist dann im Endeffekt ein Kommunikationsprozessor. War schonmal da, ganz oben: >Autor: Sebastian (Gast) >Datum: 03.04.2008 10:14 geht aber nicht. Zitat: >@Sebastian: >Die Hardware kann (und soll) ich ändern. (denn den Dongle gibts noch >nicht) >Dein Vorschlag hat zwei Nachteile, welche man aber möglicherweise lösen >kann: >1) er verlangsamt die Ausführung (10Byte brauchen auch über SPI ne >weile) >2) wie updaten? Also zurück auf los, und weiterrätseln. Oliver
> @ oliver: > bitte lern (genau)lesen
@Ralf, leicht am Thema vorbei, aber nur ein kleiner Hinweis: Seit gestern Mittag versagt Deine Shift-Taste zunehmend. Mittlerweile scheint sie total defekt zu sein.
Ralf H. wrote: > @ulrich: das es das alles gibt ist schön. nur leider kann ich den > controller nicht wechseln :-) ich darf nur 'was dran bauen' und dass mit > der bibliothek verflechten, sodass der aufwand das rückgänig zu machen > entsprechend groß wird. Also zum Einen musst Du Dich entscheiden, ob Du nun etwas ändern darfst nur hunzufügen darfst oder was auch immer. Wenn ich das richtig in Erinnerung habe, gibt es den AT91SAM7X in einer Version mit und einer ohne CryptoCore. Das Pinning sollte nicht unterschiedlich sein. Kann aber auch sein, dass ich da was aus der Roadmap in Erinnerung habe und der CryptoCore erst noch kommt. Wenn der Aufwand des Reverse Engineerings aber nur möglichst hoch getrieben werden soll und zudem der Einsatz in schweren Automotive/Industrial Bedingungen eh ein Thema ist, dann vergießt das gesammte System doch einfach mit einer dafür vorgesehen vergussmasse ( diese gibt es in verschiedenen Sicherheitsstufen) und dann kommt keiner mehr an die Chips ran um dort ein reverse Engineering durchzuführen. Ein AES Algorythmus ist auch in Software nicht schwer nach zu bilden und in mehreren Geschmacksrichtungen und wenig aufwändigen Lizenzbedingungen im Netz verfügbar. So könnte man zumindest Teile der Software schützen ohne gleich das System unnötig träge zu machen. Durch das zusätzliche Anbringen eines weiteren Bauteils kann ich niemals meinen Code schützen, wenn Hash und Key in einem der beiden Angreifbaren Speicher im Klartext stehen. Wenigstens einer der beiden Teile muss irgendwo untergebracht werden können, wo ich ihn nicht mehr von außen erreichen kann. Wenn ich mir aktuelle Disassembler ansehe, dann ist es relativ leicht Datenmüll ( und das ist verschlüsselter Code) von richtigem Code zu trennen. Ein Auffinden der beiden Teilschlüssel ist damit sehr wahrscheinlich. Eine Sicherung findet also nur dann statt, wenn zumindest ein Schlüssel weder über Datenbus-Analyse noch JTAG auffindbar ist. Auch ein TPA Verfahren nützt Dir nichts, wenn die verschlüsselten Daten über einen von außen Erreichbaren Bus an einen Entschlüsseler geschickt werden, der diese dann entschlüsselt wieder über den Datenbus zurück an die CPU schickt. Allerdings wßürde dieses Verfahren immerhin den Reverse-Engineering Aufwand enorm erhöhen, da erst einmal die Dastenströme auf ein und dem selben Bus getrennt werden müssten. Aber jetzt mal zurück auf Anfang: Der SAM7A3 hat doch internen Flash. Dieser sollte doch gegen externes Auslesen zu schützen sein. Hier kann doch dann ein AES Loader untergebracht werden, der verschlüsselte Teile aus einem externen FLASH nachlädt. In diesem Flash kann man dann auch Hash und Key unterbringen. Dieser Teil kann auch eine Schutzfunktion beinhalten, die den externen FLASH auf eine Prüfsumme hin untersucht, damit ein Angreifer keinen Code einspeisen kann, der hinten herum ( über den Datenbus oder eine andere Schnittstelle) den internen FLASH auslesen kann. JTAG sollte man dann natürlich beim auszuliefernden Produkt deaktivieren. Damit musst Du überhaupt nichts anbauen außer einer kleinen Loader-Software. Gruß, Ulrich
"Damit sollen die Käufer in der Lage sein auf Basis dieser Hardware und der Bibliotheken eigene Entwicklungen durchzuführen." -> durchgefallen, wenn der Käufer Code ausführen kann funktioniert das alles nicht.
Ulrich, es geht dem Threadstarter nicht darum, einen fertig programmierten ARM vor dem Auslesen und Kopieren zu schützen, sondern darum, eine Library, die an andere Programmierer verkauft wird, vor dem Kopieren zu schützen.
Bitte erst informieren. Zitat http://de.wikipedia.org/wiki/Diplomarbeit: Nach dem Urheberrechtsgesetz (UrhG) erwirbt der Verfasser einer Diplomarbeit mit Anfertigung seiner Arbeit das alleinige Urheberrecht und grundsätzlich auch die hieraus resultierenden Nutzungsrechte wie z. B. Erstveröffentlichung (§ 12 UrhG), Verbreitung (§ 17 UrhG), Vervielfältigung (§ 16 UrhG), Online-Nutzung usw., also alle Rechte, die die nichtkommerzielle oder kommerzielle Verwertung betreffen. „Will die Hochschule [...] Rechte an Schutzrechten von Studenten oder Diplomanden erwerben, ist sie, wie jeder Dritte auf vertragliche Vereinbarungen mit den Studenten oder Diplomanden angewiesen“ Zitat http://www.uni-erlangen.de/universitaet/organisation/verwaltung/zuv/verwaltungshandbuch/drittmittel/Merkblatt_Diplomarbeiten_und_Dissertationen.pdf: Das Urheberrecht sowie die daraus resultierenden Verwertungs- und Nutzungsrechte stehen allein dem Diplomanden/Doktoranden als dem Verfasser der Arbeit zu. Die Universität, der Betreuer/Prüfer oder Dritte können Nutzungsrechte hieran nur erwerben, wenn der Verfasser ihnen solche einräumt. Eine Verpflichtung hierzu besteht nur dann, wenn sie vertraglich vereinbart wurde oder die Diplomanden/Doktoranden auch Arbeitnehmer der Friedrich-Alexander-Universität Erlangen-Nürnberg sind und die Arbeit im Rahmen der von ihnen arbeitsvertraglich geschuldeten Tätigkeit entstanden sind.
Wenn du eine ISO Bus-Implementierung (ich nehme mal an, du meinst ISO11783) für schützenswert hältst, dann komme ich ehrlich ins zweifeln... Schreibst du deine Dipl. Arbeit etwa für die Fa. Agrocom...?
@ Punktrichter: tschuldigung @ Ulrich P: Der SAM7A3 hat leider einen Flash der sich nicht schützen lässt. (Hatte ich das nicht schon erwähnt?) Und JTAG zu deaktivieren geht auch nicht, weil es soll ja weiterentwickelt werden. Ich glaube die Geräte werden sowieso vergossen, aber wenn sich Leute die Arbeit machen Gehäuse von EEPROM wegzuätzen und diese dann mit Microskopen auszulesen, dann hällt die auch vergussmaße nicht auf. (Ich gehe allerdings nicht davon aus, dass die Energie bei einem potentiellen Angreifer dafür ausreicht. Welche krypto Algorithmen wie nachgebildet werden können, damit habe ich mich schon befasst (zumindest bei den bekannten wie AES, ARC4, RSA,.. ) - das ist nicht das Problem. Trotzdem vielen Dank für deine Ausführungen - wenigstens weiß ich jetzt, dass das was ich bisher zu Papier gebracht habe stimmt. Viele Grüße und ein schönes Wochenende Ralf
Das Thema ist imho total mau für eine Diplomarbeit. An welcher FH studierst du?
Bei uns war es so, dass im Rahmen von DAs und SAs entstandene Technologien/Verfahren/Techniken nicht vermarktet/verkauft/(zu Geld gemacht) werden durften.
Ich bin zufällig über diesen Thread hier gestolpert und muss agen, ich bin echt verwundert, dass es im Bereich Softwareentwicklung Firmen / Menschen gibt die über so etwas überhaupt nachdenken. Jeder halbwegs talentierte Entwickler sollte mittlerweile begriffen haben, dass es so etwas wie einen effektiven Kopierschutz nicht geben kann, weder in Hardware noch in Software. Ich entwickle und vertreibe in meiner Firma u.a. auch Libs, für so etwas wie Kopierschutz verschwenden wir erst gar keine Zeit, dass bringt nunmal einfach nichts. Was wir machen ist Softwareentwicklungen entweder komplett als Binary und Source auzuliefern und dem Kunden die Rechte daran abzutreten oder eben nur als Binary wobei der Kunde dann keinerlei Rechte hat die Sourcen zu sehen oder zu nutzen. Das rentiert sich immerhin gut genug das wir davon 14 Mitarbeiter bezahlen können. Insofern halte ich persönlich diese ganze Diskussion hier für sinnlos. Der einzige ansatzweise sinnvolle Vorschlag, der auch schon vorgebracht wurde, ist einen Kommunikationscontroller mit definierter Schnittstelle zu verkaufen, das so etwas zu langsam glaube ich einfach nicht, wieviel Gigabits pro Sekunde soll dieser ISO Bus denn übertragen ? Das jemand seine Diplomarbeit über ein solches Thema shreibt verwundert mich noch mehr, müssen denn Diplomarbieten nicht auch erst einmal beim Prof. beantragt werden ? Welcher Prof. stimmt denn so einer Schnappsidee zu ?
> Insofern halte ich persönlich diese ganze Diskussion hier für sinnlos. Diese Diskussion ist auch sachlich für'n Popo... > Welcher Prof. stimmt denn so einer Schnappsidee zu ? Das Frage ich mich auch schon die ganze Zeit. Vielleicht ist die Storry mit der Dipl-Arbeit nur vorgeschoben?
Für die Diplomarbeit ist es kein Todesurteil. Die Arbeit selbst ist neutral. Wenn am Ende rauskommt, dass es nicht geht, dann ist das auch ein Ergebnis. Toll ist es für den Diplomanden natürlich nicht, aber nicht jede Entwicklung kann gelingen. Dann musst du andere Möglichkeiten aufzeigen, wie man es mit einer Kombination aus Hard- und Software möglichst sicher machen kann. Die Software kann eben nur die Möglichkeiten ausschöpfen, die die Hardware auch bietet.
Hi, analysiere existierende Systeme / bereits gemachte Fehler und leite daraus dein weiteres Vorgehen ab: http://www.xbox-linux.org/wiki/17_Mistakes_Microsoft_Made_in_the_Xbox_Security_System Gruß, Alex
@Unbekannter >So ein Blödsinn. >Es fordert nur etwa 5 Sekunden nachdenken um das als Marketinggewäsch zu >entarnen und etwa 5 Minuten Arbeit um den Beweis dafür aus Papier zu >schreiben. Dann schreib den Beweis hier ins Forum rein! Ausserdem meinte ich ein Wasswerzeichen für Video/Audio Daten. Das mit dem "nicht totzukriegen" bezieht sich nur darauf, dass man das Wasserzeichen nicht durch Formatkonvertierung oder Filterung rausbekommt, ohne die eigentlich wichtigen Daten zu zerstören (z.B. einen Film unansehnlich zu machen).
Das "Geheimnis" muß IMHO im Prozessor liegen: - Schlüssel im uP ablegen, gegen lesen schützen ("geheimer Schlüssel") - Lib verschlüsseln, bevor sie im externen Rom, Flash o.ä. abgelegt wird - uP liest verschlüsselte Lib ein, entschlüsselt mit geheimem Schlüssel, führt Code aus. In der Produktion (Auslieferung an Entwickler) wird jede Lib auf den/die verwendeten uPs verschlüsselt. Im Extrem geht eine Lib nur mit einem einzigen uP (spezifischer Schlüssel je uP), im anderen Extrem geht die Lib mit allen uPs (1 Schlüssel für alle uPs). Statt im uP abgelegtem Schlüssel kann man auch die geschützte Prozessor-ID nehmen so der uP eine hat. Welche Verschlüsselung (RC5 ..) genommen wird ist ein anderes Thema. Hab ich da einen Denkfehler? Gruß Gerd.
Ja, Denkfehler. Sobald der Code ins Ram entschlüsselt wurde, kann er da auch ausgelesen werden.
Der RAM ist im Einchip uP - wie soll da jemand an die Daten rankommen? Keine Adress/Datenleitungen nach aussen - und nehmen wir für die Diskussion mal fehlerfreien Programmcode an (kein Buffer overflow Angriff o.ä. möglich) Gruß Gerd.
Es handelt sich hier um eine Library. Die wird mit Code des die Library kaufenden Kunden gelinkt, der befindet sich also genauso wie die gelinkte Library im µC. Und kann daher mit der Library machen, was er will.
Dem verlinken der verschlüsselten lib steht nichts im Weg IMHO. Ich entschuldige mich für meine Penetranz - würde aber gerne wissen ob ich mich irre (bzw. ob das geht): Ansatz: Library besteht aus Funktionen, mit denen der Kunde verlinkt. Wird eine lib-Funktion aufgerufen, so holt die lib-Funktion/der uP das entsprechende Stück "wieauchimmer" verschlüsselten Codes aus der library (dort z.B. in Array abgelegt) ins (Singlechip) RAM, entpackt es mit dem geheimen Schlüssel (im Singlechip Flash/ROM) und führt ihn aus. Für die Diskussion: JTAG o.ä. ausgeschalten Singlechip-Prozessor, keine externen Daten/Addressleitungen, RAM, ROM entschlüsselter Code im internen RAM oder Flash ausführbar
Ich verstehe das nicht - z.B. Windows kam/kommt doch auch mit einer Produktaktivierung. Früher war der Key noch bei der CD dabei, heute kommt er (meistens) online. Das das von der theoretischen Seite keine 100% sichere und unumgehbare Methode ist, ist ja bekannt. Aber es muss ja auch nur darum gehen, die Latte hoch genug zu hängen. Den Rest soll die Rechtsabteilung lösen. (In der DA könnte man an der Stelle etwas von Interdisziplinär schreiben, kommt bestimmt gut an)
Hallo Laute, bei Maxim gibts doch Secure Controller. http://para.maxim-ic.com/en/search.mvp?fam=secuc&tree=ucontroller Damit sollte sich doch was "ordentliches" machen lassen. Soweit ich das damals richtig verstanden habe wird der Code nur zur Laufzeit entschlüsselt und ausgeführt. Aber eben nicht der ganze sondern immer nur die Bytes die grbaucht werden. Reinschauen lohnt sich bestimmt.
Gerd Gerd wrote: > Dem verlinken der verschlüsselten lib steht nichts im Weg IMHO. > > Ich entschuldige mich für meine Penetranz - würde aber gerne wissen ob > ich mich irre (bzw. ob das geht): > > Ansatz: > Library besteht aus Funktionen, mit denen der Kunde verlinkt. > Wird eine lib-Funktion aufgerufen, so holt die lib-Funktion/der uP das > entsprechende Stück > "wieauchimmer" verschlüsselten Codes aus der library (dort z.B. in Array > abgelegt) ins (Singlechip) RAM, entpackt es mit dem geheimen Schlüssel > (im Singlechip Flash/ROM) und führt ihn aus. > > Für die Diskussion: > JTAG o.ä. ausgeschalten > Singlechip-Prozessor, keine externen Daten/Addressleitungen, RAM, ROM > entschlüsselter Code im internen RAM oder Flash ausführbar Hallo Gerd, ja das geht. Aber nehmen wir mal an ein normaler funktionsaufruf dauert eine µs. willst du diese funktion jetzt erst zum dongle schicken dauert das. dann muss sie entschlüsselt und ausgeführt werden. die antwort geht zurück an den eigentlichen rechner.. ich denke mal da kommen mindestens 20µs zusammen. viele grüße ralf
Genau. Wollte den Ansatz auch nicht gutreden. Aber: Viele moderne Einchip-uPs haben gigantische Flaschspeicher. Wenn da neben der Applikation Platz ist (bzw. reserviert wird) muß nicht jedesmal ausgepackt/entschlüsselt werden - oder nie wenn die Lib (bzw. die vom Anwender verwendeten Teile) komplett reinpassen. Ob die entschlüsselten Teile resident bleiben sollen könnte man ja der unverschlüsselten lib-funktion mitteilen, mit der man verlinkt. Ausführungsgeschwindigkeit ist dann wie von normalem Code. Übrigens: Dongle gibts bei mir nicht, sondern Schlüssel der im uP abgelegt ist.
> kein schlechter Ansatzpunkt. Klar gibt es das Urheberrecht, nur wie > soll man es einem Nutzer einer nichtlizenzierten Betrieb nachweisen, > dass > > a) sein Produkt Funktionen aus der Bibliothek verwendet > b) er wirklich keine Lizenz besitzt (eine Lizenz muss er ja kaufen) Das ist der bittersüße Geschmack von Closed Source. Weil viele es so halten, haben sie alle das gleiche Problem miteinander. Wenn ich manchmal sehe, was hinter diesen zu schützenden Teilen steht (Innovationshöhe), verstehe ich das ganze Getue um diese Geheimniskrämerei nicht. Zwei Gründe sprechen aber für eine Geheimhaltung: Erstens Patente. Solange keiner reingucken kann, kann er auch nicht so leichtfertig behaupten, ich verletze sein Patent (was im Zeitalter von Softwarepatenten ja ganz schnell passieren kann). Und Open Source: Solange keiner reingucken kann, kann auch keiner behaupten, ich hätte bei ihm abgekupfert. Aber ansonsten? Meistens ist der Aufwand es zu schützen höher, als der Aufwand es zu knacken.
Juergen Beisert wrote: > Aber ansonsten? Meistens ist der Aufwand es zu schützen höher, als der > Aufwand es zu knacken. deswegen nimmt man ja diplomanten ...
Wie der OP schon mehrfach sagte, ist es weder möglich auf eine andere CPU FLASH RAM Kombination zu setzen, als auch den JTAG zu deaktivieren. Damit scheiden alle machbaren Verfahren für eine 99.9% Sicherheit aus. Man kann nur noch mit der "security by obscurity", also Sicherheit durch Verwirrung arbeiten. Auch der Ansatz einer mechanischen Sicherung ist noch möglich. Mein Lösungsvorschlag wäre, in der Software einen AES für Software-Updates zu integrieren. Die Binärdaten wären damit nicht angreifbar auf ihrem Transportweg zum Kunden. Die Update-Schnittstelle darf nicht über den JTAG erfolgen, sondern muss über eine andere Kommunikationsschnittstelle erfolgen, die über einen eigenen Treiber mit der Fähigkeit für die AES Entschlüsselung verfügt (Serielle / USB o.ä.). Bei der Produktion wird die Platine einmalig mit dem Loader über JTAG versehen, der JTAG wird am besten per Nadelbett kontaktiert. Danach wird alle komplett vergossen. Bei diesem prozessor nicht möglich ( sagt der OP) aber bei anderen durchaus: Abschalten des JTAG per Software auf der CPU. Gleich der erste Boot-Code sollte noch vor einer möglichen Entschlüsselung den JTAG abschalten. Das Verzichten auf JTAG-Pinne und das, wenn mögliche, Abschalten des JTAG soll verhindern, dass man die vergossene Platine auf einfachem wege durch anbohren der Vergussmasse kontaktieren kann. Eine zusätzliche Hürde für die Laien-Hacker Abschreckung ist übrigens auch der Einsatz von Multilayer und BGA. Entgegen den anderen Bauformen ist hier ersteinmal eine Menge Arbeit nötig die Signalbahnen zu zu ordnen. Gruß, Ulrich
Leute, könnt ihr nicht lesen? Es geht darum die Bibliothek vor den Leuten zu schützen die damit entwickeln sollen. Die haben bei diesem Controller vollen Zugriff auf Flash und RAM, alle Vorschläge mit Verschlüsselung und JTAG-Deaktivierung gehen völlig am Problem vorbei. Die einzige Möglichkeit ist, alles möglichst verworren und undurchsichtig zu machen. Den Entwickler wird's natürlich "freuen".
Mal von oben: >Der Kopierschutz soll sicherstellen, dass die Bibliotheken wirklich nur >auf der Hardware funktionieren. Also bekommen die Leute von euch Hardware und Software. Egal welche und wieviele Bauteile du noch hinzufügst, man kann die Hardware nachbauen. Dongle bringen nix, da man debuggen kann, kann man den Dongle auch emulieren. Seriennummerbausteine, etc. alles gleich. Software kann man anpassen.... Am besten alles so anbieten das ein Nachbau nicht lohnt.
> Ausserdem meinte ich ein Wasswerzeichen für Video/Audio Daten. > Das mit dem "nicht totzukriegen" bezieht sich nur darauf, dass > man das Wasserzeichen nicht durch Formatkonvertierung oder > Filterung rausbekommt, ohne die eigentlich wichtigen Daten zu > zerstören (z.B. einen Film unansehnlich zu machen). Das ist einfach: Einfach mit dem gleichen Algorithmus ein anderes Wasserzeichen einrechnen. Das neue Wasserzeichen "überschreibt" das alte, da der gleiche Algorithmus natürtlich die gleichen Modulationstechniken verwendet. Ansonsten gibt in der Literatur dutzende Beispiele, wie man komplizierte, digitale Wasserzeichen mit deutlich einfacheren Mitteln völlig sicher rausbekommt.
So einfach geht das nicht. Ein gutes Wasserzeichen ist ein feiner Rauschteppich der über die gesamte Bandbreite verteilt ist, wenn du den Code nicht kennst kannst du es nicht von anderweitig entstandenem Rauschen unterscheiden, und auch nicht überschreiben oder durch Mittelung über mehrere Versionen mit unterschiedlichem Wasserzeichen entfernen. Das Prinzip ist das selbe wie bei GPS. Was noch am meisten bringen würde wäre eine Codierung wie MP3, die ja genau das Gegenteil vom Wasserzeichenalgorithmus erreichen will: nicht hörbare Information zu entfernen. Ich vermute aber dass in der Praxis trotzdem das Wasserzeichen gewinnt, wenn die Qualität nicht leiden soll.
>Leute, könnt ihr nicht lesen? Es geht darum die Bibliothek vor den >Leuten zu schützen die damit entwickeln sollen. Die haben bei diesem >Controller vollen Zugriff auf Flash und RAM, alle Vorschläge mit >Verschlüsselung und JTAG-Deaktivierung gehen völlig am Problem vorbei. >Die einzige Möglichkeit ist, alles möglichst verworren und >undurchsichtig zu machen. Den Entwickler wird's natürlich "freuen". Den Ton ignorier ich jetzt mal. HimmelHerrGottSakrament! Der Themenstarter (->Ursprungsartikel lesen) sprach von der Möglichkeit eines zusätzlichen Chip zum Schutz der Bibliotheken, hatte aber die Befürchtung das ganze zu verlangsamen. Vorschlag war Singlechip-uP mit Flash, verschlüsselter lib , kein JTAG lib und kann geschützt in diesem Chip mit Orig.Geschw. (oder schneller) laufen. Kommunikation über SPI oder was auch immer, ein Teil der Lib ungeschützt auf dem orig.-Prozessor, die patentierten Teile im geschützen. Ausweiten kann man den Schutz mit "mutual authentification". Ich trau mich jetz aber nicht darüber zu schreiben, sonst krieg ich wieder was ab;)
@Gerd Gerd JTAG ausschalten bei einer Lib für Entwickler? Das Ding würde ich nicht kaufen. Neulich habe ich einen interessanten Vortrag zum Thema Linux-xbox hacken gesehen. Da sind mit Sicherheit einige Don'ts dabei, die hier auch interessant wären. ... 3 Minuten Google später ... http://video.google.com/videoplay?docid=-749497642180741726&q=linux+xbox+22c3&total=1&start=0&num=10&so=0&type=search&plindex=0
ne, auf dem bestehenden uP auf dem der Entwickler die Lib aufruft und seine Applikation schreibt ist JTAG an, auf dem "zusätzlichen Chip"der die LIB schützt aus - die lib muß man ja hoffentlich nicht debuggen und wenn ja nur der Patenthalter???
@gerd gerd prinzipell ist das schon denkbar, allerdings nur wenn es funktionen gibt die a) wichtig für die funktionalität vieler funktionen, (wen interessierts wenn eine led nicht aktiviert werden kann?) b) nicht zeitkritisch, c) nicht reproduzierbar sind. und sowas habe ich leider nicht. Vorallem a und c gibts nicht. Da die ISO Normen (gegen 2Geld) zu bekommen sind kann jeder durchschnittliche programmierer die ausgelagerten teilfunktionen selber machen. und wenn man zu viele auslagert hauts wieder mit der zeit nicht hin *sich permanent im kreis dreht*
> und auch nicht überschreiben oder durch Mittelung über > mehrere Versionen mit unterschiedlichem Wasserzeichen entfernen. Sicher geht das. Wenn Deine Aussage stimmen würde, dann könnte man beliebig viele Wasserzeichen in eine Datei "einmitteln". Sozusagen unbegrenzte Speicherkapazität... Es gibt sicherlich nur wenige Wasserzeichen-Methoden die so plumb sind und nur das LSB modulieren. Dennoch arbeiten alle Wasserzeichen nach dem gleichen Prinzip: a.) Daten aufteilen in Nutzdaten und Rauschen b.) Rauschen modulieren bzw. ersetzen. c.) Nutzdaten und Rauschen wieder zusammenführen. Niemand hindert dich daran, den gleichen Prozess durchzuführen und in Schritt b das Rauschen so zu verändern, dass das Wasserzeichen nicht mehr demoduliert werden kann. Es ist sicher richtig, dass man Wasserzeichen so optimieren kann, dass sie die gängigen Bearbeitungsschritte der Daten überstehen. Man kann sie allerdings nie so kontruieren, dass sie allen Bearbeitungsschritten widerstehen.
Unbekannter wrote: >> und auch nicht überschreiben oder durch Mittelung über >> mehrere Versionen mit unterschiedlichem Wasserzeichen entfernen. > > Sicher geht das. > > Wenn Deine Aussage stimmen würde, dann könnte man beliebig viele > Wasserzeichen in eine Datei "einmitteln". Natürlich nicht beliebig viele, aber mehr als genug um den Mittelungs-Angriff unpraktikabel zu machen. > Dennoch arbeiten alle Wasserzeichen nach dem gleichen Prinzip: > > a.) Daten aufteilen in Nutzdaten und Rauschen Diesen Schritt solltest du patentieren ;) Das Wasserzeichen wird einfach zum Nutzsignal addiert, danach weißt du nicht mehr was Nutzsignal und was Wasserzeichen ist.
Ralf H. wrote: >... Da die > ISO Normen (gegen 2Geld) zu bekommen sind kann jeder durchschnittliche > programmierer die ausgelagerten teilfunktionen selber machen. und wenn > man zu viele auslagert hauts wieder mit der zeit nicht hin *sich > permanent im kreis dreht* Wenn jeder "durchschnittliche Programmierer" den Code soweit durchschauen kann um die ausgelagerten Teilfunktionen selber zu machen, dann würde ebendieser Programmierer wahrscheinlich auch in der Lage sein, sich seine Library selbst zu basteln. Gruß Jörg
Leider ist das Projekt nicht von Anfang an wirklich genau definiert worden, was wohl auch daran liegt, dass der OP noch nicht genau wusste in wie weit er in den Prozess eingreifen kann und darf. Es ist auch nicht bekannt, wie komplex die von den Kunden zu entwickelnde Software ist, die auf der Hardware und der LIB basiert. Auch ist diese Bündelung von Hardware und LIB eine Quelle der häufigen Missverständnissen in den Antworten von Anderen und mir selbst. Wenn ich eine Hardware mit einer Software liefere, auf deren Basis weitere Entwicklungen stattfinden sollen, dann kann ich mit vermutlich keinem vertretbaren Aufwand verhindern, dass Signaturen, Keys und Hashes ausgelesen werden können. Also bleibt nur der vorgeschlagene Weg eines Wasserzeichens, dass Rechteverletzungen im Nachhinein verfolgbar macht, also die Quelle der Raubkopie innerhalb der Kunden lokalisierbar macht. Das Wasserzeichen wird also aus einem Kundenspezifischen String erzeugt. Das verhindert die Kopie nicht aber es behindert keine Entwicklung und verlangsamt auch keine Systeme. Wenn der Kunde aber nur noch kleine Modifikationen machen muss oder will, dann braucht er vielleicht auch kein JTAG. Und letztendlich muss man sich bei den diskutierten Mitteln und Wegen auch mal fragen, ob das aufwendige und doch löchrige Schutzsystem nicht mehr Geld kostet, als ein Redesign mit einer CPU, die einen CryptoCore und FLASH beinhaltet. Ein weiterer Punkt kommt noch hinzu: Will man den eigenen Code von seinen Kunden schützen, oder möchte man das Gesammtprodukt vor den Mitbewerbern schützen? Mit meinen Kunden kann man per NDA einen vertrag schließen. Das Gesamtsystem kann dann wiederum mit den üblichen Verschlüsselungen und deaktiviertem JTAG u.s.w. geschützt werden. Dies wäre sogar ein Mehrwert, der zusätzliche Kunden bringen könnte, weil deren Software gleich mit geschützt würde. Es sind bei der Definition dieses Projektes doch noch recht viele Fragen offen. Gruß, Ulrich
Wie man so ein Wasserzeichen basteln kann, hatte ich weiter oben schon beschrieben: Beitrag "Re: Kopierschutz für (Entwicklungs-) Bibliotheken - Diplomarbeit"
Bitte 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.