vorweg: Bei mir in der Uni ist Kryptographie nicht so wirklich behandelt worden, das ist definitiv nicht meine starke Seite.
ich würde gerne eine App schreiben, die Inhalte mit einem privaten Schlüssel signiert den nur sie kennt. Dieser Schlüssel kann beispielsweise beim Installieren der App generiert werden. Etwas anderes soll die App nicht tun. Wichtig ist, dass niemand sich als die App ausgeben darf, um etwas anderes zu signieren und sich als die App auszugeben.
Wie ich Schlüssel erzeuge und Dateien signiere ist mir soweit klar. Das Problem ist aber, dass auf alle Fälle verhindert werden muss, dass jemand an den privaten Schlüssel kommt. Auch der User der App soll nicht in der Lage sein seinen Schlüssel zu extrahieren. Niemand, der Root Zugriff auf das Handy/den Laptop hat, niemand der einen Dump zieht. Ist so etwas überhaupt möglich? Für Hardwarelösung gibt es ja Chips die so etwas übernehmen, wie würdet ihr bei Software, welche auf einem “untrusted” Gerät läuft damit umgehen? Habt ihr Literatur die ihr mir hier empfehlen könnt?
Kurze Antwort: das geht nicht. Sofern jemand Rootzugriff auf das Gerät hat, kommt er an die Daten. Und sei es nur über einen Speicherdump.
Nachtrag: selbst bei einigen Hardwaremodulen kommt man an den Schlüssel, wenn man die geeigneten Gerätschaften hat. Kürzlich gab es auch ein Sicherheitsproblem mit Chips, bei denen sich die privaten Schlüssel errechnen ließen, weil sie schlecht generiert wurden.
Ich denke, dass das nicht gehen wird. Wie soll ein Stück Software sich auf einem “untrusted” Gerät gegen Auslesen schützen? Du kannst es Angreifern vielleicht ein wenig schwerer machen, aber letztendlich ist das alles nur “Security by Obscurity”. Die einzig sicheren Wege für sowas sind
Hardware
ein Server unter deiner Kontrolle
eventuell noch eine Peer-to-Peer Lösung, bei der die “faulen Eier” überstimmt werden können (Blockchain?)
Danke euch beiden, ich hatte soetwas schon befürchtet.
@Landei: Um Blockchain geht es sogar, der private Schlüssel hätte der des Accounts sein sollen. Ich würde gerne sicherstellen, dass sich NUR das Gerät über diesen Account verbinden darf. Dann muss ich noch mal in den Denkteich, wie man etwas ähnliches erreichen kann.
Also wenn du das ohnehin über Accounts lösen willst, dann hast du doch einen Server unter deiner Kontrolle. Für eine Verbindung zu diesem muss sich die App authentifizieren, wofür sie bei der Installation vom Server einen speziellen Schlüssel bekommt, welcher über die IMEI vom Server erstellt wird. Bei der Authentifizierung des Geräts schickt man IMEI und Schlüssel an den Server und der Server verbindet nur, wenn beides zusammenpasst. Sämtliche Kommunikation könnte man dann noch über eine sichere Verbindung erfolgen lassen.
Wer Zugriff auf das Gerät hat, hat nun natürlich auch Zugriff auf Schlüssel und IMEI und kann dies evtl. von einem anderen Gerät verwenden. Dazu könnte man aber in der App noch die Prüfsumme der App errechnen lassen und zu den Prüfdaten hinzufügen. Wenn man diesen Mechanismus ändern will, ändert sich auch die Prüfsumme der App. Nun müsste man schon sehr viel RSE-Arbeit leisten, um die App auf anderen Geräten lauffähig zu bekommen.
Auch wenn ich die Thematik nur oberflächlich kenne, so ist doch TPM gerade für sowas gebaut worden. Umsetzung, Verbreitung und Zugang dazu sind erstmal ganz andere Themen.
Aber prinzipiell sollte dies alles in diesem TPM ablaufen können.
Speziell der Absatz unter
Schutz kryptografischer Schlüssel
fasst doch eigentlich zusammen, dass so ein TPM eigentlich alles macht, was man braucht. Schlüssel erzeugen, verwalten und verwenden. Keine Zugriffsmöglichkeiten durch Software.
Das Thema TPM wollte ich auch gerade ansprechen. Vom Grundsatz her ist dies genau das, was man benötigt. So etwas ist auf Smartphones allerdings in der Regel nicht vorhanden (in vielen Laptops und auf Businessmainboards findet man häufig TPMs). ARM CPUs hingegen bieten eine TrustZone, der Zugriff darauf scheint allerdings herstellerspezifisch zu sein. Darüber hinaus seien die herstellerspezifischen Implementierungen wohl häufig fehlerhaft und brächten mehr Probleme mit sich, als sie lösen:
Eine Nutzung der IMEI halte ich persönlich für bedenklich aus Datenschutzsicht, weil sich die Geräte so eindeutig identifizieren lassen (auch nach Neuinstallation der App / Rücksetzen auf Werkseinstellungen etc.). Ebenso wie eine Verwendung des Hashes der App bringt dies ohnehin nur einen Schutz gegen die Portierung des Schlüssels auf ein anderes Gerät unter Verwendung der offiziellen App. Wenn die Logik hingegen nachprogrammiert wird, sind sowohl IMEI als auch Hash eine Konstante, die man dort hinterlegen kann.
Das würde ich gerne vermeiden. Ich hätte die App sehr gerne dezentral ohne Authentifizierung an einem zentralen Server. Account war im Kontext Blockchain Account, also ein Schlüsselpaar.
Der Hinweis mit dem TPM hat mich weiter ein wenig zum Googlen gebracht: Offensichtlich existiert bei Apple etwas in der Richtung, die Secure Enclave. Und sie ist auch noch einigermaßen gut dokumentiert:
Das hilft mir auf jeden Fall schon mal für iOS. Private Schlüssel können in der Enclave generiert werden (nicht importiert) und die Enclave nicht verlassen. Ich glaube damit kann man arbeiten
Eine Blockchain dient in der Regel ja dazu, dass es keine intransparente Instanz gibt, die die Sicherheit garantiert, sondern sie ist secure by design. Damit einher geht in der Regel, dass die verwendeten Algorithmen und APIs offengelegt sind. Reversingarbeit ist in dem Falle dann nicht notwendig.
Iphones lassen sich softwaretechnisch übrigens aus Datenschutzgründen nicht mehr eindeutig identifizieren. Die IMEI lässt sich auf Androidgeräten nur mit zusätzlichen Berechtigungen ermitteln. Alternativ kann man natürlich UUIDs verwenden, die im Kontext der App weltweit eindeutig sind.
Es gibt Fälle, in denen eine derartige Zuordnung notwendig und sinnvoll ist, hier sehe ich aber den Ansatz über durch das Betriebssystem bereitgestellte sichere Bereiche zu gehen als zielführender an.
Das ist korrekt, und gerade das möchte ich mir ja zu Nutze machen. Ich suche aber nach einem Weg zu „beweisen“, dass die Daten die in der Blockchain geschrieben wurden auf einem bestimmten Gerät erstellt wurden um zu vermeiden dass jemand sich einen bösartigen Client nachbaut. Deswegen würde ich die Daten gerne vorab signieren.
Kannst du noch etwas genauer ausführen, was in diesem Sinne ein “bösartiger” Client ist? Weshalb muss nachweisbar sein, von welchem Gerät ein Eintrag kommt? Für gewöhnlich ist entscheidender, welcher Nutzer einen Eintrag hinzugefügt hat.
Das Angriffsszenario “Nutzer hat Rootrechte” könnte man dann nämlich ausschließen.
Zum Schutz vor Malware ist die Verwendung von Hardwarekryptographie natürlich trotzdem sinnvoll.
Ich versuche es noch mal so: Es gibt eine App, die Daten generiert und mit einer Signatur sicherstellen soll, dass die Daten nur von der Software, also der App erzeugt wurden. Ein bösartiger Client könnte sich als die App ausgeben und selbst Daten erzeugen und signieren. Dabei hätte er aber Einfluss auf die Daten und könnte manipulierte Daten erzeugen.
Ich bin selbst noch nicht ganz sicher ob es einen Sinn ergibt das Problem so zu lösen. Es ist tatsächlich nicht wichtig, dass der User über die Zeit hinweg den selben Account nutzt, wenn er also das Handy wechselt und die App neu installiert, ist es okay einen neuen Account in der Chain für ihn anzulegen. Es soll nur niemand in der Lage sein, eigene Daten zu erstellen und zu signieren. Da z.B. Ethereum ja für alle zugreifbar ist und jeder Smart Contracts aufrufen kann, kann es auch gut sein dass eine permissionless Blockchain hier nicht funktioniert und wir auf etwas aus dem Hyperledger Toolstack zurückgreifen müssen. Das wäre dann aber schade, weil eine dezentrale Lösung einfach viel sauberer und vertrauenswürdiger wäre
Die Sicherheit in einer Blockchain basiert nicht darauf, dass die Daten signiert werden. Ich versuch mal knapp das Prinzip einer Blockchain zu erklären;
Alice und Bob wollen einen Vertrag abschließen, diesen signieren beide mit ihrem privaten Schlüssel und hängen ihren öffentlichen Schlüssel an diese Transaktion an. Dadurch kann das gesamte Netzwerk den Vertrag verifizieren.
Um jetzt nachträgliche Manipulationen zu verhindern kommt dieser Vertag in einen Block. Dieser Block wird jetzt von der Community signiert. Das passiert, dadurch, dass ein Hash berechnet wird, der gewisse Vorgaben erfüllt. Nehmen wir als Beispiel es soll ein Hash für die Zeichenkette “Hello World” + [nonce] berechnet werden, dessen letzten 10 Binärziffern 0 sind. Nonce ist eine numerische Variable, die es gilt zu bestimmen.
In jedem Block ist neben den einzelnen Transaktionen auch der Hash des Vorgängerblocks enthalten. Will man nun einen Block nachträglich manipulieren, müsste man seinen Hash und auch den der nachfolgenden Blöcke neu berechnen. Da sowas ziemlich rechenintensiv ist, ist es nahezu unmöglich Transaktionen im Nachhinein zu manipulieren.
Wie Blockchains funktionieren ist mir bestens bekannt, das wird auch nicht meine erste Applikation in der Art
Die Unveränderlichen Daten und die Möglichkeit mit untrusted Clients zu arbeiten möchte ich mir ja gerade zu nutzen machen. Darüber hinaus frage ich mich aber wie ich die Daten so konstruieren kann, dass ich auch „beweisen“ kann dass diese auf eine bestimmte Art und Weise erzeugt werden. Das Problem ist nicht Blockchainspezifisch, ich möchte die Blockchain lediglich nutzen um zu beweisen dass bestimmte Daten zu einem bestimmten Zeitpunkt existiert haben
Dieses Problem kann aber auch durch Hardwarekryptographie nicht gelöst werden. Sei es nun ein TPM, eine Secure Enclave, eine TrustZone oder was auch immer - hier wird nur sichergestellt, dass der private Schlüssel privat bleibt, indem nichtmal der Endanwender ihn zu Gesicht bekommt. Die Signatur wird dann in der Blackbox vorgenommen.
Das Verhalten der Software wird sich aber immer imitieren lassen. Ob die Originalsoftware nun eine Hardware zur Speicherung der Schlüssel verwendet oder nicht, ist dabei unerheblich, denn in einer nachprogrammierten oder gecrackten Software lässt sich dieser Bestandteil der Software austauschen.
Es ließe sich nicht einmal sicherstellen, dass die signierten Daten auch durch eine unverfälschte Version der App übermittelt wurden, wenn man weiß, dass der verwendete Schlüssel durch die Originalapp erstellt wurde. Denn die Originalapp lässt sich auf dem selben Gerät in „gecrackter“ Form ausführen, wodurch der Schlüssel verwendet werden kann.
Genau das ist absolut richtig. Selbst wenn wir davon ausgehen, dass niemand an den privaten Schlüssel kommt, es hindert niemanden daran sich einfach selbst ein Schlüsselpaar zu erstellen und so zu tun als ob er eine neu angemeldete App wäre. Hier kann man lediglich die Hürden hochlegen, aber nicht ausschließen dass es doch jemand tut…
