www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kopierschutz für (Entwicklungs-) Bibliotheken - Diplomarbeit


Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ga5t (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die bib einfach opensource machen und gut is 8)
immer diese geheimnistuerei...

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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,...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: thyristor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-(

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nucor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Die Kopien der Lib, die an Kunden verkauft werden, werden markiert -
z.B. indem man gewisse Codeblocks in Funktionen permutiert und eine
Möglichkeit schafft, diese Permutationen in eine Zahl umzucodieren,
die eindeutig einer Kopie der Lib zugeordnet ist. (Das läßt sich
sehr elegant über ein Zahlensystem mit der Stellenwertigkeit n!
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ß.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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)

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Norgan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: 6644 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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%2...

Dass du bereits 30 Seiten recheriert hast, geht aus deinem OP nicht 
direkt oder indirekt hervor. Sorry, wenn ich dir Unrecht getan habe.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olli R. (omr) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 6644 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bernd G. (Firma: LWL flex SSI) (berndg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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!

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: jl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Willi Wacker (williwacker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christoph R. (mories)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Mitbastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Willi Wacker (williwacker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Was hältst du denn von der Sache im Anhang? Nur um mal eine Anregung in 
den Raum stellen.

Michael

Autor: Karl der Große (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö, du bist der Autor und hast alle Rechte eines Autors.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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...

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: ludwig van (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@ 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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bau ne GSM-Verbindung ein und lass Teile des Codes auf deinem Server 
laufen.
:-)

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dalai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Alexander Liebhold (lippi2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Alexander Liebhold: es ist ein arm. der hat keine securitybits

@ random: es ist ein arm7, der hat sowas nicht :-)

trotzdem danke euch beiden

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf: wenn ihr jetzt anfangt das Debugging zu erschweren und die 
Software an eine spezielle Hardware zu koppeln kann sich das ganz 
schnell ändern.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> @ oliver:
> bitte lern (genau)lesen

Autor: Punktrichter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/organisati...
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.

Autor: Heinzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...?

Autor: Ralf H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: John C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Thema ist imho total mau für eine Diplomarbeit. An welcher FH 
studierst du?

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei uns war es so, dass im Rahmen von DAs und SAs entstandene 
Technologien/Verfahren/Techniken nicht vermarktet/verkauft/(zu Geld 
gemacht)  werden durften.

Autor: Timberwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,


analysiere existierende Systeme / bereits gemachte Fehler und leite 
daraus dein weiteres Vorgehen ab:

http://www.xbox-linux.org/wiki/17_Mistakes_Microso...



Gruß,
Alex

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, Denkfehler. Sobald der Code ins Ram entschlüsselt wurde, kann er da 
auch ausgelesen werden.

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abschaltbar

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Laute,

bei Maxim gibts doch Secure Controller.
http://para.maxim-ic.com/en/search.mvp?fam=secuc&t...

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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Juergen Beisert (jbeisert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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;)

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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=-749497642...

Autor: Gerd Gerd (gege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Ralf H. (rahu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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*

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie man so ein Wasserzeichen basteln kann, hatte ich weiter oben schon 
beschrieben: Beitrag "Re: Kopierschutz für (Entwicklungs-) Bibliotheken - Diplomarbeit"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.