Hallo zusammen, als Unwissender wüde ich gerne mal eine Frage stellen. Ist es möglich ein fertiges Programm für einen Atmel-Controller so zu schützen dass es nur für eine gewisse Anzahl an Chips verwendet werden kann? Der Hintergrund: Wenn man mit einem Plan für eine Platine und dem Programm für den Controller zu einer Fertigungsfirma geht, haben die alle Unterlage diese Platine auch nacher noch fertigen zu können. Wie kann ich also ein Controller Programm vor der Weiternutzung schützen? Geht das überhaupt oder wie wird das sonst gemacht. Gruß Robert
Die Anzahl der Kopien kannst Du nicht einschränken. Lösungen: - Fertigungsfirma vertrauen - Controller selber programmieren, und die LOCK-Fuses setzen /Ernst
Hallo, danke erstmal Ernst. Aber den Firmen in China zu vertrauen ist nicht immer leicht. Und selbst programmieren ist ein großer logistischer Aufwand den ich vermeiden will. Gruß Robert
jeder seriöse Fertiger behandelt Kundendaten absolut vertraulich. Ein einziger Fall von "Veruntreuung" kann den Ruin der Firma bedeuten.Ich glaube, du leidest da ein wenig unter Verfolgungswahn. Ansonsten, wie schon gesagt, fertig gebrannte Controller liefern oder die Software erst nach Bestückung draufspielen.
Und hier einen Schwung Controller programmieren, und zur Bestückung nach China Liefern? Oder Platine mit ISP-Anschluss ausstatten, Platine mit leeren Controllern bestücken lassen, und die Geräte hier programmieren? Ansonsten, wenn das Programmieren in China erfolgen muss: kleine Public-Key check-routine in den Code einbauen, die eine Signatur im Eeprom prüft und ansonsten den Start verweigert. Je nach Geräteart: Signatur bei Auslieferung (+ Seriennr) ins Eeprom brennen, oder bei Computer-Hardware bei Treiberinstallation mit Freischatcode-check... Ist aber kein wirklicher Schutz, so eine Routine aus einem .hex file rauszunehmen ist eher trivial. /Ernst
Also ich China wär ich da auch sehr vorsichtig. Bleibt also nur selbst programmieren oder vorprogrammierte µC's besorgen und nach China schicken (lassen)!
Alternative: 10 cent mehr ausgeben und nicht in China fertigen lassen. Es gibt zum Beispiel auch in Deutschland Bestückungs/Herstellungsfirmen ...
Ja, lustig. So langsam bekommen sie alle kalte Füße, dsa Know-How nach China zu tragen... Was der Volksmund schon lange wuste, kommt nun so langsam auch in den Köpfen der "Entscheider" an.
Hi, müssen ja schon ein paar mehr chips sein wenn sich das mit China ohnen soll. Da würde ich mal darüber nachdenken die gleich maskenprogrammiert zu bestellen. Dafür muß man dann natürlich seinem Hersteller vertrauen können. Eckhard
Ich kenne selber Leute, die an Chinesen verkauft haben, die haben dann über eine Kalenderfunktion alle "nicht-legalen" Kopien der Software nach 6 Monaten "abstürzen" lassen, auf einmal kamen die Chinesen dann "hintenrum", als die nämlich an der TU Aachen angefragt hatten, die TU Aachen aber auch nur die eine Person kannte, und diese angeschrieben hatte. Blöderweise war diese eine Person der Entwickler der Geräte...ich würde den also auch nicht vertrauen... ;-)
Hallo, die Alternative Deutschland kostet wohl einiges mehr als 10 Cent, leider!!!! Ich würde das gerne hier machen, aber dann kauft das Zeug keiner mehr. Mit chinesischen Anbietern arbeite ich schon auf einem anderen Gebiet zusammen, daher weiss ich wie das läuft. Die bauen das gleiche Teil dann für jeden der es haben will. Gruß Robert
>>Die bauen das gleiche Teil dann für jeden der es haben will.
Das ist dann wohl der Preis für billig...billig...billig. Die
Stückzahlen bringens.
Sven
Eine gerade im Bereich der Software praktizierte andere Möglichkeit des Kopierschutzes ist es, die Software so grottenschlecht zu machen, daß sie keiner haben will ...
Ja genau... ne grottenschlechte V0.1 drauf und dann n Update anbieten. Beim Update muss man sich als rechtmäßiger Kunde mit der "seriennummer" anmelden und bekommt das Update nur, wenn man verifiziert wurde. Sind wir da nicht fast bei dem Kopierschutz von Windoof ?!?!
oder Studenten auf 400,- Euro Basis beschäftigen, die die uC vorprogrammieren und locken. Dürfte dann auch bezahlbar bleiben, ist sicher, und hilft denen die es brauchen können ;-)
Den Chinesen nur den Bootloader geben der nur verschlüsselte/zertifizierte Daten brennen kann. Die fertigen Platinen dann beim Treibersetup mit der eigentlichen Software updaten. Gruß Hagen
Achso, ein Reverse Engineering des Bootloaders bringt dann nichts mehr wenn die verschlüsselten Programmdaten beim Setup ihren eigenen Entschlüsselungsschlüssel mit senden. D.h. im Grunde ist das eigentliche Program quasi doppelt verschlüsselt. Ein Schlüssel ist im Bootloader schon enthalten, der andere wird durchs Setup mitgeliefert. Gruß Hagen
@Hagen: Dein Idee funktioniert nicht. Der gemeine Chinese hat den Bootloader. Er kann ein Exemplar vom fertigen Produkt regulär kaufen/besorgen und dem Treibersetup einen echten Bootloader vortäuschen und die eigentliche Software abfangen. Egal, wie oft Du verschlüsselst, egal wie kompliziert, egal wie raffiniert, dieses Problem lässt sich nicht lösen. Mit ein wenig logischem Denken wird auch klar, warum. Die einzige Möglichkeit besteht darin, das Ding nicht in China programmieren zu lassen.
> oder Studenten auf 400,- Euro Basis beschäftigen, die die uC > vorprogrammieren und locken. > > Dürfte dann auch bezahlbar bleiben, ist sicher, und hilft denen > die es brauchen können ;-) Das hälst du für sicher? Einige Studenten nehmen gern mal alle Software mit, die sie kriegen können. Man weiß ja nie, wozu man's mal brauchen kann. @Hagen: > Der gemeine Chinese hat den Bootloader. Er kann ein Exemplar vom > fertigen Produkt regulär kaufen/besorgen und dem Treibersetup > einen echten Bootloader vortäuschen und die eigentliche Software > abfangen. Nicht, wenn zusammen mit dem ersten Einspielen der eigentlichen Firmware ein initialer Schlüssel mitgegeben wird, der im Mikrocontroller gespeichert wird und für alle weiteren Zugriffe benötigt wird. Upgrades der Firmware werden nur in verschlüsselter Form ausgegeben. So kann der Chinese mit dem Bootloader nix anfangen.
Und der Endtest wird dann auch gleich in China gemacht? Wenn die Geräte hier ausgepackt wern müssen, dann kann man auch gleich die richtige Software hier draufspielen. Apropos Bootloader: einfach 2 Bootloader verwenden .. der erste hat keine Verschlüsselung, sondern erlaubt nur das Einspielen des eigendlichen Bootloaders im Testfeld über die RS232 (oder was-auch-immer). Der eigendliche Bootloader hat Verschlüsselung zum Download der Applikationssoftware. Übrigens teile ich die Meinung von Rufus: in vielen Fällen dienen die Lock-Bits wohl eher dem Vertuschen von Pfusch-Code. Gruß, Stefan
Ich arbeite bei einem Lohnbestücker. Wir programmieren auch für unsere Kunden Atmel µP's. Wir verwenden von www.e-lab.de die Programmiergeräte und Software. Diese Software verschlüsselt das Programm und bietet die Möglichkeit die Anzahl der Programmzyklen zu begrenzen. Die Programme können so sicher per Email verschickt werden. Genau das was du suchst...
Auch wenn das Programm bis in den Programmieradapter hinein verschlüsselt ist, die Übertragung in den AVR ist es nicht. Also einfach mitlauschen. Wie die so erhaltenen Daten zu interpretieren sind steht haarklein im Datenblatt, ist also auch kein Aufwand das Programm auf diesem Wege zu klauen. /Ernst
@Ernst: Da könntest du Recht haben... die Idee ist mir noch gar nie gekommen. Allerdings hatte ich auch noch nie das Bedürfniss ein Programm zu klauen ;-) Das Programm kann dann aber nur 1:1 übernommen werden, oder? Änderungen sind ja nicht möglich da man das Programm ja nicht in Klartext (Assembler) hat, richtig?
Den Assembler-Quelltext kann man sehr leicht wieder rausfinden, ASM ersetzt ja praktisch immer nur einen Befehl durch den zugehörigen Opcode, das ist leicht unzukehren. Schwieriger wirds dann schon die Struktur wieder rauszuholen, z.B. was war eine Subfunktion, wo läuft die schleife etc... Richtig gemein wirds bei Optimiertem C-Code, den Orginalcode kriegt man nicht mehr, aber kleine Patches/Änderungen sind da auch auf ASM Ebene möglich. Lies mal: http://www.ccc.de/hackabike/index_de.html Die haben zwar das Binary über ne vergessene Lock-Fuse bekommen, aber wenn man das erstmal hat ist das vorgehen identisch. /Ernst
Software einfach mitnehmen und Lockbits umgehen sind zwei völlig verschiedene Dinger. Und setz mal eine Vertragsstrafe in China durch...
In de.sci.electronics läuft gerade ein Thread zu dem Thema Fertigung in China. Einfach mal ein paar tausend Platinen zusätzlich durchlaufen zu lassen oder jemanden auf das Knacken eines Controller anzusetzen sind doch zwei völlig verschiedene Ansätze. Woher soll eine 0815-Fertigungsklitsche denn das Knowhow zum Knacken eines Controllers haben? Mit einfach Anschließen und Auslesen ist es nicht getan, man müsste bei zig verschiedenen Typen auf dem Laufenden sein, usw. Vielleicht kann sich die Firma das einkaufen, aber lohnt sich die ganze Sache dann noch, oder hätte man die paar kByte Assemblercode nicht gleich selber schreiben können? Schutz misst man in $, nicht in %.
Also ich habe eine Weile mit Chinesen gearbeitet, die hatten auch Kontakt in diese Brache. Ich würde einen hier programmierten Controller verwenden, und zwar einen der neuen von Atmel. Da ist das Auslesen und knacken deutlich aufwendiger und teurer als bei den alten. Die habe auch spezielle Security Controller. Was ist es denn für ein Produkt? Lohnt sich der Aufwand? 3N
Achja, die Geschichte um die es damals ging war die, das die Chinesen den Code geklaut haben, das Programm und gerät etwas verbessert haben und den Hersteller hier in Dtl. in den Ruin getrieben haben. Unrechtsbewusstsein dafür existiert übrigens nicht, ich würde in China NIEMANDEM vertrauen. Es ist ein altes Händlervolk, was gelernt hat wie man die anderen über den Tisch zieht. Wenn man aber vorsichtig ist wird es auch kein Reinfall, in fast allen Fällen haben wir mit Unvorsicht zu solchen Sachen beigetragen. Transrapid etc... http://de.wikipedia.org/wiki/Strategem 3N
>>Egal, wie oft Du verschlüsselst, egal wie kompliziert, egal wie >>raffiniert, dieses Problem lässt sich nicht lösen. Alles lässt sich lösen ;) In diesem konkreten Falle liegt das eigentliche Problem in den Anforderungen des Fragestellers. So lange er nicht mindestens EINEN Arbeitsschritt vorsieht in dem ER und nur ER die Kontrolle hat, wird das niemals funktionieren. Das mit dem Bootloader würde funktionieren wenn er nur einen Arbeitschritt vorsieht bei dem seine Firma diesen Bootloader serialisiert. D.h. der Bootloader im AVR bekommt zuhause in der eigenen Firma oder in einem Unternehmen seines Vertrauens die Schlüssel programmiert. Er könnte also die Chinesen beauftragen die Teile zu produzieren und den Bootloader aufzuspielen. Eine andere Firma oder seine eigene hat den Auftrag diesen Bootloader zu serialisieren. Es gäbe da aber auch noch eine Hardwaremäßige Lösung. Informiere dich bei Dallas und ihren Kryptochips. Die haben kleine schnuckelige Teile in MSOP8 / SO8 die geschützte Serialnummern sammt Ver/Entschlüsslung zur Verfügung stellen. So ein Ding kommt aufs Board. Wichtig ist nur das man bei Dallas zb. 1000 solcher Chips bestellt die innerhalb EINES ganz eigenen Serialnummernbereiches liegen. Dallas stellt dann sicher das keine ANDERE Firma diesen Nummernbereich mehr bekommen kann. Da dieser Nummernbereich, bzw. durch Dallas vorprogrammierte Schlüssel nur der eigenen Firma bekannt ist wird einfach die Software damit verschlüsselt. Der Bootloader im AVR lässt die Software nun durch den Chip von Dallas vorentschlüsseln. Das funktioniert dann aber nur wenn der Dallas Chip vorher die Daten authentifiziert hat. Man kann also nicht mehr den Datenaustausch zwischen AVR und Dalles Chip abhören, bzw. man kann schon aber das bringt nichts da die Kommunikation zwischen den Chips selber wieder verschlüsselt wurde. Das erfolgt dann aber diesesmal live mit einem authentifiziertem Verfahren und neuen Schlüsseln. Ergo: die eigene Firma hat einen Arbeitsschritt, nämlich die Bereitstellung der Authentifikations-Chips an Dallas abgetreten und muß dieser Firma vertrauen. Die Chinesen kommen zwar auch an solche Chips ran aber nicht an 1 zu 1 identische Chips mit den gleichen internen Seriannumern und Schlüsseln. Genauer gesagt: die Chinesen verbauen diese Chips wissen aber nicht welche Keys darin enthalten sind. Im Endeffekt ziemlich viel Knowhow und Aufwand der die 10 Cent pro Platine wohl wieder auffressen wird. Gruß Hagen
Davon mal abgesehen: Warum nicht gleich bei Atmel 1000 vorprogrammierte Chips einkaufen ? Ich dächte ich hätte bei Atmel gelesen das die auch die Chips vorprogrammieren können. Gruß Hagen
"Schutz misst man in $, nicht in %." Ich denke mal, das bringt es auf den Punkt und erübrigt alle weiteren Diskussionen. Zuallererst muß man sich Gedanken machen, wie groß ist der Gewinn, den man mit dem Produkt erzielt. Und erst dann kann man überhaupt anfangen zu überlegen, welche Kopiererschwermaßnahmen wirksam genug sein werden. Oftmals ist es eh sinnvoll, erstmal eine Testsoftware draufzuspielen, mit der nur Hardwarefehler erkannt werden können und erst danach dann die eigentliche Funktionssoftware. Peter
@Hagen: Klar, man kann es beliebig kompliziert machen. Nur: Wenn ich selbst noch Hand anlegen muss, um irgendetwas aufzuspielen, dann kann ich auch gleich das komplette Programm aufspielen und anschließend den Ausleseschutz aktivieren. Dann brauche ich mir überhaupt keine Gedanken um Verschlüsselung zu machen.
Dock, kann man immer noch knacken. Gibt einige chinesische Firmen die +- alles knacken. 3N
Rein mal aus Sicht der Kryptographie, da das das ist wovon ich Ahnung habe. Die Behauptungen "man kann alles knacken" ist schlichtweg falsch. Mathematsich gesehen ist dies zwar richtig, aber nur wenn man praktisch gesehen unendliche Zeit und unendlich große Resourcen zur Verfügung hat. Das ist aber schon immer ein Problem der Mathematiker gewesen, das sie infinitiv denken und nicht finitiv wie ein Praktiker. Praktisch gesehen ist ein sauber konstruiertes kryptographsiches System von keinem zu knacken. Nicht vdurch Big Brother, von keinem Ausserirdischen, keinem Menschen und auch keiner technisch denkbaren Machine. Nicht umsonst ist die Kryptographie und Kryptologie eine WISSENSCHAFT und keine Hexerei. Aber stellt sich die Frage was denn ein sauber konstruiertes kryptographisches System überhaupt ist, bzw. welche wichtigen Grundbedinungen es erfüllen muß ? Als allererstes muß im Protokoll der Benutzung des Systemes es immer einen Zeitpunkt geben der sicherheitskritisch ist. Ganz einfach heist das: Der Zeitpunkt der Eingabe der PIN am Bankautomaten ist ein kritischer Zeitpunkt. Wenn dieser NICHT sicher ist dann fällt das gesammte System insich zusammen. Und exakt das trifft auch hier zu, der Zeitpunkt an dem es kritisch wird. Dazu gibts nun 4 Vorschläge: 1.) selber brennen in eigener Firma 2.) durch Atmel die Chips brennen lassen, schon beim Einkauf 3.) den kritischen Zeitpunkt verlagern, also Dallas Chips nehmen und im Setup brennen 4.) den Chinesen vertrauen Wogegen ich mich aber immer wieder verwehre sind Aussagen das ALLES knackbar ist. 1.) stimmt dies einfach nicht 2.) und selbst bei einem absichtlich schlechtem kryptographischen System würden 99.99999999% der Menschen es immer noch nicht schaffen, weil einfach die Erfahrungen fehlen 3.) es gehört also immernoch eine gehörige Portion Knowhow dazu um einerseits ein System sicher zu bekommen oder andererseits selbst ein schwaches System knacken zu können. Als ob es mal eben so einfach für den Rest der Welt wäre mal eben 2^64 Schlüssel druchzuprobieren. Bevor man sowas behauptet sollte man sich erstmal hinsetzen und auf einem Zettel aufschreiben was 2^64 eigentlich bedeutet ! Und sichere Systeme fangen erst bei 2^128 minimal an sicher zu werden. Man sollte sich fragen wieviel mehr nun 2^128 im Vergleich zu 2^64 ist. Einfach mal ausprobieren und auf den Zettel die Zahl 2^64 einfach 2^64 mal draufkritzeln. Ich frage dann mal in 50 Jahren nach wieweit derjenige gekommen ist. Jetzt könnte das Argument des Praktiker kommen: Na da knacken wir doch die Fusebits des AVRs, schleifen das Ding einfach ab und schauen mal mit der Lue nach ob wie den Schlüssel irgendwo im Silizium da finden können. Ja technisch machbar mit entsprechendem Geld. Aber das macht die verschlüsselt gespeicherten Daten immer noch nicht knackbarer. Den diese bestehen nicht aus Silizium sondern reiner Information. So, sorry muste mal raus ;) Gruß Hagen
> Praktisch gesehen ist ein sauber konstruiertes kryptographsiches > System von keinem zu knacken. Das ist nicht die Praxis, sondern die Theorie. Das System selbst mag nicht zu knacken sein, aber oft genug lässt es sich durch Bugs in der Umsetzung umgehen. Und es gibt bekanntlich keine bugfreie Software. > Jetzt könnte das Argument des Praktiker kommen: Na da knacken wir > doch die Fusebits des AVRs, schleifen das Ding einfach ab und > schauen mal mit der Lue nach ob wie den Schlüssel irgendwo im > Silizium da finden können. Ja technisch machbar mit entsprechendem > Geld. Aber das macht die verschlüsselt gespeicherten Daten immer > noch nicht knackbarer. Den diese bestehen nicht aus Silizium > sondern reiner Information. Sobald man die Fusebits geknackt hat, kann man die Informationen doch einfach wieder auslesen.
Wozu ein aufwendiger und teurer Kopierschutz? Wenn es ein Nischenprodukt ist und einen überschaubaren Kundenkreis anspricht, sollte man sich auf genau die Wüsche dieser Kunden spezialisieren. -> Marktanalyse Ein wirklich effektiver Kopierschutz ist Service. Ein Handbuch mit dem der Kunde wirklich etwas anfangen kann, währe ein Anfang. Investiere lieber in die Übersetzung... Anpassung des Gerätes an die Kundengegebenheiten, neue oder zusätzliche Produkte sind weitere Punkte. Die kann man dann z. B. immer dann Präsentieren, wenn die Konkurrenz mit dem Plagiat fertig ist.
> Das ist nicht die Praxis, sondern die Theorie. Das System selbst mag > nicht zu knacken sein, aber oft genug lässt es sich durch Bugs in der > Umsetzung umgehen. Und es gibt bekanntlich keine bugfreie Software. Auch dies ein unausrottbares Gerücht. Nur weil Microsoft und Konsorten denken, dass es niemanden interessiert, ob ihre Software einmal pro Monat oder einmal pro Stunde abstürzt, heißt dies nicht, dass dies für alle gilt. (Und obwohl ich es selber nutze gilt dies uneingeschränkt auch für Linux) Man kann es einerseits mit sauberer Programmierung versuchen, z.B. NASA, die trotz einiger Abstürze eine extrem geringe Fehlerzahl in ihrer Software hat, oder wenn man wirklich sicher gehen will: Formale Verifikation: http://en.wikipedia.org/wiki/Program_verification Und für den praktischen Beweis, dass es bugfreie Software gibt: "Hello World" ansehen. Dies ist wirklich ernst gemeint! Genau auf diese Art und Weise zeigt man die Korrektheit von großen Programmen und so werden auch Dinge in der Mathematik bewiesen. Man beweist die Korrektheit kleiner Unterprogramme (bzw. in der Mathematik Hilfssätze und Grundlagen) und arbeitet sich immer weiter vor, wenn ein paar Leute unabhängig voneinander sich die Sache angeguckt haben, dann kann man davon ausgehen das es korrekt ist. Fehler können sich natürlich immer mal wieder einschleichen, aber irgendwann ist halt auch der letzte gefunden, weswegen Beweise wichtiger Sätze in der Mathematik heute fehlerfrei sind. Da dies aber nicht billig zu erreichen ist, verzichtet man bei der Programmentwicklung darauf, dies heißt aber nicht, dass es keine bugfreie Software gibt
> Man kann es einerseits mit sauberer Programmierung versuchen, z.B. > NASA, die trotz einiger Abstürze eine extrem geringe Fehlerzahl in > ihrer Software hat, Das habe ich nicht bestritten. Fehler gibt's aber trotzdem, wie du ja selbst schreibst. Überleg mal, was die für ein Budget haben und was für Leute daran arbeiten. Wenn die es nicht fehlerfrei bekommen, wer dann? > oder wenn man wirklich sicher gehen will: Und du glaubst, die NASA will nicht "wirklich sicher gehen", wenn ein 100M$-Projekt ins All geschossen wird? > Formale Verifikation: > http://en.wikipedia.org/wiki/Program_verification Diese ist für alles außer Trivialprogrammen mit extremem Aufwand verbunden. > Und für den praktischen Beweis, dass es bugfreie Software gibt: > "Hello World" ansehen. > Dies ist wirklich ernst gemeint! Ok, ich schränke ein: Es gibt keine fehlerfreien Programme, die etwas sinnvolles tun. > Man beweist die Korrektheit kleiner Unterprogramme (bzw. in der > Mathematik Hilfssätze und Grundlagen) und arbeitet sich immer > weiter vor, Das wird schwierig, das für alle Teile und auch für deren Interaktion miteinander zu beweisen. > wenn ein paar Leute unabhängig voneinander sich die > Sache angeguckt haben, dann kann man davon ausgehen das es korrekt > ist. Das ist aber keine formale Verifikation. Das ist Code-Review. > Fehler können sich natürlich immer mal wieder einschleichen, aber > irgendwann ist halt auch der letzte gefunden, weswegen Beweise > wichtiger Sätze in der Mathematik heute fehlerfrei sind. Es gibt aber einen Unterschied zwischen einem formalen Beweis und einem Test. Beweise mal, daß eine komplexe Software in absolut jeder denkbaren und undenkbaren Situation immer korrekt funktioniert. Das Ausprobieren mit jeder Menge Testdaten ist kein formaler Beweis.
Nun, jedes Programm enthält mindestens einen Fehler, und lässt sich um mindestens eine Anweisung kürzen. Daraus beweisen wir mittels Induktion: Jedes Programm lässt sich auf eine Anweisung reduzieren, die nicht funktioniert. /Ernst
@Hagen: "Bevor man sowas behauptet sollte man sich erstmal hinsetzen und auf einem Zettel aufschreiben was 2^64 eigentlich bedeutet ! Und sichere Systeme fangen erst bei 2^128 minimal an sicher zu werden. Man sollte sich fragen wieviel mehr nun 2^128 im Vergleich zu 2^64 ist. Einfach mal ausprobieren und auf den Zettel die Zahl 2^64 einfach 2^64 mal draufkritzeln. Ich frage dann mal in 50 Jahren nach wieweit derjenige gekommen ist." Fertig ;) 2^64 == 18446744073709551616 2^128 == 340282366920938463463374607431768211456 2^128 / 2^64 == 18446744073709551616 (wer hätts gedacht? :)) Ist jetzt auch nicht sooo schwer die auf Papier abzuschreiben, nur das händische Ausrechnen.... Ansonsten hast du natürlich recht mit deinen Kryptographie-Ausführungen, solang wir noch keinen 128Bit Quantencomputer haben... /Ernst
Ein wichtiges Kriterium für "Sicherheit" in der Kryptographie ist die Beweisbarkeit das es sicher sein muß. Dies gilt nicht nur auf die Algorithmen die angewendet werden sondern eben auch für deren Implementierungen. Gute Algorithmen haben immer auch Sub-Algorithmen enthalten die die erzeugten Resultate verifizierbar machen. Das ist also so als ob man eine Software schreibt die an vielen Stellen die eigenen Resultate auf Plausibilität überprüfen kann. Es bleibt immer noch ein Restrisiko, aber auf Grund der eh schon hohen Wahrscheinlichkeitsschranken die in der Kryptrographie üblich sind werden solche Fehler mit < 1/2^128 Wahrscheinlichkeit auftreten, also defacto niemals. Und es kommt ein Vorteil hinzu. Die meisten kryptographischen Verfahren reagieren bei einem Bit-Fehler wie eine "Ales oder Nichts" Verschlüsselung. D.h. sollte ein Fehler auftreten so ist die Sicherheit fast nie gefährdet sondern nur die Datenintegrität beeinträchtigt. Aus meinen Erfahrungen heraus, mit wirklich sicheren Systemen, kann ich meiner Meinung nach ernsthaft behaupten das gute Systeme niemals knackbar sein werden solange a) es keine neuen und umwälzenden mathematischen Erkenntnisse vorliegen b) gerade solche Systeme strengsten Wartungsmaßnahmen unterliegen die gerade auf die Erkennung möglicher Ausfälle hin optimiert sind c) ein Knowhow und Kapital in 6-8 stelliger Höhe nötig wird Der Aberglaube der meisten Menschen das man alles knacken kann ist einerseits durch die wahnsinnige Überwertung in den Medien von angeblichen Hackeraktivitäten zu suchen. Das fördert die Basis für die gewollten Entscheidungen der Politiker die Freiheiten einzuschränken, und mehr nicht ! Die Wissenschaften beweisen eindeutig was anderes. Gruß Hagen
@Enrst: sorry du hast mich wohl falsch verstanden, du sollst 18446744073709551616 mal 18446744073709551616 auf einen Zettel schreiben. Bisher hast du nur EINMAL auf dem Zettel 18446744073709551616 stehen. Erst wenn du es 18446744073709551616 mal egschrieben hast hast du 2^62 erreicht. Danach kannst du anfangen 18446744073709551616 solcher Zettelhaufen vollzukritzeln und hast dann den Wertebereich von 2^128 von heutigen Schlüsseln erreicht. Gruß Hagen
>Ansonsten hast du natürlich recht mit deinen >>Kryptographie-Ausführungen, solang wir noch keinen 128Bit >>Quantencomputer haben... Irrelevant! Wenn der Aufwand der Ver-schlüsselung 1 beträgt und man aber mathematisch beweisen kann das der minimalste Aufwand was zu ent-schlüsseln > 1 ist dann ist die Kryptographie in JEDEM Falle sicher. Es hängt dann alles nur noch davon ab das man die Schlüssel ausreichend groß auswählt. Als wenn selbst ein Rechner mit Zeit 1 entschlüsseln könnte so würde man nur < 1, zb. 0.5 der Rechenzeit benötigen um zu verschlüsseln. Gruß Hagen
> Und du glaubst, die NASA will nicht "wirklich sicher gehen", wenn > ein 100M$-Projekt ins All geschossen wird? Die NASA hat auch ein Budget und es sind z.B. Fehler passiert wie: Wir haben hier ein Programm für Rakete X, lasst es uns einfach für Rakete Y nehmen, uups, die verhalten sich ja ganz anders ... BUMM. >> Formale Verifikation: >> http://en.wikipedia.org/wiki/Program_verification > Diese ist für alles außer Trivialprogrammen mit extremem Aufwand > verbunden. Zugegebenermaßen ist es noch relativ schwierig, ABER es wurde auch noch nicht sehr viel auf diesem Gebiet gearbeitet und Fortschritt braucht Zeit. Am Anfang waren ICs mit Integrationsdichten wie sie heute erreicht werden unvorstellbar. Es gibt deswegen auch Programme die mit ein bisschen Hilfe einen Teil der Verifikation automatisch erledigen (und die auch ihrerseits verifiziert wurden). Es gibt übrigens Aussagen in der Mathematik (merkt man, dass ich Mathematiker bin? ;) ) die nur mit Hilfe von Programmen bewiesen wurden, z.B. der Vier-Farben-Satz http://de.wikipedia.org/wiki/Vier-Farben-Satz > Ok, ich schränke ein: Es gibt keine fehlerfreien Programme, die > etwas sinnvolles tun. Ein Satz der uneingeschränkt gültig ist, weil man einfach "sinnvoll" so definiert wie man will. Nimm zum Beispiel einen einfachen Taschenrechner der Integer-Zahlen multipliziert, addiert und subtrahiert. Wenn man den Zahlenbereich einschränkt ist dies schon ein "sinnvolles" Programm und sehr einfach komplett fehlerfrei zu kriegen >> wenn ein paar Leute unabhängig voneinander sich die >> Sache angeguckt haben, dann kann man davon ausgehen das es korrekt >> ist. > Das ist aber keine formale Verifikation. Das ist Code-Review. Da hab ich mich wohl missverständlich ausgedrückt, ich meinte: Ein paar Leute sollten diese formale Verifikation machen, denn auch in Beweisen können Fehler auftreten, nur das diese eben bei sauberen und detaillierten Beweisen sehr unwahrscheinlich sind. Ein Code-Review heißt ja einfach nur, dass sich jemand mal den Sourcecode anguckt, das ist im Allgemeinen vielleicht gut ein paar einzelne Fehler zu finden, aber selten um wirkliche Fehlerfreiheit herzustellen. > Es gibt aber einen Unterschied zwischen einem formalen Beweis und > einem Test. Beweise mal, daß eine komplexe Software in absolut > jeder_ denkbaren und undenkbaren Situation _immer korrekt > funktioniert. Das Ausprobieren mit jeder Menge Testdaten ist kein > formaler Beweis. Deswegen gibt es ja gerade die formale Verifikation, dafür muss man ja nicht alles durchrechnen, sondern man teilt die möglichen Zustände auf und zeigt separat, dass das Programm für die Klasse von Eingangsdaten korrekt ist. Zum Beispiel zeigt ja vollständige Induktion die Korrektheit einer Aussage für unendlich viele Eingangsdaten, obwohl man ja prinzipiell nur endlich viele überprüfen (testen) kann (bzw. könnte, dafür hat man es ja bewiesen). Ich kann natürlich schlecht ein Beispiel für eine vollständig korrekte Software geben, weil es so etwas momentan nicht gibt, dies liegt zum Teil auch daran, dass immer noch Dinge wie C++ benutzt werden, die genügend Seiteneffekte haben um alleine damit Bücher zu füllen. Das kaum jemand Memory Management wirklich beherrscht sieht man ja an der Menge an Buffer Overflows, aber dies liegt eben nicht an der prinzipiellen Unmöglichkeit. Vielleicht entwickelt sich ja Coyotos brauchbar: http://www.coyotos.org/
Ich frage mich die ganze Zeit, was Robert entwickelt hat, dass sich diese Diskussion über "böse" Chinesen (ein Kumpel von mir ist ein Chinese...konnte bei ihm nur bösen Durst nach Bier etc feststellen) und Kryptographien entwickelt hat. Hat er sich inzwischen eigentlich wieder gemeldet? Was ich eigentlcih viel interessanter finde: Er lässt in China fertigen, weil es dort billiger ist, hat aber Angst, dass seine Erfiindung da "die Runde macht". Wenn ihm etwas daran liegt, sein geistiges Eigentum zu behalten, sollte es es ihm Wert sein, die "paar" Kröten mehr in eine deutsche (von mir aus auch europäische) Firma zu investieren, denen er eher auf die Füsse steigen kann. Das ist diese "Aldi-Mentalität", dass alles, was billig ist, und genauso aussieht, wie die teueren Sachen, mindestens genauso gut, wenn nicht sogar besser ist. Billiges bezahlt man immer doppelt.
Nicht irrelevant. Mit einem Quantencomputer mit der entsprechenden Anzahl QBits kann ich jedes Problem in P in Konstanter Zeit Lösen. Du verschüsselst mit 1024 Bit, ich probiere alle 2^1024 möglichen Schlüssel GLEICHZEITIG aus, und nehme den der passt. Ein Quantencomputer ist also sowas wie die "Unendliche Zahl Affen an unendlich vielen Schreibmaschinen". Einer von denen wird zufällig deinen geheimen Schlüssel erraten. /Ernst
Sorry Rahul noch ein Kommentar von mir: Falls unser Universum wieder implodieren sollte dann beträgt die Lebenszeit des Universum ca. 2^61 Sekunden. (Bruce Schneier "Angewandte Kryptographie"). Wenn Ernst pro Sekunde einmal 18446744073709551616 auf einen Zettel schreibt von 2^64 mal dann wird er mit absoluter Sicherheit den Urknall des nächsten Universum miterleben müssen. So, nur mal so was 2^64 eigentlich für eine Zahl ist. Gruß Hagen
Doch irrelevant: den ich setze unendlich viele Affen daran einen unendlich großen Schlüssel zu benutzen. Wenn der Aufwand der verschlüsselung 1 beträgt und die der Einschlüsselung > 1 dann benötige ich also unendlich * 1 und du unendlich + unendlich * x mal länger. Pure Theorie, in der Praxis ist heutige Kryptographie sehr wohl sicher. Gruß Hagen
Hagen, dummerweise hilft dir ein unendlich langer Schlüssel nichts, um einen endlich langen Klartext zu verschüsseln. Bei gleicher Bitzahl ist Schluss, womit wir beim (auch theoretisch beweisbar) sicheren OTP angekommen wären. (Die lustigen Missgeschicke der Russen beim OTP-Verschlüsseln lassen wir mal außen vor). Ein OTP ließe sich zwar auch mit nem Quantencomputer in konstanter Zeit entschlüsseln, nur bringt mir das nichts weil ich keine Möglichkeit hab rauszufinden, welcher der vielen verschiedenen möglichen Klartexte nun der richtige ist. /Ernst
@Hagen: Und das geht alles mit einem AVR? Was haben Affen damit zutun? Wie gut, dass ich nie Interesse hatte, Mathematik zu studieren. Für mich bedeutet Mathematik einerseits "Rechnen"/Werkzeug für Ingenieure, andererseits aber auch "ein Kapitel in meinem Leben, dass man als Erfahrung abhaken möchte".
Ja, und noch viel mehr durch die Dummheit der Benutzer,siehe Enigma. Die wenigsten sind "geknackt" worden auf Grund neuerer mathematischer Erkenntnisse oder technologischer Meisterleistungen. Der letzte große Schub in der Kryptologie war die Entdeckung der differientiellen Kryptoanalyse vor nunmehr 30 Jahren. Mit ihrer Hilfe wurde der letzte mathematische "Rest" beim Knacken von Enigma erledigt. Seitdem gelten Streamcipher nicht mehr als so sicher. Es ist vom finanziellen Aufwand einfacher a) einen Verräter zu bezahlen b) denjenigen dessen Daten man haben möchte zu kaufen c) denjenigen dessen Daten man haben möchte zu entführen, dessen Familie zu foltern etc.pp. Gruß Hagen
könnte interessant sein: http://www.cl.cam.ac.uk/~sps32/mcu_lock.html Bezüglich der Möglichkeit dass ein Student die Chips brennt und die Firmware behält: Ich denke der Schaden in diesem Fall läge bei nahe null da ihm die Firmware ohne Schaltplan/Produktionsstätten kaum was bringen wird. Er darf den nur nicht der chinesischen Fertigungsfirma zukommen lassen. Bei der ganzen Kryptographie: Da ja anscheinend ein AVR zum Einsatz kommen soll, habt ihr schon mal berücksichtig dass ein Bootloader doch nur sehr begrenzt Platz für derartige Routinen bietet?
Wenn er auch noch Sozialpädagoik-Studenten anlernt, dann ist die Wahrscheinlichkeit, dass die damit überhaupt etwas anfangen können minimal...Somit auch wenig Interesse daran haben, den Code mitzunehmen...
>habt ihr schon mal berücksichtig dass ein Bootloader doch
nur sehr begrenzt Platz für derartige Routinen bietet
Das geht wirklich, siehe AVR230, AVR231 (3DES oder AES-Bootloader mit
max. 2K Speicherverbrauch).
MfG Olaf
Mmh, also als studierter Informatiker muss ich auch mal meinen Senf dazu geben: 1. Es ist möglich, bugfreie Software herzustellen. 2. Es gibt bugfreie Software. Auch welche, die einen wirklichen Nutzen ergibt. 3. Es ist PRAKTISCH NICHT IMMER möglich dies auch zu beweisen. 4. Und bevor hier wieder diskutiert wird: Punkt 1 ist nicht bewiesen, sondern ein sog. Axiom. (Axiom (v. griech.: tà tôn progónon axiómata = als wahr angenommener Grundsatz) nennt man eine Aussage, die grundlegend ist und deshalb nicht innerhalb ihres Systems begründet werden kann bzw. muss.). q.e.d. (quod erat demonstrandum) so long 8astian PS: Noch was zum diskutieren: Ich meine, ich hätte mal folgendes gelesen: Wenn es nicht möglich wäre, bugfreie Software herzustellen, wäre es auch nicht möglich, verbugte Software herzustellen (auf Grund dessen, dass man Bugs nicht definieren könnte), also dürfte es keine Software geben.
Was nützt mir bugfreie Software, wenn die Hardware fehlerhaft ist. Ich glaube kaum, dass die Hersteller jeden einzelnen Controller 100% testen.
Wegen bugfreier Software: Theoretisch lässt sich Software ohne Bugs wunderbar herstellen. Entweder durch mathematische Methoden (Beweis etc.) oder durch entsprechende organisatorischen Methoden (Strenge Schnittstellendefinitionen) etc. Aber leider haben diese Ansätze alle ein entscheidendes Problem: Punkt 1.) Faktor "Mensch". Wenn eine Software nur ausreichend groß ist, ist die Wahrscheinlichkeit auch entsprechend hoch, dass dementsprechend viele Bugs enthalten sind. Ein Mensch kann problemlos einen mathematischen Beweis oder einen Algorithmus auf Papier schreiben, der ohne irgendeinen Zweifel korrekt ist. Danach fangen die Probleme aber schon an: Wenn ein Mensch nun einen Algorithmus ausführen muss, sei es manuell mit Papier und Bleistift, oder automatisch in dem er diesen abstrakten Algorithmus in eine Maschinensprache übersetzt, kann dieser Mensch Fehler machen. Die Wahrscheinlichkeit, dass ein Mensch Fehler macht, steigt mit der zu bewältigenden Aufgabe. D.h. wenn die zu lösenden Aufgabe nur groß genug, ist die Wahrscheinlichkeit dass der Mensch Fehler macht, sehr hoch. Ergo: Menschen können Fehler machen, und werden Fehler machen. Punkt 2.) Bug ist nicht gleich Bug. Man sollte zusätzlich auch bedenken, dass bei den Bugs ein Evolutionsdruck herscht und nur die fiesen, hinterhältigen und schwer zu finden Bugs überleben. Denn alle trivialen oder großen Bugs werden während der Softwareentwicklung oder im Betrieb sofort oder schnell gefunden. Diese Bugs haben kaum eine Chance zu überleben. Die Bugs die allerdings nur in ganz bestimmten Situationen auftreten, werden in der Regel kaum oder nie entdeckt, da eben die relevanten Situationen, bzw. Zustände, im Programm nur sehr selten oder in der momentanen Software-Benutzungs-Praxis oft nie auftreten. Ergo: Software enthält mit relativ geringer Wahrscheinlichkeit grobe Schnitzer die sofort zu Tage treten, aber dafür mit hoher Wahrscheinlichkeit Fehler die nur in bestimmten Situationen auftreten. Punkt 3.) Reale Welt Softwareentwicklung findet heute praktisch nie im Vakuum statt. Jeder Programm muss sich auf Compiler, Bibliotheken, Betriebssystem und Hardware verlassen, die alle mit hoher Wahrscheinlichkeit Fehler enthalten. Das heisst: Selbst wenn das eigentliche Programm fehlerfrei ist, kann es in Verbindung mit Bibliotheken, Betriebssystem und Hardware dennoch fehlerhafte Ergebnisse produzieren. Fazit der 3 Punkte: In der Praxis ist es nahezu unmöglich, fehlerfreie Software zu schreiben. Die Wahrscheinlichkeit, dass irgendwo ein schwer zu entdeckender Bug lauert, ist sehr hoch. Dieser Bug kann auch erst durch falsches Funktionieren von Betriebssystem oder Hardware verursacht werden. Aber die Erkenntnis bleibt: Software enthält Fehler. Als logische Konsequenz ergibt sich darauf: Wenn man die Fehlerfreiheit in der Praxis, in der realen Welt nicht garantieren kann, muss man mit Fehlern leben. D.h. man muss für den Fehlerfall planen und ein Fehlermanagement betreiben. Und genau das wird ja gemacht. Betriebssystem existieren, um verschiedene Programme gegeneinander abzuschotten. Laufzeitumgebungen und Programmiersprachen werden so gestaltet, um Fehler effektiv erkennen zu können und darauf reagieren zu können. Code wird wiederverwendet, um die Wahrscheinlichkeit für neue Bugs zu minimieren, usw. Nichts desto trotz sollte das Ziel jeder Softwareentwicklung sein, möglichst absolut fehlerfreien Code zu schreiben. Doch wer daraus ableitet, dass sein Programm niemals Fehler enthalten könne, ist ein Narr.
Hallo zusammen, dass Alles irgendwie zu knacken ist das ist schon logisch. Es sollte eben nur ein Schutz sein der nicht ganz einfach zu umgehen ist in dem man eine Kopie macht und dann sämtlich Unterlagen hat um die Produktion weiter zu machen. Es ist schon ein Problem wenn man alle wichtigen Unterlagen an eine Firma weitergibt. Besser wäre es die Pläne für die Hardware an eine Firma zu geben und die Softwar bei einer anderen Firma erledigen zu lassen. So hat keine Firma alle Unterlagen. Das ist wohl die beste Lösung. Gruß Robert
Wenn Du nicht mindestens genauso viel Gehirnarbeit in das eigentliche Produkt gesteckt hast wie in den Kopierschutz, ist es das eh nicht wert. Wenn irgendwelche Probleme mit dem Kopierschutz dem Komfort bei der Bedienung / Benutzung hinderlich sind, wirst Du auch nicht allzuviel davon verkaufen. Da sollte schon eine vernünftiges Verhältnis vorhanden sein. Wenn man sich so auf den Kopierschutz versteift, leidet meistens das Produkt darunter und wird minderwertig (wenn es das nicht schon ist). Eine weitere Absicht, die ich nicht unterstelle, ist das man verhindern möchte, dass jemand anders herausfindet, dass man selber alles nur geklaut hat. Arno
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.