Zukunftsverschlüsselung?

  • Hallo in die Runde,


    ich habe schon etwas länger eine Idee für ein Projekt.

    Grob gesagt sollen "Geheimnisse" gespeichert werden und zu einem späteren Zeitpunkt anonym veröffentlich werden. In dieser Zeit von Eingabe des Geheimnisses bis zur Veröffentlichung kann die Person über das aufrufen eines Links das Geheimnis löschen, sodass es nicht veröffentlicht wird. Alternativ periodisch einen Link aufrufen, damit das Geheimnis nicht veröffentlicht wird ("Totmannschalter"-mäßig)


    Da die Geheimnisse potentiell dazu geeignet sind Personen in Bedrängnis zu bringen möchte ich zum einen selber gar nicht wissen wer meine Seite benutzt. Das denke ich würde ich über irgendwelchen wilden Reverse-Proxy-non-logging-Dingsbums ganz gut hinbekommen.


    Mehr Gedanken mache ich mir derzeit wie ich verhindern kann, dass bei einem Hack die unveröffentlichten Geheimnisse gelesen werden können oder weniger drastisch Administratoren diese lesen können. Ich suche nach einer Art "Zukunftsverschlüsselung". Ein bestimmtes verschlüsseltes Geheimnis kann erst NACH einem bestimmten Datum entschlüsselt werden. Wie das mathematisch klappen soll, weiß ich nicht (deshalb gibt es sowas wahrscheinlich auch nicht :D) aber ich dachte ich frag mal in die Runde, ob jemand eine Idee hat.

  • Smart Contracts in Blockchains ermöglichen dir, dass du auf einen Geldbetrag erst nach einem Jahr Zugriff erhälst.

    Bsp.: Etherium, Byteball

    Hab ich auch schon drüber nachgedacht. Ich würde z.B. das Geheimnis symmetrisch verschlüsseln und den Schlüssel in einen smart-contract packen. So ist das secret selbst nicht in der Blockchain und wenn der Contract zerstört wird, kann der Text nicht mehr entschlüsselt werden. Vielleicht sollte ich das weiter verfolgen. Danke für deinen Input

  • nur Gedanken, vielleicht klappt das;

    generiere zum Verschlüsseln ein Zertifikat das jetzt gültig ist, und zum Entschlüsseln eines, das erst in der Zukunft gültig ist;

    und nachdem Du es verschlüsselt hast, lösch das eine jetzt gültige Zertifikat;


    irgendwie ist das sowas wie eine Zeitbombe; sprich Du brauchst mehr als 1 Kritierium um zu erkennen,

    daß tatsächlich bereits dieses Datum aktuell ist; und daß es aus dem System läuft, und genau dann:

    if ( file exists );

    do nothing;

    else

    create file;


    und das im Zusammenhang mit dem bereits erwähnten Zertifikat als binary in Form einer Black Box

    (closed source)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Die Gültigkeit eines Zertifikates ist lediglich eine ASN.1 kodierte Zertifikatseigentschaft, die aus kryptographischer Sicht völlig unerheblich ist. Und selbst wenn die genutzte Software dieses Kriterium prüft, so muss zur Umgehung lediglich das Systemdatum angepasst werden.


    Dass bei so einer fancy-Aufgabenstellung natürlich irgend jemand sofort reflexartig mit Blockchain antwortet war vorherzusehen :) Ich würde es dennoch mit etwas klassischem versuchen.


    Eine fertige Lösung habe ich ad-hoc auch nicht, aber versuchen wir mal ein paar Puzzlesteine zu definieren, aus denen man etwas "bauen" kann.


    1. asymmetrische Kryptographie

    • Vertraulichkeit: Der zukünftige Empfänger der Nachricht soll sich ein Schlüsselpaar generieren und Dir den Public-Key zukommen lassen. Du verschlüsselst das Geheimnis mit seinem Public-Key und vernichtest den Klartext. Du hast nun ein Chiffrat, das du selbst nicht mehr entschlüsseln kannst, und die einzige Person die das (irgendwann einmal) kann ist der Inhaber des Private-Keys.
    • Integrität: Damit der Empfänger sich sicher sein kann, dass die Nachricht die er irgendwann einmal erhalten wird wirklich von dir stammt, willst Du diese signieren. Du erstellst Dir also auch selbst ein Schlüsselpaar und lässt dem zukünftigen Empfänger Deinen Public-Key zukommen. Mit dem Private-Key signierst du das Chiffrat. Ob Du Klartext oder Chiffrat signierst ist Geschmacksache, es gibt Vor- und Nachteile beider Varianten. Das Chiffrat zu signieren ermöglicht auch ohne den Private-Key des Empfängers zu besitzen eine Integritätsprüfung.
    • Tools hierfür z.B. "openssl smime" oder gpg


    2. ein Server mit Versand-Script und Totmann-Schaltung

    Du hinterlegst das signierte Chiffrat auf einem Server. Der Server prüft per Cronjob z.B. täglich, ob Du dich gemeldet hast. Wenn Du dich mehr als 6 Tage lang bei ihm nicht gemeldet hast, dann versendet er das Chiffrat an $DefinierterEmpfänger.


    Schutzbedarf des Servers:

    • Vertraulichkeit: Das Chiffrat betrachten wir als sicher, entschlüsselt kann es nur vom Inhaber des PrivateKeys werden. Der einzige Hacker der also etwas damit anfangen könnte diesen Server zu knacken um an das Chiffrat zu kommen, ist der PrivateKey-Inhaber selbst. Du musst also den Server so absichern, dass er ein ausreichendes Schutzniveau gegenüber dem PrivateKey-Inhaber bietet, schließlich soll dieser nicht zu früh an seine Nachricht gelangen können.
    • Integrität und Verfügbarkeit: Dritte denen etwas daran liegt zu verhindern, dass (wenn Dir etwas zustößt) die Nachricht an den Empfänger versandt wird, könnten deinen Server dahingehend kompromittieren wollen, dass er eine gefälschte Nachricht an den Empfänger sendet oder der Versand überhaupt ausbleibt.
      • Verfügbarkeit: nicht nur einen sondern mehrere Server verwenden, diese nach außen hin möglichst unsichtbar machen und Angriffsfläche reduzieren. Klassische System-Härtung und Redundanz.
      • Integrität: Damit nicht jemand eine gefälschte Nachricht versenden kann haben wir mit dem Empfänger vereinbart, dass dieser die Signatur prüfen wird und den Public-Key hierfür von Dir persönlich erhalten hat. Solange also nicht jemand mittels SocialEngineering den Empfänger überredet eine gefälschte Nachricht als Deine anzuerkennen sollte die Integrität gewahrt sein.


    Aus meiner Sicht wars das auch. Klingt nicht nach "Zukunftsverschlüsselung", sondern ist klassische Ende-zu-Ende Mail-Security, bei der die Mail aber am "Totmann-Schaltungs-Server" für x Wochen/Monate/Jahre zurückgehalten wird.

  • Hallo gunnarh ,


    danke für deine Ideen. Genau was du zu den Zertifikaten meintest, hatte ich auch im Sinn: Keiner zwingt mich (kryptografisch) mich an das Ablaufdatum zu halten. Ich kann analog z.B. auch an bereits abgelaufene PGP-Schlüssel Text senden, obwohl der Schlüssel als ungültig markiert ist.


    GPG kam mir auch in den Sinn, aber das "Problem" ist, dass der zukünftige Empfänger die Öffentlichkeit wäre, also die geheimen Texte veröffentlicht werden. Sprich: Das System selbst ist gewissermaßen der Empfänger und ich möchte verhindern, dass es da früher / zwischendurch ran kann bis sich der Autor wirklich dazu entschieden hat den Text wirklich zu veröffentlichen.


    Dafür war ich schon relativ früh zum Entschluss gekommen, dass ich eine vertrauenswürdige Drittpartei brauche. Es gibt ja Timestamp-Authorities, aber damit läge die Prüfung "Darf das schon entschlüsselt werden?" wieder in der Applikationslogik, was es ja ähnlich wie bei Ablaufdaten von Zertifikaten oder Schlüsseln zu verhindert gilt. Ich wollte diese Prüfung aber schon technisch abgedeckt sehen. Der Hinweis auf Smart-Contracts muss ich sagen, gefällt mir derzeit am meisten. Und es ist tatsächlich mal ein Use-Case für Blockchain ohne, dass man unbedingt das Buzz-Word unterbringen muss :D


    Idee ist derzeit wie folgt:

    1. Nutzer gibt (zu schützenden) Text T ein.
    2. T wird symmetrisch mit Schlüssel SYMS verschlüsselt (Schlüssel ist für jeden Text einzigartig), es entsteht SYMS(T)
    3. SYMS(T) wird in der Anwendungsdatenbank gespeichert
    4. SYMS wird asymmetrisch mit (Public-)Schlüssel ASYMS_PUB verschlüsselt (Systemweit gleich). Es entsteht ASYM(SYMS)
    5. ASYM(SYMS) wird in einem Smart-Contract in einem Dictionary unter (s)einem Hash H gespeichert (dient als Identifier). Key-value-artig (mit key = H und value = {"secret" => ASYM(SYMS), "notBefore" => "2019-01-01"})
    6. SYMS wird vernichtet. Ab jetzt ist SYMS(T) von der Anwendung nicht mehr entschlüsselbar.
    7. Smart-Contract stellt zwei "Methoden" zur Verfügung (bin mit den Termini nicht so vertraut): deleteSecret, getSecret (nebst createSecret)
      • getSecret liefert zu H das secret nur aus, falls die aktuelle Zeit nach notBefore liegt
      • deleteSecret löscht den Eintrag aus dem Dictionary
    8. H wird in der Anwendungsdatenbank mit SYMS(T) verknüpft gespeichert
    9. Der Nutzer bekommt H mitgeteilt mit dessen Hilfe er die Veröffentlichung stoppen kann (die Anwendung ruft dann deleteSecret mit H auf, wodurch die einzige Version von SYMS verloren geht)
    10. Die Anwendung selbst (oder von mir aus auch das im Smart-Contract) trackt wann SYMS(T) theoretisch veröffentlicht werden soll und versucht an dem Tag (oder danach) ASYM(SYMS) aus dem Smart-Contract abzurufen. Wurde dies nicht durch den Nutzer gelöscht, erhält die Anwendung ASYM(SYMS)
    11. Die Anwendung kann nun mithilfe von (Private-)ASYMS den Originalschlüssel SYMS wieder herstellen und
    12. damit SYMS(T) entschlüsseln
    13. T wird veröffentlicht


    Zu schützende Geheimnisse sind:

    • ASYMS
    • Adresse / Private-Key für Etherium-Adresse, die berechtiggt ist mit dem Contract zu interagieren

    Selbst falls diese Geheimnisse beide in die gleichen Hände geraten, kann der Text T erst am Tag lt. Smart-Contract wieder hergestellt werden (außer derjenige hat auch 50%+1 Macht in der Etherium-Blockchain :D ). Fehlt eines der beiden Geheimnisse ist T nicht wieder herstellbar.


    Ich kann ja mal in der Idee etwas konkreter werden. In meinem Umfeld habe ich in der Vergangenheit hier und da aus erster und zweiter Hand mitbekommen, dass in öffentlichen Einrichtungen jeglicher Art hier und da mal etwas - sagen wir - nicht ganz korrekt abläuft. Da wird der ausschreibungspflichtige Auftrag mal an Cousin A vergeben und mit Tricks die Ausschreibungspflicht umgangen, dort "leiht" sich der Direktor einer Schule für's Wochenende mal den großen Schulprojektor zum Fußballgucken aus oder die Küchenhilfen in der Gerichtskantine kaufen immer 2 mal so viel ein, um das "übrig gebliebene" Material privat zu nutzen. Also alles so mehr oder minder "schlimme" Sachen.


    Ich fand nun die Idee ganz "lustig", dass es eine "Anlaufstelle" (=Webseite) für Angestellte / Beteiligte gibt, wo sie sich das von der Seele schreiben können und mit größerer Zeitverzögerung veröffentlicht werden. (Ja, keiner weiß, ob die dortig gespeicherten Geschichten echt sind).

  • Hay,


    Dass bei so einer fancy-Aufgabenstellung natürlich irgend jemand sofort reflexartig mit Blockchain antwortet war vorherzusehen

    ich bin durchaus ein Blockchain-Kritiker (v.a. die sogenannten "Währungen"), aber hier habe ich auch zuerst an Blockchain gedacht, weil es ein System ist, in dem niemand vertrauenswürdig ist, aber alle in der Gesamtheit schon, deswegen funktionieren Smart-Contracts tatsächlich: Niemand traut niemanden, aber da alle die gleiche Information haben, kann sie nur richtig sein (man verzeihe mir meine laienhafte Äußerung - aber so habe ich es verstanden).


    Eine klassischere Lösung würde ich persönlich aber auch bevorzugen, da stößt man aber an die Grenzen, dass man mindestens einem Part in dem ganzen Konstrukt vertrauen muss... ich persönlich habe damit kein Problem, aber warum nicht eine Lösung, die schon von Vorne herein den zero-knowledge-proof beherrscht?


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Der Knackpunkt in Variante von Post #6 ist die sichere Verwahrung von "(Private-)ASYMS". Und dieses Verwahrungs-Problem löst auch die Blockchain oder Smart-Contracts nicht.

    Das ist auch nicht das Problem, das es zu lösen galt. Das Problem, dass es zu lösen galt war, dass es nicht möglich ist vor einem bestimmten Datum an den zu schützenden Text T zu kommen.


    Ich habe ja erwähnt, dass man in dem Fall zwei (private) Geheimnisse schützen muss.


    Allerdings ist das sichere Verwahren der (privaten) Geheimnisse kein exklusives Problem meiner Lösung, sondern existiert bei groben Durchdenken meiner Meinung nach in jedem Lösungsansatz.


    Der wichtige Punkt ist ja: Selbst wenn jemand an ASYMS kommt, kann er damit nicht an einen beliebigen Text T kommen. Dazu braucht er zusätzlich Zugriff auf den privaten Schlüssel der Blockchain-Adresse und Geduld. Und in dieser Wartezeit ist es für mich sogar noch möglich alle Secrets aus dem Smart-Contract zu entfernen (weil ich z.B. ein Offline-Backup vom Schlüssel der Blockchain-Adresse habe)

  • Zu einem Teil kann ich dir eine Lösung präsentieren:
    Shamirs Secret Sharing. Hashicorps Vault hat das implementiert.

    Grob gesagt generiert man eine Funktion x-ten Grades (eigentlich ein Polynom), auf dieser werden gerade so viele Punkte bestimmt (irgendwas um x+-1), dass sich daraus die Funktionsgleichung rekonstruieren lässt. Die Punkte werden an verschiedene Parteien verteilt, also das System (hat es im RAM) und der der etwas sichern möchte.

    So kann nur gemeinsam entschlüsselt werden und du hast nichts, was von dir ohne Gegenseite veröffentlicht werden kann.

    Zeitlich kann man das vermutlich nur steuern in dem man eine Hardwarekompenente mit Uhr hat, die sich bei Manipulation zerstört. Zusammen mit einem sicher gespeicherten Geheimnis (Yubikey oder so) und der Zeit als Hash entsteht das Passwort, was die Verschlüsselung löst. Ob es solche Hardware gibt kann ich mir zwar vorstellen, aber nicht dass die erschwinglich ist.