Sichere History

[lordnaikon]

Guten Tag!

Ich bin gerade ein wenig am knobeln über ein Problem und wollte mal nach nen paar Meinungen fragen. Ich weiß selber noch nicht so genau die Randbedingungen, die hängen auch ein wenig davon ab, wie das Problem gelöst wird.

Zum Thema:

Ich möchte eine "sichere" History haben. Sicher soll in diesem Kontext so viel heißen wie, nicht manipulierbar. Es geht darum, dass ich die Arbeitsschritte in meinem Programm protokollieren will und dieses Protokoll soll, nach Möglichkeit, nicht manipuliert werden können. Um zu verhindern, dass keine Schritte entfernt oder hinzugefügt werden dachte ich mir, ich bilde über jeden Schritt einen Hash. Jeder nachfolgende Schritt erhält diesen Schritthash über den dann wieder der Hash gebildet werden und dem nachfolgenden Schritt mitgegeben werden kann.

[Protokollschritt[#GenesisHash]]->[Nachfolgeschritt[#ParentHash]]->...

Bsp.: (Hashfunktion hier Quersumme)

[123[0]]->[234[6]]->[345[15]]->[789[27]]->...

somit würde verhindert, dass man ein einzelnes Glied manipulieren kann ohne die gesamte Historie neu zu berechnen. Jetzt bleibt natürlich noch das Problem, dass es mit Kenntnis der Hashfunktion ein leichtes ist die Kette neu zu berechnen. Um dies zu Umgehen wollte ich die Hashes mit einem öffentlichen Schlüssel verschlüsseln. Der private bleibt nat. Geheim und wird nur z.B. auf Serverseite dazu verwendet die Hashes zu entschlüsseln um die History zu überprüfen.

Ich hatte mir auch überlegt, die ganze Datei, in der sich die History befindet, einfach zu verschlüsseln. Ich habe aber vor mit dem Programm die History auch lesen zu können. Damit müsste ich aber die Datei auch wieder im Programm entschlüsseln, hier hätte ich dann auch Angst, dass mir das einer mit Reverse Engineering bricht, die Schlüssel, Passwörter usw rausfummelt.

Hat einer Anmerkungen dazu, sieht starke Schwächen, weiß ne bessere Variante? Ich hab sowas halt noch nie gemacht und wüsste auch nicht wonach ich da bei google suchen sollte. Darum hab ich mir das eben mal so zusammengereimt. Vielleicht gibt es ja ne "Standard Implementierung" für sowas, die ich einfach noch nicht kenne und sie mir hier einer verraten kann.

mfg LordNaikon

//EDIT: beim drüber lesen ist mir schon nen Fehler aufgefallen, ich kann gar nicht die nachfolgenden Hashes berechnen, wenn ich die vorhergehenden schon verschlüsselt habe (ohne sie lokal entschlüsseln zu können) .. mist :/ ...

jemand ne bessere Idee... ?

[Hyperion]

jemand ne bessere Idee... ?

Naja, mal so ganz naiv: Belasse das doch einfach auf der Server-Seite. Das wäre wohl die einfachste Art, das ganze vor Manipulation zu schützen...

[nomnom]

Du kannst dir ja mal anschauen, wie Bitcoin das macht. Vielleicht ist das ja ganz interessant.

[BlackJack]

@lordnaikon: Ergänzend zu Hyperion: Nadeldrucker mit Endlospapier in einem gut gesicherten, verschlossenem Raum. Am besten redundant ausgelegt.

[lordnaikon]

jemand ne bessere Idee... ?

Naja, mal so ganz naiv: Belasse das doch einfach auf der Server-Seite. Das wäre wohl die einfachste Art, das ganze vor Manipulation zu schützen...

Ja, es gibt auch eine Serverseite an die das auch, im beste falle zeitgleich, übertragen wird. Wie gesagt, ich bin mir der Anforderungen selber noch nicht bewusst, weil ich noch nicht weiß wie man gewisse Sachen (wie das hier besprochene Problem) überhaupt lösen kann. Höchstwahrscheinlich wird es aber nötig sein, für denn Fall das der Server nicht erreichbar ist, die Historie lokal in sicheren Tüchern zu haben. Aber so naiv ist das nicht, wohl eher die, bis jetzt, sicherste Möglichkeit überhaupt ?!

Du kannst dir ja mal anschauen, wie Bitcoin das macht. Vielleicht ist das ja ganz interessant.

Danke! Kannst du mir vielleicht eins zwei buzzwords geben zum quer einsteigen? Ich habe mich leider noch nicht so recht mit dem System Bitcoins auseinandergesetzt. In wie weit ist so ein Historien-System in Bitcoin integriert, wofür wird es eingesetzt ..usw

@lordnaikon: Ergänzend zu Hyperion: Nadeldrucker mit Endlospapier in einem gut gesicherten, verschlossenem Raum. Am besten redundant ausgelegt.

Auch wenn das für den einen lustig klingen mag aber diese Überlegung (zumindest in diese Richtung) gab es wirklich. Leider ist sie eventuell nicht praktikabel, es werden wohl ziemlich viele Daten in recht kurzer Zeit anfallen. Leider bleibt dort auch das, eventuell gewünschte, lokale Backup, falls Serverausfall, unberücksichtigt.


Man könnte das Problem, dass ja die Hashes verschlüsselt sind umgehen, in dem man die Hashes als Klartext und verschlüsselt speichern. Das die Hashes quasi mit dem Public-Key signiert werden. Genau auf die Art und Weise, wie man Emails signiert.

So jetzt werd ich mich mal auf die Suche nach dieser Bitcoin Sache machen ...

[deets]

Der Server hilft nur bedingt. Er verhindert das nachtraegliche manipulieren, aber nicht, dass die verschickten Daten schon ohnehin falsch sind.

Und platt gesagt: alles, was auf deinem System an Code ausgefuehrt wird, ist manipulierbar. Systeme wie die PS3 und aehnliche wurden mit einer Vielzahl von Sicherheitsmechanismen ausgestattet, um das ausfuehren von nicht-signiertem Code zu verhindern. Und selbst die sind gecknackt.

Wenn es sich bei deiner Software also um eine normale Desktop-Anwendung handelt, auf einem normalen System (egal welches) - dann wird, bei entsprechendem Aufwand, das ganze manipulierbar.

Das einzige, was dagegen *wirklich* hilft ist, entscheidende Berechnungen auf ein externes System auszulagern. ZB einen Server, oder einen intelligenten Dongle.

[jerch]

@lordnaikon:
Mit der Forderung nach einer sicheren History forderst Du eigentlich sicheren Speicher, ohne diesen kann ein böser Bub Dir immer AktionBöseX+Y als AktionSchäfchenZ verkaufen. Und sobald lokaler Zugriff besteht, ist es um die Speichersicherheit schlecht gestellt. Dongles, Codeobfuscatoren und zusätzliche Speicherüberwachungstools können die Hürde zur erfolgreichen Manipulation zwar massiv erhöhen, gänzlich verhindern jedoch nicht.

Je nach dem, welchen Sicherheitsanspruch Du verfolgst, ist die Degradierung des Clients bis hin zum reinen Anzeigetool von Nöten, d.h. sowohl Ressourcen als auch Berechnungen werden vom Server bereitgestellt/durchgeführt.

Interessant zu diesem Thema ist ein Paper einer Hackergruppe, die den Skype2+ Client mal auseinander genommen hat. Das war ein ziemlich schwieriges Unterfangen, da Skype selbst fiese Tricks benutzte, um dies zu verhindern (und daraufhin von einigen Virenscannern als Malware erkannt wurde). Genützt hats nix sondern war wohl eher Ansporn

[lordnaikon]

@deets: Ja richtig, keiner garantiert mir, dass mein Programm nicht schon so gepatcht ist, dass es einfach schon die manipulierten schreibt und sendet. Wie gesagt, es wird bestimmt nicht möglich sein vollends auf einen Server vertrauen zu können, da das Programm, im Falle einer Unerreichbarkeit des Servers, weiter funktionieren muss.

@jerch: wenn du von "Speicher" redest, meinst du damit RAM im speziellen oder jeglichen Teil des Speichers, den meine Anwendung verwendet. Denn gesetzt dem Fall RAM und Programm sind sicher und zum Zeitpunkt des Zugriffs die HDD auch und die Historie ist verschlüsselt abgelegt, sollte es doch nicht mehr Manipulierbar sein oder?

Danke erstmal an euch alle für die vielen Kommentare. Heinrich Kleist hatte recht in seinem Aufsatz: "Über die allmähliche Verfertigung der Gedanken beim Reden[Schreiben ]". Mir ist (nun) selber klar, das es das sichere System nicht geben kann. Aber wie der Fall Skype zeigt, kann man die Integrität eines Programmes etwas länger als üblich erhalten.
Ich bin wie gesagt auf der Suche nach praktikablen Umsetzungen. Un dazu braucht man Randbedingungen. Eine ganz wichtige in diesem Zusammenhang ist Zeit. Das Programm selber wird nur ca. 3-4h (höchstens) in der freien Wildbahn sein (was danach passiert ist relativ egal). Mit dieser Zeitvorgabe könnte man schon so arrogant sein(ich setzte das jetzt voraus), dass man das Programm und den Hauptspeicher mit einfachen Mitteln als sicher betrachten kann.

Wie sieht es dann aus?
Was mir noch schmerzen bereitet bei oben genanntem Verfahren ist, dass der Schlüssel zum schreiben des verschlüsselten Hashs nicht entwendet werden darf, somit ist das doch auch wieder Blödsinn. Die Hashes stehen eh im Klartext da also braucht man gar keinen privaten Schlüssel mehr ... public key macht hier, wenn die Hashes Klartext und verschlüsselt angegeben werden keinen Sinn...

leider habe ich noch keine Zeit für die Bitcoins gefunden.

[lordnaikon]

Ok neuer Versuch.

Es wird immer nur der verschlüsselte Hash gespeichert. Danach ist er vom Client nicht mehr lesbar. Es wird aber, um eine neue Historie zu erstellen der Hash der letzten Historie im Hauptspeicher gespeichert.

*[letzterHash]

[Protokollschritt[#GenesisHashEnc]]->[Nachfolgeschritt[#ParentHashEnc]]->...

*[6]
[123[encOfGen#]]

*[15]
[123[encOfGen#]]->[234[encOf6]]

*[27]
[123[encOfGen#]]->[234[encOf6]]->[345[encOf15]]

*[51]
[123[encOfGen#]]->[234[encOf6]]->[345[encOf15]]->[789[encOf27]]

.....
Damit kann ich, mit Kenntnis des letzten Hashes und dem "öffentlichen" Schlüssels, sollten diese aus meinem Programm entwendet werden(darum ist öffentlich hier immer in klammern denn der Schlüssel soll nicht öffentlich sein, ich will mir nur den Umstand zu nutze machen, dass ein Schlüssel verschlüsselt der andere entschlüsselt ), einen neuen Eintrag erzeugen. Kann die Einträge(im speziellen die verschlüsselten Hashes) selber, mit dem "öffentlichen" Schlüssel, aber nicht mehr lesen, um neue Knoten zwischendrin zu erstellen oder welche zu löschen und den Nachfolger neu berechnen. Die Historie selber ist für den Client aber lesbar.

Gesetz dem Fall, dass das Programm, aufgrund von Manipulation, selbst keine falschen Einträge erzeugt, dürfte die bisher erstellte Historie nicht mehr manipulierbar und korrekt sein, richtig? Es ist aber noch Möglich, falls der Schlüssel und der letzte Hash bekannt werden neue Einträge zu erzeugen.

Auf dem Serven kann ich die Historie dann validieren, in dem ich die verschlüsselten Hashes mit meinem "privaten" Schlüssen entschlüssle und diesen Hash mit den selber generierten Hashes vergleiche.

*immer noch nicht geschafft bitcoin anszusehen*

[deets]

Ich denke, du kannst das einfacher machen, indem du einfach nur ein geteiltes secret mit in die schritt-hash-berechnung packst - statt den public key. Denn letztlich ist das genauso sicher, nur einfacher: wer deinen code soweit zerlegen kann, dass er das secret kennt, der kennt auch den public key, und damit ist Polen offen.

Eine Moeglichkeit waere uebrigens, dieses Secret nicht im Programmcode auszuliefern, sondern stattdessen bei Programmstart per Eingabe abzufragen. Dann gilt es nur fuer die Laufzeit des Programms - welches natuerlich tunlicht nicht abstuerzen sollte. Aber da kann man uU auch noch tricksen, indem man einen Envelope-Prozess macht, der das eigentliche Programm forkt, und dann das secret kommuniziert. Kommt auf deine Programmierkuenste an

[nomnom]

@lordnaikon: Ich weiß auch nicht so genau wie Bitcoin das macht … Auf jeden Fall werden da SHA-Hashes generiert für jede Transaktion und die werden dann in eine Chain aufgenommen und wenn dann da z. B. was dazu kommt, das nicht den Anforderungen entspricht, fällt das auf und das Geld ist „ungültig“.

[jerch]

@lordnaikon:
Was willst Du mit der "sicheren" History erreichen?
Die History wird relativ sicher, indem Du einfach den vorherigen Hash als Salt für die nächste Hashberechnung nutzt (Pseudopythoncode):

Code: Alles auswählen

history = []
hash1 = sha2(aktion1)
history.append(hash1)
hash2 = sha2(hash1+sha2(aktion2))
history.append(hash2)
# usw.

Da Hashs ohne absurden Zeitaufwand nicht rückberechenbar sind (Kollisionsberechnung), ist der Zweig im Aktionsbaum nur über den Wurzelknoten nachvollziehbar, allerdings musst Du die nächste Aktion immer mit O(n) unter n möglichen Aktionen suchen.
Damit ist zwar die History sicher, aber was nützt Dir das? Oder anders gefragt, ist Dein Haus sicherer, wenn Du die vordere Eingangstür mit Panzerglas, Mehrfachverriegelung und Alarmanlage ausstattest, die Balkontür aber offen steht?

[lordnaikon]

@deets: Es gibt aber folgenden Unterschied. Benutze ich nur ein normales secret, dann ist es einem Angreifer möglich, nachdem er ihn herausgefunden hat, die komplette Historie zu verändern. Dagegen kann er mit dem "public"Schlüssen nur Daten anhängen aber die schon erstellte Liste nicht mehr verändern. Desweiteren muss ich mir Gedanken über den sicheren austausch des secrets machen. Hier sehe ich schon noch gewisse Vorteile für das Schlüsselpaar. Den letzten Absatz mit dem "Envelope-Prozess" habe ich leider nicht richtig verstanden ... was meinst du genau?

@nomnom ich bin gerade das Hier am lesen (http://bitcoin.org/bitcoin.pdf), leider quatscht der Prof. in seiner Vorlesung immer dazwischen, da komm ich mit dem Verständnis nicht so ganz nahe. Was aber immer wieder ins Auge springt: " As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attacker"

So wie ich das verstanden habe läuft es so ab, dass man einen gewissen Rechenaufwand hat (http://en.wikipedia.org/wiki/Proof-of-work_system) Um jetzt einen gefälschten Eintrag (falsche Überweisung) zu tätigen muss man, aus der aktuellen Überweisungshistorie(die öffentlich bekannt ist) einen Knoten manipulieren (aufwendig berechnen) und alle Folgeknoten ebenfallst. Damit erstellt man einen "Fork" der Historie. Jedoch wird man die Historie und im speziellen seinen Fork, nicht so schnell Vorrantreiben können, wie alle anderen, die nicht bescheissen. Der "Fork" der am längsten ist und somit in dem mehr rechenpower liegt, gewinnt - ist der akzeptierte. Ich weiß noch nicht ob ich das auf mein Problem übertragen kann. Zum einen ist der Benutzerkreis recht eingeschrägt - ein Angriff mit Cloudcomputing im Wert von < 500$ sollte genügen um die Rechenpower aller anderen Clients zu übertrumpfen. Zum anderen müsste ich dann alle Historien öffentlich machen. Das würde wieder Server oder zumindest P2P Kommunikation erfordern. Ein Sinn hinter der Historie soll ja gerade sein, bei Ausfall des Servers weiter aufzuzeichnen.

[lordnaikon]

@jerch: Sry wenn ich mich gerade zu doof anstelle. Aber was hindert mich daran, wenn ich deine Historie habe, sie zu ändern? Mit Kenntnis der Hashfunktion kann ich doch jede beliebige Historie berechnen, oder? Gibt es zehn Aktionen kann ich den Hash von Aktion zwei lesen, einen dritten manipulierten erstellen und alle Folgeaktionen neu berechnen.

Ich bin mir der Gefahr eines gepatchten Programms bewusst, dass schon eine falsche Historie erstellt. Aber ich sehe das erstmal als eine andere Baustelle, da muss sich gesondert drüber Gedanken gemacht werden. Mir geht es darum, mit der Prämisse das die Historie manipulationsfrei erstellt wurde, wie "schütze" ich diese vor Veränderung mit der Bedingung, dass ich sie(die eigentlichen Daten) noch lesen kann.

[deets]

@lordnaikon

Noe, stimmt nicht. Wenn ich das secret bzw. den Schluessel habe & daten noch nicht auf dem server sind, dann kann ich auch mit deinem Schema alles wieder von vorne aufbauen. Was hindert mich denn daran?

wenn schon was beim Server ist, dann muss ich halt ab da aufsetzen.

[lordnaikon]

@lordnaikon

Noe, stimmt nicht. Wenn ich das secret bzw. den Schluessel habe & daten noch nicht auf dem server sind, dann kann ich auch mit deinem Schema alles wieder von vorne aufbauen. Was hindert mich denn daran?

wenn schon was beim Server ist, dann muss ich halt ab da aufsetzen.

guter Einwand, danke. Daran habe ich gar nicht gedacht. Sollte man den Schlüssel haben und den Hash. Kann man alles löschen und neu aufbauen. Oder doch nicht... also Man müsste auf diesen "GenesisHash" aufbauen. Dieser Müsste initial vom Server, bei der Anmeldung, dem Client mitgeteilt werden. Nach dem der erste historien Eintrag erstellt wurde wird er vom Client vergessen. Somit kann ich keine neue Historie, ohne Kenntnis des initialen Hashs, erstellen.

[jerch]

@jerch: Sry wenn ich mich gerade zu doof anstelle. Aber was hindert mich daran, wenn ich deine Historie habe, sie zu ändern? Mit Kenntnis der Hashfunktion kann ich doch jede beliebige Historie berechnen, oder? Gibt es zehn Aktionen kann ich den Hash von Aktion zwei lesen, einen dritten manipulierten erstellen und alle Folgeaktionen neu berechnen.

Richtig - aber das ist doch immer möglich, wenn Du nicht eine sichere Quelle hinzuziehst. Z.B. könnte der Server alle "Orginalhashes" vorhalten, kommt es zu Unstimmigkeiten, gilt was dort steht, da er als prinzipiell sicherere Datenquelle anzusehen ist. Die Manipulation wird dann offensichtlich. Das geht wieder in die Richtung, Vertrauen vom Client abzuziehen und Funktionalität auf den Server auszulagern.

Wenn Du erlauben willst, dass der Client zeitweise ohne Serververbindung weiterarbeiten darf, wirds schwierig. Dann hilft evtl die Unterteilung der Aktionen in kritisch und nicht kritisch. Kritische Aktionen brauchen immer ein Server-ACK, nicht kritische dürfen lokal vorbearbeitet werden. Mit einem nächsten kritischen wird auch die History übertragen und ist damit fix (weil serverseitig bestätigt). Für nicht kritische ist lokal die History bearbeitbar, nur hat das ja keinen Effekt, da das Endergebnis auf dem Server zählt und der Server die zwischenzeitlich andere History nicht sieht. Das Vertrauen liegt hier wieder beim Server.

[deets]

@lordnaikon

Jein. Das ist letztlich genauso, als ob du dann halt das secret vom server beziehst - damit kannst du dir dann den public key gleich ganz sparen. Nur ist das in deinem ja leider voellig unterspezifizierten Szenario eine starke Randbedingung. Dann darf naemlich weder der Server nicht verfuegbar sein, wenn das Programm startet, noch die Software jemals abkacken.

[lordnaikon]

@jerch: "Richtig - aber das ist doch immer möglich" ich meine nein. Bei meinem Ansatz, so glaube ich zu wissen ( ) ist es nicht möglich eine Historie, unter der Prämisse der validen Erstellung, im nachhinein zu verändern. Um auf deine Unterteilung in kritisch und nicht kritisch aufzubauen. Die Anmeldung am Server muss erfolgen, und ist als kritisch anzusehen. Danach muss die Anwendung weiterlaufen, auch wenn der Server ausfällt. In solch einem Fall muss die Historie "nachgesendet" werden zur Not einfach per Email. Unter der Voraussetzung, dass die Anwendung, während der Erstellung der Historie, nicht manipuliert wurde, darf die Historie später nicht mehr veränderbar sein, egal ob ich dann, nach der validen Erstellung der Historie, die Anwendung manipuliere, Schlüssel extrahiere usw. Ich will keine absolute Sicherheit, die es nicht gibt, ich will praktische Sicherheit, die es einfach nur schwer macht. Wie gesagt gäbe es einen Ansatz, wenn ich den Schlüssel habe und den letzten Hash im Klartext, weitere Schritte an die Historie anzufügen.

@deets: Deine Kritik an den fehlenden Randbedingungen sind absolut berechtigt. Das Problem ist, ich kann (oder konnte) noch keine näheren Randbedingungen setzen, weil ich über die Möglichkeiten noch nicht bescheid weiß (wusste). Für mich kristallisiert sich das gerade erst, vor allem durch diese Diskussion, heraus. Eine Initiale Kommunikation mit dem Server ist wohl von Nöten, alleine für die Benutzererkennung. Das Programm zeigt unterschiedliches Verhalten pro Benutzer/Gruppe. Meine Kritik an dem symmetrischen Secret bleibt, habe ich diesen erst einmal, kann ich die gesamte Historie nach belieben verändern. //Edit: Dafür spricht, ist das Programm beendet und aus dem Speicher, komme ich an den Secret nicht mehr heran, an den Schlüssen schon denn er muss sich im Programm irgendwo befinden. Allerdings darf das Programm danach nicht abstürzen. das gleiche Problem habe ich aber auch mit dem Schlüssen, denn da muss ich ja den letzten Hash im Klartext vorhalten. Schwierig ... :/

[deets]

@lordnaikon

Deine Kritik bleibt unberechtigt. Wenn bei der *Erstellung* der Historie nicht ein Secret einfliesst, dass vom Server bezogen wurde (dein initialer Hash ist nichts anderes als genau dass), dann ist saemtliches asymetrisches verschluesseln spaeter voellig irrelevant - denn es kann nachvollzogen werden.

Und wenn zwischendurch der Server aussetzt, und die History lokal geschrieben wird - dann kann ich sie auch wieder neu schreiben, sofern ich Zugriff auf zB den Speicher habe.

Ich begreife nicht, warum du ein Secret im Speicher oder Programmcode weniger sicher bewertest als einen Public key.... Das secret wird ja nicht zur *entschluesselung* verwandt, sondern ist einfach nur Bestandteil des hashes, damit man den nicht einfach nur in Kenntnis des eigentlichen Algorithmus nachbauen kann.