Ich schreibe gerade ein Berechnungsprogramm für Maschinenlemente (beispielsweise Getriebe). Das Programm berechnet Ergebnisse, die zum einen auf Herstellerdaten des Bauteils (manu_x, manu_y, manu_z) und zum anderen auf Benutzereingaben (usr_x, usr_y, usr_z) des Programmbenutzers basiert. Im Endeffekt hat man also eine (bekannte) Funktion, die das Ergebnis (erg_xyz) folgendermaßen berechnet: erg_xyz = function (usr_xyz, manu_xyz) Nun ist es allerdings so, dass der Hersteller seine internen Daten (manu_xyz) nicht offenlegen will, da man auf bestimmte Interna schließen könnte. Die einzige Möglichkeit wäre, dass der Hersteller seine Daten "verschlüsseln" (manu_xyz_enc) könnte. Gibt es deshalb eine automatisierte und standardisierte Möglichkeit, dass man die eigentlichen Parameter in der Berechnung versteckt, aber die Berechnung trotzdem noch stimmt? Also: erg_xyz = function_encrypted (usr_xyz, manu_xyz_enc)? Danke für eure Hilfe! Stefan
nein...zum rechnen brauchst du logischerweise die daten in rohform. wenn du die in der funktion entschlüsselst macht es keinen sinn diese überhaupt zu verschlüsseln...
TestX schrieb: > macht es keinen sinn diese > überhaupt zu verschlüsseln... Keine ist vielleicht übertrieben, aber im Prinzip muss alles, was irgendwie verwendet wird, egal ob Programm, Daten, Keys usw., unverschlüsselt im Speicher sein. Daher ja die Bemühungen um Malware, die Speicherbereiche anderer Programme auslesen kann. Du könntest zwar innerhalb der Funktion die Daten entschlüsseln, die Berechnung durchführen und die Daten gleich wieder löschen, um das Riiko zu verringern - aber dann müsstest du auch alle Spuren der Daten im RAM und Cache löschen, was deine Möglichkeiten sicher weit überschreitet, und noch dazu würde deine Funktion, wenn sie jemand reengeneert, die Geheimnisse deines Kunden offenlegen. Wenn die noch alle beisammen haben werden sie dem Verfahren niemals zustimmen. Georg
Hi! Mach dass was Google und Co auch machen. Verlagere die Berechnung auf einen Server im Internet und lass den Client nur die Eingaben abfragen und die Ergebnisse anzeigen. LG Stefan
wie wäre es mit einem (schlecht hackbaren) dongle das die parameter übermittelt bekommt, und das ergebnis ausspuckt?
Oder du lieferst eine Smartcard, welche die Internen Daten beinhaltet und die Berechnung macht. Aber generell wenn sich das Ergebnis so berechnen lässt erg_xyz = function(usr_xyz, manu_xyz) gibt es eine inverse Funktion für die gilt: manu_xyz = function_invers(usr_xyz, erg_xyz) Das gilt auch für Kryptofunktionen. Sicher kann die inverse Funktion eine andere Komplexität haben, aber wenn die Funktion bekannt ist und manu_xyz interessant genug, sollte man das im Hinterkopf behalten.
Stefan H. schrieb: > Im Endeffekt hat man also eine (bekannte) Funktion, die das Ergebnis > (erg_xyz) folgendermaßen berechnet: > > erg_xyz = function (usr_xyz, manu_xyz) Wenn function dem Benutzer nicht nur bekannt, sondern auch (zumindest abschnittsweise) umkehrbar ist, kann aus einem oder mehreren Paaren von erg_xyz und usr_xyz leicht manu_xyz berechnet werden. Dazu ist keinerlei Hacker-Expertise erforderlich, und dagegen helfen weder eine Verschlüsselung noch ein Dongle noch ein Web-Server.
Yalu X. schrieb: > Wenn function dem Benutzer nicht nur bekannt, sondern auch (zumindest > abschnittsweise) umkehrbar ist, kann aus einem oder mehreren Paaren von > erg_xyz und usr_xyz leicht manu_xyz berechnet werden. Und wenn ncht, dann nicht. Also wäre die Frage zu klären, ab man die Herstellerparameter in der Berechnung so kombinieren kann, daß kein Rückschluß auf die eigentlichen Werte mögich ist. Oliver
Wir machen das so, dass die Funktion noch Zusatzparameter erhält, welche in Abhängigkeit der Werte die Kurve deformieren. Die Rechnung biegt es wieder gerade. Die Zusatzparamter sind für jeden Kunden und jedes Gerät und jedes Ergebnis individuell. D.h. kein Kunde kann durch Vergleich der Ergebnisse auf die Berechnung schließen, auch nicht mit mehreren Geräten. Das Ganze machen wir aber weniger, gegen den Kunden, sondern gegen die schlitzäugigen Fälscher, die Geräte und Disposables nachbauen. Die Parameter der Disposables werden vermessen und fliessen in die Rechnung ein. Die Methode ist für jedes Objekt und Charge anders und wird von Gerät zu Gerät geänadert, damit nicht Mitarbeiter die Methode zur Konnkurrenz mitnahmen. Die GEräte bekommen einmal im Jahr ein SW-Update, wenn sie im Servive sind. Die Funtion ist für 3 Chargen gültig, d.h. auch wenn ein Kunde ein Gerät mal nicht zum Servie schickt und ein SW-update übersprungen wird und zugleich Chargen mit überlappender Änderung verwendet werden, klappt es noch. Außerhalb dieses ranges sind die Messergebnisse ungenau. Der Kunde weiß das und hat es schriftlich, dass er die Geräte nicht verwenden darf, wenn sie länger, als 18 Monate nicht im Service waren. Er hat das auch schriftlich, dass er Chargen nicht verwenden darf, wenn sie älter als 9 Monate sind. Tut er es dennoch, macht er sich strafbar, weil es in Richtung Patientengefährdung geht. Der Kunde kann also nicht in China Disposeables einkaufen, selbst wenn er es aktiv tun wollte. Ausgeschlossen ist somit auch das stillschweigende Unterschieben von Chargen aus dem Ausland, die abgelaufen sind. Die Geräte plärren Alarm, wenn die nicht mehr passen. Möglich wird das durch parameterische Funktionen mit Selbsidentitäten, die sich druch richtiges Mehrfachanwenden auf ein ander abbilden. D.h. für jeden Punkt in der Kurve gibt es eine analytische Korrektur. Diese sind linear unabhäng, sodass die Reihenfolge egal ist. Man kann also erst Parameter 1 korrigieren, dann 2 und dann 3 und oder auch 2,3,1 - es kommt dasselbe raus. Die Vorschrift sieht dann so aus: Y = F (a,b,c,d , k(a), k(b), k(c), k(d) ) k(a) ist die Korrekturfunktion für die Werteliste a. Sie funktioniert für alle Messwerte, für die a definiert ist, also z.B. die Menge in Millilitern. Konkret wird hier ein Durchflussmesser, dessen Werte ungefähr quadratisch mit der Geschwindigkeit gehen, korrigiert. Die Funktion k(a) macht es genauer, baut aber andere Nichtlinearitäten ein. Aufgelöst wird es intern in der Rechung, in dem zunächst gerechnet wird: a* = k*(a), b*= k*(c) ... d.h. auf die übergebenden Parameter a,b,c,d werden 4 Entzerrfunktionen losgelassen, die neue a*, b*, c*, d* erzeugen. Diese fliessen dann in die Formel. Die Formel selber ist in C verbacken und nicht direkt außen beobachtbar. k und k* werden für alle Paramter paarweise gebildet. Wie gesagt für jeden Kunden und für jedes Gerät etwas anders. Der Kunde kann dann zwar Chargen, die für dieselbe Geräteklasse zugelassen ist, untereinander austauschen, aber nur vertikal, also nicht über die Zeit. Er muss dazu auch nichts Neues berechnen oder vermessen, sondern die Toleranzbreite steckt in den Chargencodes mit drin.
Da wird wieder mal so viel Energie komplexitätssteigernden aber vollkommen zweckfreien und sinnlosen Firlefanz gesteckt, wenn das stattdessen in das eigentliche Produkt fließen würde käme ein besseres Produkt heraus. Und der Kunde wäre dankbar weil er nicht schon wieder pauschal als Feind klassifiziert wird mit einem Produkt das vor virtuellen Defensivwaffen die alle gezielt gegen ihn gerichtet sind nur so strotzt und damit unter Umständen auch noch seine wertvolle Zeit und Nerven vergeudet weil es alles was einfach sein könnte unnötig verkompliziert. 0.02€
Du könntest einen Satz Näherungsfunktionen berechnen (z.B. Polynome, Splines, Bézierkurven), in dem jeweils die Hersteller-Parameter schon einberechnet sind. Das Ergebnis ist eine Tabelle von Konstanten für die jeweilige Approximation. Daraus auf die Hersteller-Parameter zu schließen ist schwierig.
Danke schonmal für die Antworten! Ich habe jetzt ein paar Ideen, was möglich ist. - Die Daten online zu berechnen (beim Hersteller) ist eine interessante Idee. - Eine Smartcard oder Dongle ist wahrscheinlich zu aufwändig. @Yalu: Das mit der Umkehrbarkeit habe ich verstanden, ich denke aber dass die Funktion nicht ohne weiteres eineindeutig umkehrbar ist. @Tippgeber: Das ist ein ziemlich abgefahrenes Verfahren, ich muss da nochmal eine Weile drüber nachdenken. Ich muss mal schauen, ob das für meinen Fall anwendbar ist, aber sowas in der Art habe ich mir vorgestellt. @prof7bit: Ich gebe Dir recht. Eigentlich sollte man sich lieber auf das Programm konzentrieren, anstatt sich mit solchen Spielereien zu beschäftigen. Aber: Das Problem ist, dass das Berechnungsprogramm von den Daten lebt, die die Hersteller (das sind in diesem Fall nicht wir) zur Verfügung stellen. Ohne diese Daten (in "verschlüsselter" Form oder wie auch immer), ist der Mehrwert des Programms wertlos, da man doch wieder beim Hersteller anrufen und sich die Werte einzeln erbetteln muss oder die Berechung direkt an den Hersteller abgibt... @Alle: Danke für die vielen Guten Hinweise!
Stefan H. schrieb: > erg_xyz = function_encrypted (usr_xyz, manu_xyz_enc)? Wertetabellen aus User-Eingaben, gemessenen manu-Werten und den Werten des erg_xyz aufstellen rein in Excel, xy-Tabelle erstellen, Messreihen darstellen lassen und von Excel Trendlinie einzeichnen und deren Funktion darstellen lassen das ist die Methode per-Hand-zu-Fuß
:
Bearbeitet durch User
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.