Höheres Vertrauen in den ROI unter Wahrung der Geheimhaltung personenbezogener Daten

Dieser Beitrag ist eine Antwort auf habrahabr.ru/post/244753

Um das Vertrauen und die Transparenz in den ROI zu erhöhen, können Sie eine relativ einfache Lösung anwenden, die in diesem Beitrag beschrieben wird. Wenn ein Benutzer für eine Initiative stimmt, diese ablehnt oder seine Stimme zurückzieht, muss der ROI einen speziellen Bestätigungscode generieren, der jedoch keine persönlichen Informationen des Benutzers enthält. Eine Liste solcher Codes sollte öffentlich zugänglich sein. Somit konnte jeder das Ergebnis der Aufzeichnung seiner Stimmabgabe im öffentlichen Bereich überprüfen. Diese technische Lösung ist einfach, ermöglicht eine gewisse Kontrolle der Stimmenzählung und erhöht so das Vertrauen der Bürger in den ROI.

Vorgeschlagenes Aktionsprotokoll.

Zunächst generiert die ROI ein 2048-Bit-RSA-Schlüsselpaar (SK, PK) zur Verwendung als elektronische digitale Signatur (EDS), wobei SK der geheime Schlüssel und PK der öffentliche Schlüssel ist. Der öffentliche Schlüssel wird im öffentlichen Bereich veröffentlicht, und das Geheimnis wird nur auf dem ROI-Server gespeichert und verwendet. Solche Schlüssel können einer für den gesamten ROI oder viele verschiedene für verschiedene Initiativen sein. Beispielsweise können Sie für jede Initiative einen eigenen Schlüssel generieren. Oder aktualisieren Sie den Schlüssel von Zeit zu Zeit für den gesamten ROI. Zur Identifizierung des Schlüssels verwenden wir das Konzept der „Schlüsselversion“ (oder Index, Schlüsselnummer). Darüber hinaus kann der ROI ein Schlüsselzertifikat veröffentlichen, ist jedoch für die erste Version des Systems überhaupt nicht erforderlich.

Die Struktur und Generierung von Codes, die öffentlich verfügbar sein sollen.

1.Bei der Abstimmung durch den Benutzer bildet der ROI den folgenden 49 Byte langen Vektor V:
Schlüsselversion (Nummer): 4 Byte Anfangsnummer
: 4 Byte
Ereigniszeit (UTC-Zeit): 8 Byte
Ereignistyp: 1 Byte (FOR, AGAINST, REVIEW)
Wähler-Hash Benutzer, berechnet als
H = SHA256 (UserSecret; SNILS; Initiativennummer): 32 Byte.

UserSecret ist ein Geheimnis, dessen Quelle der Benutzer selbst ist. Beispielsweise kann es sich um ein Passwort für eine Abstimmung handeln, das ein Benutzer bei der Abstimmung auf der ROI-Website eingibt. Wenn die ROI dies technisch zulässt, kann es sich bei der Eingabe der ROI oder ihres Hashs um ein Passwort handeln. In diesem Fall kann die ROI diese automatisch in das Feld einsetzen. Auf jeden Fall sollte es das sein, was vom Benutzer kommt, und dass er niemanden kennt und sonst niemanden. Über die Gründe für die Innovation - lesen Sie die Spoiler-Kommentare.
UPD: Änderungen zur Erstausgabe, Motivation
Es war: H = SHA256 (SK; SNILS; Initiativennummer): 32 Bytes.
In den Diskussionen wurde deutlich, dass das System eine Lücke hat. Stellen Sie sich folgendes Szenario vor: ROI speichert die Ergebnisse zwischen und gibt sie beispielsweise alle 5 Minuten aus. Nehmen wir an, ein Benutzer hat abgestimmt und der richtige Code wird generiert und an ihn gesendet (Vx, Sx). Angenommen, jemand anderes stimmt in diesen 5 Minuten ebenfalls ab, und der ROI kann ihm keinen neuen Code senden, sondern den Code des vorherigen Benutzers (Vx, Sx). Später, wenn beide Benutzer ihre Codes überprüfen, sehen sie, dass sich ihr Code auf der Anweisung befindet, aber der Zähler am ROI wird nur um 1 erhöht, und dies kann nicht überprüft werden. Das heißt, wir erhalten ein Szenario, in dem eine Stimme beim ROI verschwinden kann. Das schwache Glied ist hier der Hx-Vektor. Daher ist es notwendig, dass der Benutzer selbst die Richtigkeit der Anfangsdaten dieses Vektors überprüfen kann, dies jedoch niemand anderes könnte. Dies macht das System etwas komplizierter.

Es ist zu beachten, dass wenn ein Benutzer mehrere Aktionen ausführt, z. B. FOR-REVIEW-AGAINST, UserSecret für alle diese Aktionen unverändert bleiben muss, sodass es in den Hx-Protokollen für diese Vorgänge für einen Benutzer und die ausgewählte Initiative identisch ist. In dem Fall, dass es nicht möglich ist, sich an die Stimme zu erinnern (wie es jetzt beim ROI der Fall ist), wird diese Frage irrelevant und es gibt hier kein Problem.

Folge: Der Benutzer muss nun nicht nur überprüfen, ob sein Code (Vx, Sx) in der Liste der hochzuladenden Protokolle enthalten ist, sondern auch, ob der eindeutige Vektor Hx aus Vx korrekt generiert wurde.


2. Als nächstes verwendet die ROI den entsprechenden RSA-Geheimschlüssel SK, um den zweiten Teil des Codes zu erhalten - digitale Signatur (EDS):
S = RSA_Sign (SK; V) - das Ergebnis ist 256 Bytes.

3. Ein Paar (V; S) wird per E-Mail an den Benutzer gesendet, der abgestimmt hat, und wird auch öffentlich verfügbar gemacht (z. B. im PEM-Textformat).

Vorteile:

• Jeder, der die offene Paarliste {V; S} verwendet, kann die Gesamtzahl der Stimmen für die ausgewählte Initiative berechnen, indem er zuvor jeden Vx-Wert mithilfe des öffentlichen Schlüssels des ROI wie folgt überprüft hat: RSA_Verify (PK; Sx; Vx) gibt den Wert "success" oder "Kein Erfolg." Tatsächlich entschlüsselt die Funktion die Sx-Signatur mithilfe des öffentlichen PK-Schlüssels und vergleicht das Ergebnis mit Vx, wenn es gleich Erfolg ist.

• Jeder auf der Liste {V; S} kann seinen Abstimmungscode finden, da er unmittelbar nach der Abstimmung per E-Mail an den Benutzer gesendet werden muss. Wird der Code nicht in der allgemeinen Liste gefunden, kann der Benutzer sein Paar (Vx, Sx) als Beweis für eine nicht belegte Stimme vorlegen. Darüber hinaus muss der Benutzer überprüfen, ob sein eigener Vektor Hx aus Vx korrekt generiert wurde. Dies schließt ein Szenario aus, in dem der ROI dasselbe Paar (Vx, Sx) an zwei Benutzer sendet und nur eine Stimme berücksichtigt.

• Dritte können ohne Angabe des entsprechenden Sx-Signaturpaars nicht über die für Vx nicht registrierte Stimme sprechen, da Sie hierfür den geheimen ROI-Schlüssel kennen müssen. Somit ist der ROI vor unzumutbaren Ansprüchen dieser Art geschützt.

• Feld H wird in Zeile V eingefügt, um die Aktionen desselben Benutzers im Rahmen der ausgewählten Initiative eindeutig zu identifizieren. Beispielsweise muss die PROCESS-CANCEL-Sequenz an einen bestimmten Benutzer gebunden sein, damit diese Sequenz in der {V; S} -Ereignisliste nachverfolgt werden kann. Gleichzeitig ist das SNILS des Benutzers selbst nicht verfügbar, da der geheime Schlüssel der ROI in dem auf dem ROI-Server generierten Hash enthalten ist. Weder der geheime Schlüssel noch die SNILS einer Person können vom Hash erkannt werden. Und selbst wenn SNILS bekannt ist, ist es unmöglich, den geheimen Schlüssel des ROI per Hash herauszufinden. Es ist auch unmöglich zu überprüfen, wie die eine oder andere Person mit SNILS abgestimmt hat, da es sich bei der Verbindung zwischen SNILS und H nicht um eine öffentliche Information handelt. Sie ist nur der Person bekannt, die abgestimmt hat. sowie das Ergebnis der Abstimmung - diese Informationen werden nun per E-Mail an den Benutzer gesendet. Somit ändert dieses Design nicht das derzeitige Sicherheitsniveau persönlicher Informationen (als Person, für die abgestimmt wurde), und es kommt nicht zu einem Informationsverlust über SNILS oder den geheimen ROI-Schlüssel.

• Wenn ein verlorener Benutzer (Vx, Sx) einem Publikum von einem bestimmten Benutzer präsentiert wird, wird ein Verbindungspaar zwischen der Stimme und der bestimmten Person erstellt, und dann wird allen klar, wie diese bestimmte Person abgestimmt hat. Aber jetzt ist die Situation ähnlich - wenn ich gestimmt habe und meine Stimme nicht gezählt wurde, dann werde ich in diesem Sinne öffentlich darüber informieren, wie ich gestimmt habe. Das Plus ist jedoch, dass die verlorene Stimme (Vx, Sx) und damit der Anspruch auf den ROI anonym auf den öffentlichen Raum übertragen werden kann, ohne dass eine Verbindung mit einem bestimmten Benutzer hergestellt werden muss.

Nachteile:

• Es ist unmöglich, das Szenario zu verfolgen, in dem der ROI Stimmen FÜR oder WIEDER für nicht vorhandene SNILS hinzufügen kann. Aber dieses Szenario ist jetzt möglich.

Technische Umsetzung:

Um diese Idee umzusetzen, kann die ROI OpenSSL (eine offene und kostenlose kryptografische Bibliothek, die in vielen Systemen weit verbreitet ist sowie zum Einstellen von verschlüsselten Kanälen in IP-Verbindungen, Browsern und vielen anderen Anwendungen) installieren und über ihre Skripte für alle oben genannten Vorgänge verwenden: Generierung RSA-Schlüssel (für digitale Signatur), Signieren und Hashing von SHA256. Die Schlüsselgenerierung ist eine langsame Operation, aber selten (einmalig oder beim Öffnen einer neuen Initiative). Das Signieren und Hashing von privaten Schlüsseln ist ein schneller Vorgang. OpenSSL kann sowohl über die Befehlszeile oder das Skript als auch aus verschiedenen kompilierten Programmiersprachen wie C / C ++ verwendet werden. Die Implementierung erfordert keine infrastrukturellen oder anderen komplexen Schritte und passt möglicherweise in mehrere Skript- oder Codezeilen.

UPD: Klarstellungen und Ergänzungen auf Wunsch der Leser.
Ich habe das Gefühl, dass, wenn alle Meinungen gefaltet sind, es sich als Null herausstellen wird. Aber ich werde versuchen:

1. Ich habe durch einen Text klargestellt, dass der RSA-Schlüssel auf der ROI-Seite zur Verwendung als EDS generiert wird. Auch RSA_Encrypt / RSA_Decrypt wurden durch RSA_Sign / RSA_Verify ersetzt.

2. Es gab eine Frage, warum nicht ECDSA 256 Bit (Elliptic Curve Digital Signing Algorithmus). Ja, die Menge der digitalen Signatur S hat Vorteile. Es werden nicht 256 Bytes, wie im Fall von RSA, sondern 72 Bytes sein. Aber es gibt auch Geschwindigkeitsnachteile. Die Operation RSA_Verify ist um ein Vielfaches schneller als ECDSA_Sign and Verify. Und wenn wir einfach RSA_Sign / Verify in RSA_Encrypt / Decrypt ändern und SK anstelle von PK veröffentlichen, erhalten wir einen Server, der schnell signieren kann, und zwar um ein Vielfaches schneller als ECDSA.

3. Warum nicht GOST? Ich habe von unseren sowjetischen Standards aus den Augenwinkeln gehört. Ich weiß nur, dass einige von ihnen von ausländischen Ideen kopiert wurden und etwas hinzugefügt wurde, damit es anders aussieht. Ein Beispiel ist der im KGB erstellte GOST-Code (ich kenne ihn aus der wissenschaftlichen Gemeinschaft unter diesem Namen), der 3DES mit geringfügigen Abweichungen kopiert. Nach GOST-Hash-Algorithmus die gleichen Fragen - ich habe keine Ahnung.

4. Um zu verhindern, dass die Chinesen ähnliche Fragen stellen (sie haben auch etwas Eigenes), wie in den Absätzen 2–3, ersetzen Sie es einfach sofort: Lassen Sie den asymmetrischen Algorithmus X und den Hashing-Algorithmus Y sein und wählen Sie den gewünschten aus. Befolgen Sie einfach die Sicherheitsstufe von mindestens 128 Bit für die verwendeten Algorithmen (vorzugsweise 256), ansonsten ist dies eine Frage der Wahl und hat keinen großen Einfluss auf das Wesentliche.

Vielen Dank!

Jetzt auch beliebt: