Kopierschutz für (Entwicklungs-) Bibliotheken - Diplomarbeit

> 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

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 ;-(

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.

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.

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.

@ 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.

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.

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.

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.

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)

@ 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.

@ 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...

@ 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.

> 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

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

> 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 :-)

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?

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

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.

> @ oliver:
> bitte lern (genau)lesen

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

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.

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.

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.

Abschaltbar

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

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

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;)

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*

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"