1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

RSACryptoServiceProvider mit eigenen Keys

Dieses Thema im Forum ".NET Datenverwaltung" wurde erstellt von JJB, 1. September 2016.

  1. JJB

    JJB Cogito ergo brumm

    Hallo

    Ich möchte einen RSACryptoServiceProvider samt Parametern zur Ver-/Entschlüsselung von Daten erzeugen.

    Doch ich muss die Daten auch morgen noch mit den selben Schlüsseln, ver-/entschlüsseln.
    Die Schlüssel in Dateien zu exportieren wäre eine nette Sache, doch ich darf/kann keine Dateien erzeugen.
    Also dachte ich, ich könnte meinen RSACryptoServiceProvider mit eigenen Keys und Parametern erzeugen dich ich aus dem System entnehme. So habe ich hier Daten wie processorID, Mac und anderes.

    Daher meine Frage.

    Kann ich eigene Strings nutzen, um einen RSACryptoServiceProvider zu parametrisieren und morgen die selben Schlüssel noch einmal erzeugen ?

    AFAIK, hat der RSACryptoServiceProvider Parameter wie p, d, n, etc. Doch habe ich auch irgendwo aufgeschnappt dass diese auf Primzahlen beschränkt sind.
    Kann mir jemand helfen ?

    Thanx
     
  2. sheel

    sheel I love Asm Administrator

    Hi

    Genau.
    Als Erstes braucht man zwei zufällige Primzahlen (oder zumindest, primzahltest-bestehende teilerfremde Zahlen) p und q, die auch nicht auseinander ableitbar sind (zB. die eine ist immer um x größer als die andere), stellenmäßig nicht zu unterschiedlich lang sind, und generall auch ziemlich lang sind (kurz = unsicher. In der Praxis werden Zahlen mit zB. 4096bit Länge (eben in Binärschreibweise) eingesetzt.)
    ...
    Sowas nicht in Dateien speichern zu dürfen geht einfach nicht. Man kann sich nicht einfach so 4096bit merken.

    a) Die nicht-veränderlichen Daten geben meistens keine 4096bit Entropie her => Geht nicht.
    b) Wirklich "nicht veränderlich" ist es ja nicht. Sollen alle verschlüsselten Daten verloren sein, wenn der Computer einmal kaputt ist?
    c) Warum dann überhaupt noch verschlüsseln, wenn jeder mit Zugriff auf den Computer alles hat?
     
  3. JJB

    JJB Cogito ergo brumm

    Jaaa, ich weiß. Da gibt es diese Diskussion, warum managed code wenn man verschlüsselt, warum .Net mit Crypto Themen, warum Daten auf einem Computer speichern wenn sie geheim sind. Aber lassen wir das mal beiseite.

    Mir gefällt das auch nicht, aber es gibt hier eben verschlüsselte Daten die immer wieder gelesen werden sollen. Natürlich auch immer wieder mit dem selben Schlüssel, heute wie morgen. Aber ich kann diesen eben nicht auf dem Rechner in Reintext in eine Datei legen, ich darf ihn auch nicht in der Registry oder sonst wo verbergen. Also kreiere ich ihn mir neu, jedes Mal wenn ich das Programm starte. Aber er muss eben der selbe sein wie gestern. Daher der Ansatz den Schlüssel zu parametrisieren mit Daten wie z.B. Hardware Werte. Ich kann auch irgendwelche andere Zahlen nehmen die auf dem System gleich bleiben. An sich egal, Hauptsache ich kann den Schlüssel nochmal erzeugen.
    Wenn etwas am Rechner kaputt geht sind die Daten eben futsch, egal. Das ist kein Drama.
    Aber im laufenden Betrieb sollen die Schlüssel eben funktionieren.
    Das ganze läuft unter "hinreichende" Sicherheit.
    Die verwalteten .Net dlls laufen durch eine Art Obfuskierung und sind damit eben auch nur hinreichend sicher.

    Mir ist klar dass alles was mit selbstgebauter Sicherheit zu tun, in der Regel nur dem Gewissen der IT dient und nicht dem Kampf gegen Al-Qaida Software Terroristen, die 5 Millionen investieren um Lieschen Müllers Tagebuch zu klauen.
     
  4. sheel

    sheel I love Asm Administrator

    Gern, weil es komplett am Thema vorbeigeht.
    Falls es dir entgangen ist, bisher hat niemand etwas von .NET, Obfuskatoren oder Ähnlichem gesagt.

    Was dir aber noch immer nicht klar zu sein scheint, dass dein Vorhaben nicht "nicht 100% sicher" ist, sondern exakt 0%. Weil man ganz genau nichts tun muss, um die Verschlüsselung zu umgehen. Keine DLLs zerlegen, kein gar nichts. Was sonst noch an Sicherheitsmaßnahmen da ist kann ja evt. gut sein, aber je nach Umsetzung macht dieser Teil die gesamte Kette sogar schwächer.
    ...

    Das klingt jetzt vermutlich arrogant, aber wer nicht selbst auf Wikipedia lesen kann, dass man für RSA Primzahlen braucht, bitte die "Hinreichend"-Einschätzung nicht selber machen.
     
  5. JJB

    JJB Cogito ergo brumm

    Okay, eine Rüge von einem Admin...
    Hm... also setz ich mich mal vor meinen Zeichenblock.

    Ich erzeuge einen privaten und einen öffentlichen RSA Schlüssel und gebe den öffentlichen frei, damit eine Gegenseite eine Datei erzeugt die ich mit meinem privaten lesen muss.
    Soweit dürfte das ja keinem Fehler unterliegen.
    Wie erzeuge ich meinen Schlüssel ? Ich erzeuge einen RSACryptoServiceProvider und exportiere einen Schlüssel.
    Das Problem ist, wenn ich das mache, erzeuge ich jedesmal einen anderen und kann die Datei nicht mehr lesen.
    Also muss ich den RSACryptoServiceProvider mit Parametern füttern um den Schlüssel immer wieder gleich zu erzeugen.
    Liegt hier der Wurm begraben ?
    Darf man mit einem RSACryptoServiceProvider nicht mehrfach die selbe verschlüsselte Datei öffnen ?
    Oder muss ich meinen Schlüssel aufbewahren ? Aber wo ? Ich kann nichts speichern ?
    Und wieso hat jeder mit Zugriff auf den Rechner "alles" ?
    Nur die DLL die den Schlüssel innehält bzw. erzeugt, hat alles. Der Content wird damit enschlüsselt und verarbeitet. Ja, aber nur durch das Programm oder habe ich was verdreht ?

    An sich suche ich nur nach ein paar Code Schnipseln, um mit dem RSACryptoServiceProvider einen Key zu erzeugen, einen den ich noch einmal erzeugen kann, wenn der Input gleich ist.
    Geht das prinzipiell nicht ?

    Was die Natur der Frage angeht. Ja, ich weiß von den Primzahlen. Genau genommen kenne ich die ganze Mathematik hinter dem Algorithmus und die Konzepte der Kryptologie. Das war ein Vertiefungsfach meines Studiums, aber ich lese das jetzt nicht alles in meinen 20 Jahre alten Aufschrieben nach. Und nur weil ich für den Algorithmus Primzahlen brauche, heißt das ja nicht, dass ich sie "brauche". Das ist DotNet ! Da sage ich GenerateSomething() und etwas wird erzeugt. Die IL, das Framework und die Abstraktionsebenen sind ein wundervolles Werkzeug uns die Details abzunehmen. Wenn das hinter den Kulissen gemacht wird, ist das schön, aber das heißt nicht dass ich zwingend die Details regeln muss.
    Entscheidend ist, welche Parameter ich hineinladen muss, um hinten etwas herauszukriegen. Und mit etwas Mühe kann man aus einem String eine Zahl erzeugen, vlt. Hash, Codierung, Transformation, was auch immer, die immer wieder die gleiche sein wird. Damit führt ein String zu einer Zahl und mit intelligenter Konfiguration die Zahl zu einem Schlüssel. Ich verschiebe meine Byte-Array Schlüsselfrage über einen Algorithmus in einen String, so zumindest die Hoffnung.

    Ich hoffe, dass ich hier keinem Beef eines Admins erliege, der "netiquette" in seinem Footer stehen hat.
    Sollte ich auf Kritik empfindlich reagiert haben, möchte ich mich in aller Form entschuldigen.
    Ich mag Foren in denen die Frage "Wie..." beantwortet wird mit
    Code (Text):
    1.  var = 'Etwa_so_oder_so;'
    und nicht mit "...wer nicht selbst auf Wikipedia...".
    Sollte das hier Verwirrung stiften tut es mir leid. Ich will da nichts philosophisch einreißen.

    Ich suche nur ein paar Zeilen Code.
     
  6. sheel

    sheel I love Asm Administrator

    Bitte mich themenmäßig einfach als normalen User betrachten, und keine Angst vor Sperren etc. haben nur weil man anderer Meinung ist. (Und ruhig auch mal zurück-kritisieren, wenn was nicht passt :))

    Da haben wir was gemeinsam... umso weniger versteh ich das ganze Problem.

    Alo nochmal langsam: Du willst etwas verschlüsseln, kannst aber aus irgendeinem Grund keinen Schlüssel irgendwo ablegen und willst ihn deshalb aus Daten wie processorID, Mac usw. erzeugen. Ok. Und ja, mit .NET aus diesen Daten lange Primzahlen generieren geht schon irgendwie.

    Problem 1: Ein Angreifer "mit" Zugriff auf den Computer, oder zumindest Wissen von der Hardware, kann die Generierung doch jederzeit nachmachen... . Mit Computerzugriff würde ein Start deines Programms reichen.

    Problem 2: Auch ohne Computerzugriff bleibt das Problem, dass Prozessor-ID usw. nicht sehr zufällig sind. Es gibt keine 2^4096 Prozessortypen. Und aus wenig zufälligen Daten kann auch .NET nur wenig zufällige Primzahlen erzeugen. Entropie von Nichts heraus erzeugen geht einfach nicht. Folge davon => Es gibt nur wenige Keys, die deine Generierung generieren kann, und man man sie sehr schnell alle durchprobieren lassen.

    (Ja, das ist nicht das Selbe wie "man muss nichts machen", aber knapp dran. Geht jedenfalls schneller als DLLs zu zerlegen).

    Um sichere Hoch-Entropie-Keys zu erzeugen sind eben Daten mit hoher Entropie nötig. Nur hast du dir mit deinen Rahmenbedingungen selber alle möglichen Quellen verbaut. (Externe Quellen => nichts dauerhaft speichern. Daten, die das OS aus Netzwerklatenzen usw.usw. sammelt => nie die Selben, deswegen auch speichern nötig. Hardware-Generator => Naja, hat man vermutlich nicht)
     
  7. JJB

    JJB Cogito ergo brumm

    Hm... nun gut.

    zu Problem 1:
    Wenn jemand mit Zugriff auf den Rechner zur Findung der relevanten Hardwareparameter und des Weges zur Parametrisierung des Providers, sowie des Inhalts der obfuskierten DLLs eine Arbeitszeit von mehr als 10 T€ verschwendet, ist die Lösung hinreichend sicher.
    Und das ist je nach Agentur oder Firma schnell erreicht. Meist ist das schon mit der Ausarbeitung des Pflichtenheftes aufgefressen.

    zu Problem 2:
    Ich benutze 1024er Keys, das sollte die (hoffentlich automatische) Erzeugung von Primzahlen etwas beschleunigen.

    Sollte ich irgendwie durchkriegen, dass ich den Schlüssel lokal speichern kann, habe ich das Problem, dass er gemeinsam mit der verschlüsselten Datei auf ein anders System kopiert wird. Und da liegt der eigentliche Fokus. Es ist nicht so das Thema, dass der Inhalt von einem Programm ausgewertet wird, sondern eher wo er ausgewertet wird und ob er verändert wurde. Warum das so ist will ich nicht weiter beleuchten.

    Ich brauche einfach ein paar Schnipsel Code.
    Vielleicht ist Serialisierung der schnellste Weg, wenn ich den Import nicht richtig füttern kann. Dann brauche ich aber immer noch zwei zu einander passende Primzahlen. Oder reicht eine ?
     
  8. sheel

    sheel I love Asm Administrator

    ...ich denke nicht, dass du die genannten Probleme wirklich verstanden hast.

    Problem 1 braucht keine 10T€ zum Angreifen, ein paar Minuten Zeit reichen. Und nach wie vor ist kein DLL-Zerlegen nötig.

    Problem 2 hat nichts mit der Erzeugungsgeschwindigkeit deiner Primzahlen zu tun.

    ...

    Serialsisierung von woher bzw. wohin? Ich dachte, man kann nichts speichern?

    Nein, eine Primzahl reicht für RSA nicht. Nichtmal zwei reichen, das oben war ja auch nur ein Teil der Beschreibung.

    ...

    Naja, ich bin mit dem Thread jetzt fertig. Warum das Vorhaben schlecht ist kann ich anscheinend nicht verständlich erklären; aber jedenfalls werd ich nicht dabei helfen sich sprichwörtlich selbst in den Fuß zu schießen (Code geben wäre genau das. Sorry.).
     
    Zuletzt bearbeitet: 5. September 2016
  9. JJB

    JJB Cogito ergo brumm

    Also ich habe gerade meinen Kopf 33,5 Mal gegen die Wand geschlagen nur um den Text zu verdauen.

    Du magst meinen Ansatz nicht.
    Du kannst/darfst/willst mir nicht erklären, was genau nicht stimmt. (Jemand/etwas kann das irgendwie knacken)
    Du willst mir keinen Code nennen, und deutest mir durch die Blume an, dass du es eigentlich könntest.
    Du hast 4 lange Posts gebraucht um mir das zu sagen.
    Du bist Admin in einem Forum für Entwickler die Hilfe suchen.

    Ich glaube, das erübrigt jetzt jede Wertung.
    Kann bitte mal jemand den Thread löschen !!!
     
  10. sheel

    sheel I love Asm Administrator

    ...Wenn du meine 4 Posts irgendwie gelesen hättest, hättest du dir Erklärung schon lang.

    Nein, kann ich nicht, weil es so einen Code nicht gibt
    Mac usw. zu Nummern wandeln ja, von mir aus sogar zu Primzahlen, aber NICHT zu Primzahlen die geeignet für einen sicheren RSA sind.

    Und ich wiederhol die letzten 4 Posts immer in verschiedenen Detailstufen, warum das so ist.

    Mac und Prozessorid sind kein CSPRNG (Punkt).

    ...
    Nein, Threads werden generell nicht grundlos gelöscht.
    Und "ich will nicht hören, dass es nicht geht" ist kein Grund.
     
    Zuletzt bearbeitet: 7. September 2016
Die Seite wird geladen...
Ähnliche Themen - RSACryptoServiceProvider eigenen Keys
  1. Polli
    Antworten:
    3
    Aufrufe:
    1.443