Wie kann ein Ein-Personen-Betrieb eine Sammlung von Online-Geldbörsen sicher halten?

Meine Lösung in Open-Transactions besteht darin, einen Abstimmungspool zwischen teilnehmenden Transaktionsservern zu erstellen. (Mir ist aufgefallen, dass Leute hier über das Projekt diskutiert haben, also wollte ich sicherstellen, dass es nur vorgeschlagen wurde – ich habe es noch nicht programmiert.)

Wenn Alice in einen OT-Server einsteigt, sendet sie ihre BTC nicht direkt an den Server, sondern an den Abstimmungspool.

===> Mein Vorschlag war, wann immer sie wieder aussteigen will, sendet sie eine signierte Anfrage an den Server und leitet dann die signierte Antwort des Servers an die Mitglieder des Pools weiter. WENN die Poolmitglieder eine Aufzeichnung/Prüfung von Alices Konto haben (das sich in einem von ihnen gemeinsam genutzten DHT befinden muss) und WENN die beiden Signaturen beide auf der Quittung bestätigt werden und WENN die Anfrage innerhalb der Zuweisung für diesen Server und seiner maximalen Bailout-Pro liegt -Tag, dann stimmen die Pool-Mitglieder ON THE BLOCKCHAIN ​​ab, um die Gelder an Alice zurückzugeben.

===> Dies kann auch zeitverzögert sein, wie ein 24-Stunden-Bailout, falls erforderlich, und es ist auch davon abhängig, dass alle Pool-Mitglieder Zugriff auf Audit-Daten der anderen Pool-Mitglieder haben. (Die anderen Transaktionsserver.)

===> Für den Fall, dass ein Server GEHACKT wird, kann er immer noch keine von Alices Bitcoins bewegen, da die anderen Pool-Mitglieder ohne Alices Unterschrift nicht dafür stimmen werden.

===> Für den Fall, dass der Server ein Dummy-Konto (versteckt vor der DHT) verwendet, um die interne Währung aufzublähen, werden die anderen Pool-Mitglieder nicht für solche Kautionen stimmen, weil es nicht über die Echtzeit hinauskommen kann oder tägliche Prüfung.

===> Für den Fall, dass ein Server sich weigert, Alices Bailout-Anfrage zu beantworten, kann sie sie an die Pool-Mitglieder senden, was eine Nachricht an den säumigen Server auslöst. Wenn es nach einer Zeitüberschreitung keine Antwort gibt, können sie mit 9 von 10 (oder was auch immer) abstimmen, um die Gelder freizugeben. Dadurch ist es möglich, Gelder auch von Servern zurückzuerhalten, die vollständig verschwunden sind.

Ich arbeite in meiner Freizeit an OT, daher wird es leicht ein paar Monate dauern, bis das obige Protokoll tatsächlich einsatzbereit ist. Aber das ist der grundlegende Plan.

Dies ist ein großartiges Ziel, von dem viele Menschen annehmen werden, dass es einfach nicht erreicht werden kann. Aber auf dem Gebiet des sicheren Cloud-Computing durch homomorphe Verschlüsselung werden bemerkenswerte Fortschritte gemacht.

Diese Schemata ermöglichen es Servern in der Cloud, Rechenaufgaben (derzeit nur eine begrenzte Menge an Arithmetik) mit verschlüsselten Werten auszuführen, ohne sie zu entschlüsseln. Weitere Informationen finden Sie unter Welche Vorteile bietet die vollständige oder teilweise homomorphe Verschlüsselung für die Cloud? - IT-Sicherheit - Stapelaustausch

Eine Frage zur Anwendung auf Bitcoin-Clients auf Less Wrong ist hier: Homomorphe Verschlüsselung und Bitcoin , aber sie scheinen die homomorphe Verschlüsselung mit einer Form der geheimen Aufteilung zwischen zwei Computern zu verwechseln, was das hier skizzierte Ziel nicht erfüllen würde.

Ich vermute, dass die aktuellen homomorphen Techniken für Bitcoin unzureichend oder zu langsam oder beides sind, aber ich bin mir nicht sicher. Aber weitere Forschung könnte es praktisch machen.

Eine Technologie, die eine Antwort liefern könnte, liegt in föderierten Servern, die durch die offenen Transaktionsbibliotheken von Mitreisenden ermöglicht werden . Dies ist die gleiche M von N-Unterschrift, von der David Perry in seiner Antwort spricht.

Als kleiner E-Wallet-Anbieter würden Sie sich mit einigen Kollegen zu einem Netzwerk von Wallet-Betreibern zusammenschließen.

Mithilfe der Skriptfunktionen von Bitcoin kann Benutzerin Alice eine spezielle Transaktion erstellen und an die Blockchain senden. Diese Transaktion ist im Grunde ein Schuldschein – sie hat ein Ablaufdatum und einige Anweisungen. Wenn die Anweisungen vor Ablauf der Transaktion erfüllt werden, findet die Transaktion statt und das Bitcoin-Netzwerk stimmt der Überweisung des Geldes zu.

Alice kann mehrere Parteien (z. B. Sie und Ihre Kollegen) als Vollstrecker des Schuldscheins festlegen. Ihr Skript kann sagen: „Ich benötige 9 von diesen 10 Wallet-Servern, um diese Transaktion zu signieren.“

Diese Sammlung von Verbundservern muss also einen Konsens erzielen, damit die Transaktion durchgeführt werden kann. Wenn einer, zwei oder acht der zehn Server gehackt werden oder die Betreiber gezwungen sind, die ihnen anvertrauten Schlüssel preiszugeben, kann der Angreifer Alices Bitcoins nicht ausgeben, weil er keinen Konsens hat.

Ich ermutige alle Interessierten, sich das Github-Repo anzusehen und einen Beitrag zu leisten. Mitreisender hat all diese Arbeit bisher alleine erledigt und braucht Hilfe.

Es hängt alles von Ihrer Definition ab, was eine Online-Wallet ist.

Sie können einen Online-Wallet-Service einrichten, bei dem die Serverseite nur Ihre öffentlichen Schlüssel kennt und all die schwere Arbeit leistet, die erforderlich ist, um die Blockchain zu verfolgen, einschließlich der Buchhaltung, die erforderlich ist, um festzustellen, welche Transaktionen zu Ihrer Wallet gehören. Die Client-Seite ist die einzige Entität, die Ihre privaten Schlüssel hat, und die einzige, die Coins ausgeben kann. Wenn sich die Serverseite in Luft auflöst, können Sie Ihre privaten Schlüssel jederzeit zu einem anderen Anbieter bringen oder in einen klassischen Client importieren. Diese Art von Online-Wallet erfordert, dass Sie eine kleine clientseitige Software ausführen, z. B. ein Smartphone.

Die BCCAPI ist ein Beispiel für einen solchen Dienst.

Obwohl sicherlich nicht so weit fortgeschritten wie nealmcbs Beschreibung der homomorphen Verschlüsselung, könnte eine Lösung, die ein angemessenes Maß an Sicherheit gegen "Gummischlauchzugriff" bietet, über eine Kombination aus Cold Storage , M of N-Signatur und plausiblen Deniability - Passwörtern aufgebaut werden.

Grundsätzlich bewahren Sie die meisten Ihrer Bitcoins in einer oder mehreren Offline-Wallets auf, die in einem physischen Format an einem sicheren Ort aufbewahrt werden. Um diese Coins/Wallets zu kompromittieren, müssten Sie gezwungen werden, physisch zu diesem Ort zu reisen, was viel riskanter ist für den Dieb, als einfach ein Passwort aus Ihnen herauszuprügeln. Zweitens, wenn es drei „Unterzeichner“ auf dem Hauptkonto gibt und zwei von ihnen eine Überweisung vornehmen müssen, ist es doppelt so schwer, die Passwörter von mindestens zwei von ihnen zu schlagen, als die Passwörter von nur einem zu schlagen, besonders wenn sie geographisch weit entfernt sind. Schließlich wäre es für viele bestehende Sites eine einfache Angelegenheit, Benutzername/Passwort-Kombinationen zu ihrer eindeutigen Einschränkung zu machen, anstatt nur den Benutzernamen. Dies würde es Benutzern effektiv ermöglichen, einen oder mehrere "Dummys" zu erstellen. Konten, die kompromittiert werden könnten, ohne ihr gesamtes Guthaben zu gefährden. Da sie alle denselben Benutzernamen haben, wäre es schwierig zu beweisen, wie viele Konten jemand hatte, ohne die Website selbst vollständig zu kompromittieren, wodurch zumindest ein gewisses Maß an plausibler Leugnung gegeben wäre.

Ich wünschte, ich könnte Ihnen eine hilfreichere Antwort geben, aber die Wahrheit ist, dass dies ein sehr schwieriges Problem ist. Ein Teil der Lösung besteht darin, Ihre Bitcoins in einen „Arbeitsstash“ und eine „Speichereinheit“ zu trennen. Bitcoins im Working Stash sind leicht zugänglich und können vollautomatisch manipuliert werden. Bitcoins in der Speichereinheit erfordern einen manuellen Eingriff, um freigegeben zu werden. Sie halten den Arbeitsspeicher so klein wie möglich, um das Risiko einer Kompromittierung zu verringern.

Wenn Sie eine sehr große Anzahl von Bitcoins haben, benötigen Sie möglicherweise mehrere Speicherebenen mit unterschiedlichen Sicherheits-/Unannehmlichkeiten. Das Ziel ist es, möglichst viele Bitcoins so fest wie möglich einzusperren, da man sie nur sehr selten benötigt.

Idealerweise sollte die ultimative „Speichereinheit“ offline sein. Wenn Sie Bitcoins aus dem Tresor holen müssen, erstellen Sie eine Transaktion, um diese Anzahl von Bitcoins aus dem Tresor zu nehmen und sie in den Arbeitsspeicher zu übertragen, wodurch das Wechselgeld an den Tresor zurückgegeben wird. Sie führen diese Transaktion dann zur Speichermaschine, die sie signiert. Sie führen die signierte Transaktion dann zurück zum Online-Rechner, der sie an das Netzwerk übergibt.

Die Idee ist, dass der einzige Zweck der Offline-Speichermaschine darin besteht, Transaktionen zu signieren. Alles andere erledigen andere Maschinen. (Stellen Sie sicher, dass der Betrag und die Ziele angezeigt werden, bevor Sie zur Unterschrift aufgefordert werden!)

Dies stellt nur das Problem dar, wie Sie die Offline-Storage-Signaturmaschine sichern und was Sie tun, wenn sie kaputt geht. Das letztere Problem ist das einfachere – Sie können eine Papierkopie des Hauptverschlüsselungsschlüssels in einem Tresor einschließen.

Im Allgemeinen wird dies in der Privatwirtschaft nicht getan. Sie vertrauen darauf, dass diese Branchen es richtig machen, aber normalerweise tun sie es nicht. Sicherheit ist schwierig, wirklich schwierig. Das Sichern gegen sich selbst (Rändelschrauben- und Gummischlauchzugang: p), wenn Sie direkten Zugriff auf die Hardware haben, macht es noch schwieriger.

Sie können den Client ein Passwort verwenden lassen, das nicht gespeichert ist, aber als Verschlüsselungsschlüssel zum Sichern seiner Brieftasche verwendet wird, und nur er, der diesen Schlüssel bereitstellt, würde es entsperren. Natürlich könnten Sie diesen Schlüssel jederzeit abfangen, außerdem haben Sie Zugriff auf die verschlüsselten Daten und den verwendeten Algorithmus.

Ehrlich gesagt würde ich öffentlichen Wallets nicht trauen.

Die Antwort ist die clientseitige Verschlüsselung .

Im Grunde funktioniert es ungefähr so.

1. Sie registrieren sich beim E-Wallet-Service.
2. KUNDE - Sie erstellen dann Ihr erstes Bitcoin-Schlüsselpaar. Dies geschieht, indem Javascript im Browser ausgeführt wird.
3. CLIENT - Sie werden nach einem starken Passwort gefragt, um dieses Schlüsselpaar zu sichern.
4. CLIENT - Der Private Key wird im Client mit Javascript verschlüsselt.
5. SERVER - Schließlich werden der öffentliche Schlüssel und der verschlüsselte private Schlüssel zur Speicherung an den Server gesendet.

Der E-Wallet-Dienst hat keinen Zugriff auf Ihre privaten Schlüssel.

Wenn Sie Münzen von Ihrer Adresse ausgeben müssen.

1. Wählen Sie das Bitcoin-Schlüsselpaar aus, von dem Sie ausgeben möchten.
2. CLIENT - Sie werden nach dem Passwort gefragt, um den privaten Schlüssel zu entschlüsseln. Auch dies geschieht clientseitig.
3. KUNDE - Die Zahlungstransaktion wird unterzeichnet. (Im Browser)
4. SERVER - Die Transaktion wird an den Server gesendet und an das Bitcoin-Netzwerk weitergeleitet.

Auch hier sieht der E-Wallet-Dienst Ihren privaten Schlüssel nie.

Es gibt immer noch Risiken bei diesem Ansatz.

1. Keylogger oder Malware könnten die Passwörter erfassen, die Sie zum Verschlüsseln der Schlüsselpaare verwenden. Es wäre ratsam, einen Browser auf einem sauberen Betriebssystem oder auf einem System zu verwenden, das nicht anfällig für Malware ist, z. B. ein Kindle.

2. Sie müssen darauf vertrauen, dass der E-Wallet-Dienst das Javascript nicht ändert und Ihre Passwörter erfasst. Ein externer Dritter könnte das Javascript vielleicht über Prüfsummen validieren.

3. Eine Serververletzung könnte es einem Angreifer ermöglichen, das clientseitige Javascript zu ändern. Der Dienst sollte einen eigenen Mechanismus zum Überprüfen der Integrität des an den Browser gelieferten Codes bereitstellen.

4. Der Wallet-Service sollte sichere Offsite-Backups aufbewahren.

Dies ist der Ansatz, den eine Reihe neuer Wallet-Dienste wie StrongCoin und BitcoinJS verfolgen .