none
[Security/.NET] RSA Key Container und Asymmetrischer Verschlüsselung für Dateisicherheit RRS feed

  • Frage

  • Liebe Kolleginnen und Kollegen,

    wie der Titel es bereits sagt, würde ich gerne um ein wenig Hilfe beim Verständnis von asymmetrischer Verschlüsselung bitten. Im MSDN gibt es eine guten Übersicht und Anleitung für das Kryptografiemodell im .NET Framework. Dennoch ergeben sich mir einige Sicherheitsfragen.

    Situation

    Mein derzeitiges Projekt verlangt beide Nutzen der Asymmetrischen Algorithmen, sowohl das Signieren als auch das Verschlüsseln.

    Die Anwendung benötigt fest strukturierte Daten (Strukturdaten) aus einer Datei, die durch ein anderes, privates Programm erstellt werden. Hierfür muss es sicherstellen, dass die Daten nicht verändert worden sind. Die Daten werden also signiert.

    Die Anwendung arbeitet daneben mit einem eigenen Dateisystem. Die Dateien enthalten unter anderem sensible Daten (Dokumentdaten). Daher sollen diese Daten mithilfe eines vom Benutzer festzulegenden Passworts verschlüsselt auf der Festplatte gespeichert werden. Nur die Nutzer der Anwendung, die das Passwort eingeben, sollen die Daten in die Anwendung einlesen können.

    Mein Problem mit Key Container im Kryptografiemodell

    Das oben erwähnte Kryptografiemodell macht deutlich, dass asymmetrische, private Schlüssel nie wörtlich oder im Klartext auf der Festplatte oder in dem Code des Assembly gespeichert werden sollen. Dafür biete das .NET Framework sogenannte Key Container. Das Modell gibt auch Anleitungen her, wie Daten mithilfe von Key Container signiert/verifiziert und ver-/entschlüsselt werden können.

    Key Container haben es nun an sich, dass sie entweder benutzerkonten- oder rechnergebunden sind. Das heißt, unter dem gleichen Container Namen finden sich andere Schlüsselparameter, je nach Benutzerkonto oder Rechner.

    Nun genau das zerstört meinem Verständnis nach den Sinn dieser "sicheren Art und Weise", Schlüsselpaare zu speichern.

    Wenn ich so mit einem privaten/autorisiertem Rechner Daten signiere, dann kann kein anderer als eben jener Rechner auch die Daten verifizieren. Im oben genannten Beispiel könnte die Anwendung auf dem Rechner des Kunden die von mir bereitgestellten, signierten Strukturdaten nicht verifizieren.

    Wenn ich so mit einem Rechner Daten verschlüssele, dann kann auf keinem anderen als eben jenem Rechner die Daten entschlüsselt werden. Das zerstört die Idee, dass Jeder so Daten verschlüsseln können soll, die nur Einer lesen können soll. Es kann doch nicht ernsthaft verlangt werden, dass sich der Leser hierfür an den gleichen Rechner setzen muss.

    Das Kryptografiemodell leitet da fehl, wenn es bei "Überprüfen der digitalen Signaturen" und "Entschlüsseln von Daten" mit den Key Container arbeitet. Der private Schlüssel eines Key Container muss geheim bleiben und der öffentliche Schlüssel des Key Container exportiert und weitergegeben werden. Nur so kann eine Signatur erfolgreich geprüft und Daten erfolgreich verschlüsselt werden.

    Mein Problem in meiner Anwendung

    Wie erwähnt, meine Anwendung arbeitet mit signierten Strukturdaten und mit zu ver- und entschlüsselnden Dokumentdaten.

    Die Prüfung der Signatur kann ich noch fertigstellen. Anstatt das meine Anwendung den Key Container Namen nutzt, um die Signatur zu prüfen, erhält sie schlichtweg den öffentlichen Schlüssel, der zum privaten Schlüssel korrespondiert.

    Das Ver- und Entschlüsseln der Dokumentdaten macht mir aber auf zwei Weisen Probleme. Verschlüsselte Dokumentdaten können nur mit dem privaten Schlüssel entschlüsselt werden, aber:

    1. Der private Schlüssel kann der Anwendung nirgendwo zugänglich bereitgestellt werden. Das würde die Sicherheit zu Grunde richten.
    2. Der Key Container ist hier nicht nützlich, da sich der private Schlüssel ja je nach Rechner oder Benutzer ändert.

    Demzufolge eignet sich diese Verschlüsselung nicht, um Daten bis zur nächsten Nutzung durch die Anwendung sicher auf einer Festplatte zu speichern?

    Mein Ziel

    Ich möchte, dass meine Anwendung die Dokumentdaten mithilfe eines benutzerdefinierten Passworts verschlüsselt auf der Festplatte speichert und die Dokumentdaten wieder mithilfe des Passworts entschlüsseln kann,

    1. ohne ein Sicherheitsproblem zu kreieren und
    2. ohne benutzerkonten- oder rechnergebunden zu sein.

    Könnt ihr mir bitte dafür Denkanstöße, Ideen oder ähnliches aufzeigen? Eventuell sehe ich den Wald vor lauter Bäumen nicht.

    Vielen Dank für Rückmeldungen.



    Mittwoch, 26. September 2018 13:52

Antworten

  • Hallo,

    ich persönlich würde das anders lösen und 2 Verschlüsselungsverfahren nutzen. Die Daten der User würde ich mit AES 128 oder 256 bit verschlüsseln (nur Passwort nötig). Die Prüfung ob eine Datei verändert wurde, würde ich mit einer Hashsignatur realisieren.

    Ich persönlich finde das testen auf Veränderung der Daten unsinnig. Eine mit AES verschlüsselte Datei kann nur verändert werden wenn sie vorher entschlüsselt wird. Dieses kann auch nur die Person die das Passwort kennt. Verändert man die Datei z.B. auf Bit oder Byte ebene, ist die Datei zerstört und lässt sich nicht mehr entschlüsseln.

    Du solltest aber bedenken das beim vergessen des Passwortes die Daten verloren sind. Eine Bruce Force Attack auf eine Datei die mit AES verschlüsselt worden ist, könnte viele Jahre dauern.

    Demnach ist halt immer die Frage ob man eine "Hintertür" einbaut. Jede "Hintertür" schwächt das gesamte Sicherheitskonzept, kann aber vor Datenverlusts schützen. 

    Ich persönlich würde den User entscheiden lassen wie er seine Daten verschlüsseln will und ihm damit mehrere Verfahren mit Erklärung und möglichen Risiken anbieten.

    Eins sollte man immer bei sowas bedenken. Ein Sicherheitskonzept muss den Wert der Daten entsprechen. Wenn ich z.B. persönliche Daten von 10 Usern in einer Datei verschlüssele und die Entschlüsselung mit analyse meines Sicherheitskonzeptes 1 Monat dauern würde, würde sich kein Angreifer die mühe machen. Habe ich in dieser Datei 100 Millionen Datensätze, sieht das ganze schon anders aus.

    Ein Sicherheitskonzept sollte immer mit den betroffenen ausgearbeitet werden und nicht über deren Kopf hing weg entschieden werden. Auch muss es nicht immer ein auf ein Geheimnis (Passwort) basierendes Sicherheitskonzept sein. In einer Frima/Netzwerk oder Domain, kann man auch mit Rechten arbeiten die durch einem Admin geschützt werden. Auch das Speichern in der Cloud (DropBox, OneDrive...) könnte ein Konzept sein. 


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings


    Mittwoch, 26. September 2018 22:14

Alle Antworten

  • Hallo,

    ich persönlich würde das anders lösen und 2 Verschlüsselungsverfahren nutzen. Die Daten der User würde ich mit AES 128 oder 256 bit verschlüsseln (nur Passwort nötig). Die Prüfung ob eine Datei verändert wurde, würde ich mit einer Hashsignatur realisieren.

    Ich persönlich finde das testen auf Veränderung der Daten unsinnig. Eine mit AES verschlüsselte Datei kann nur verändert werden wenn sie vorher entschlüsselt wird. Dieses kann auch nur die Person die das Passwort kennt. Verändert man die Datei z.B. auf Bit oder Byte ebene, ist die Datei zerstört und lässt sich nicht mehr entschlüsseln.

    Du solltest aber bedenken das beim vergessen des Passwortes die Daten verloren sind. Eine Bruce Force Attack auf eine Datei die mit AES verschlüsselt worden ist, könnte viele Jahre dauern.

    Demnach ist halt immer die Frage ob man eine "Hintertür" einbaut. Jede "Hintertür" schwächt das gesamte Sicherheitskonzept, kann aber vor Datenverlusts schützen. 

    Ich persönlich würde den User entscheiden lassen wie er seine Daten verschlüsseln will und ihm damit mehrere Verfahren mit Erklärung und möglichen Risiken anbieten.

    Eins sollte man immer bei sowas bedenken. Ein Sicherheitskonzept muss den Wert der Daten entsprechen. Wenn ich z.B. persönliche Daten von 10 Usern in einer Datei verschlüssele und die Entschlüsselung mit analyse meines Sicherheitskonzeptes 1 Monat dauern würde, würde sich kein Angreifer die mühe machen. Habe ich in dieser Datei 100 Millionen Datensätze, sieht das ganze schon anders aus.

    Ein Sicherheitskonzept sollte immer mit den betroffenen ausgearbeitet werden und nicht über deren Kopf hing weg entschieden werden. Auch muss es nicht immer ein auf ein Geheimnis (Passwort) basierendes Sicherheitskonzept sein. In einer Frima/Netzwerk oder Domain, kann man auch mit Rechten arbeiten die durch einem Admin geschützt werden. Auch das Speichern in der Cloud (DropBox, OneDrive...) könnte ein Konzept sein. 


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings


    Mittwoch, 26. September 2018 22:14
  • Hallo Thomas,

    so wie ich das nachvollziehe, benötigt ein asymmetrischer Algorithmus immer zwei unterschiedliche Parteien, sonst kann der private Schlüssel nicht geheim bleiben. Demzufolge eignet er sich nicht, um Daten unär-parteilich geheim zu sichern, sondern nur geheim zu transportieren. Ich würde danach wirklich dazu übergehen, die Dokumentdaten mittels benutzerdefinierten Passworts und AES zu verschlüsseln. Das sollte genügen. Danke für den Vorschlag.

    Die von mir erwähnten Strukturdaten, die ich ja signieren möchte, sind dabei eigenständige Daten. Sie sind nicht Teil der Dokumentdaten und werden somit nicht mit ihnen verschlüsselt. Daher ist es schon richtig, sie auf Veränderungen zu prüfen.

    Mit dem Thema Hashsignatur muss ich mich dann auseinandersetzen, es hört sich nach kurzem Einlesen interessant an. Dabei scheint es mir aber kaum unterschiedlich zu einer direkten Signatur, nur dass ich die Daten vorher "komprimiere". Trotzdem auch für diesen Anstoß ein Danke. 

    Über Eignung und Maß von Sicherheitskonzepten zum Datenwert lässt sich sicherlich gut diskutieren. Ich sehe zwar, wie die Menge der Daten ein entscheidender Faktor sein kann. Doch selbst einige wenige wertvolle Daten können sich lohnen. Es ist immer ein Zusammenspiel von Quantität und Qualität. Außerdem ist eine Verschlüsselung von Daten selbst in einem internen Unternehmensnetzwerk ein guter Auffang, sollten sie wider der Vorkehrungen doch nach außen dringen.

    Wie gesagt, ich lese mich da noch schlauer. Auf jeden Fall Danke, dass Du mich in die richtige Bahn gelenkt hast.

    Gruß Martin


    Wupp Wupp! Fnak Fnak!

    Donnerstag, 27. September 2018 14:07