Signatur/MAC mittels RSA
-
Hallo,
Mein Wissen bzgl. Kryptographie und digitalen Signaturen ist bislang ziemlich überschaubar, dennoch suche ich für folgendes Szenario ein funktionierendes und sicheres Signatur/MAC-System.
Eine Menge von Kunden wird mit je einer (schwer zu eratenen) Nummer ausgestattet. Mit dieser Nummer soll es möglich sein bei einer Akzeptanzstelle zu bezahlen. Die Akzeptanzstelle hat jedoch nicht unmittelbar Zugriff auf eine Datenbank aller Nummern, sie muss offline prüfen ob die Nummer gültig ist. Außerdem kommt hinzu dass Kunden theoretisch Zugriff auf die Software der Akzeptanzstelle haben (es ist also nicht auszuschließen dass diese den Programmcode disassemblen).
Nach erster Recherche bin ich zu dem Eindruck gekommen, dass eine Möglichkeit wäre, mittels RSA eine Signatur der Nummer zu erstellen und diese an die eigentliche Nummer anzuhängen. Der Schlüssel zum Erzeugen bliebe geheim. Die Akzeptanzstelle kann dagegen auf den öffentlichen Schlüssel zurückgreifen um zu prüfen ob Nummer und Signatur zusammenpassen.
Übersehe ich hier etwas? Würde sich ein anderes Vorgehen besser eignen?
Ich bin mir außerdem nicht im klaren, welche Parameter für eine sichere RSA-Signatur empfehlenswert sind. Da Nummer und Signatur später in einen QR-Code (zum Scannen) verpackt werden sollen, wäre eine möglichst kurze Signatur vorteilhaft.
Vielen Dank schon im Voraus!
Johannes
-
Ups, hast recht. Hatte das selbe Vorgeschlagen, wie Du schon geschrieben hast.
Statt Signatur könnte vielleicht auch die nur Kundennummer RSA verschlüsselt werden.2048 Bits wären so viel: qr
256 Bits nur so viel: qr
-
jtreitz schrieb:
(schwer zu eratenen)
erratenden?
-
jtreitz schrieb:
Eine Menge von Kunden wird mit je einer (schwer zu eratenen) Nummer ausgestattet. Mit dieser Nummer soll es möglich sein bei einer Akzeptanzstelle zu bezahlen. Die Akzeptanzstelle hat jedoch nicht unmittelbar Zugriff auf eine Datenbank aller Nummern, sie muss offline prüfen ob die Nummer gültig ist. Außerdem kommt hinzu dass Kunden theoretisch Zugriff auf die Software der Akzeptanzstelle haben (es ist also nicht auszuschließen dass diese den Programmcode disassemblen).
Können sie auch eigenen Code laufen lassen? Falls ja, was hindert die Nutzer daran, den public key im Code gegen einen anderen auszutauschen?
-
Oder einfach eine eigene "Akzeptanzstelle" erstellen, die immer "ja" sagt.
-
schonmal vielen Dank für die zahlreichen Antworten!
volkard schrieb:
Statt Signatur könnte vielleicht auch die nur Kundennummer RSA verschlüsselt werden.
Dann kann ich aber doch nicht wissen ob die entschlüsselte Message nun wirklich eine Kundenummer ist oder eine beliebige andere Zahl?
finalla schrieb:
jtreitz schrieb:
(schwer zu eratenen)
erratenden?
Sagen wir, das Raten der Nummer ist schwierig
Christoph schrieb:
Können sie auch eigenen Code laufen lassen?
Der Zugriff beschränkt sich auf die Software allgemein, es gibt keinen Zugriff auf das Device selbst, das von der jeweiligen Akzeptanzstelle benutzt wird.
finalla schrieb:
Oder einfach eine eigene "Akzeptanzstelle" erstellen, die immer "ja" sagt.
Das dürfte in der Anwendung kein Problem darstellen, die akzeptierten (zwischengespeicherten) Zahlungen werden anschließend zur Zentrale übertragen, überprüft und dem Konto der Akzeptanzstelle gutgeschrieben.
-
jtreitz schrieb:
schonmal vielen Dank für die zahlreichen Antworten!
volkard schrieb:
Statt Signatur könnte vielleicht auch die nur Kundennummer RSA verschlüsselt werden.
Dann kann ich aber doch nicht wissen ob die entschlüsselte Message nun wirklich eine Kundenummer ist oder eine beliebige andere Zahl?
Naja, eine beliebige Zahl ist zwischen 0 und 2^256, Kundennummern liegen nur zwischen 0 und 2^27. Die Chance auf einen Glückstreffer, also eine 256-Bit-Eingabe, die mit dem öffentlichen Schlüssel verschlüsselt, eine gültige Kundennummer ergibt, dürfte recht gering sein. So ungefähr 1 zu 2^(256-27).
Mit 27Bit Kundennummer und 256-7 Bit Signatur dürfte die Chance, eine gültige Signatur zu erraten, nicht deutlich anders sein.
-
Von der direkten Verwendung von "Nachrichten" als Klartext für RSA-Verschlüsselung rate ich stark ab. Es gibt nicht umsonst so Dinge wie RSA-OAEP für Verschlüsselung und RSA-PSS für digitale Unterschriften. Verwende lieber Standard-Verfahren, -Protokolle, -Formate und Bibliotheken. Kein selbst gebasteltes Zeug.
Ein MAC ist hier unbrauchbar, weil zur Überprüfung des MACs der geheime Schlüssel nötig ist. Ein asymmetrisches Verfahren passt hier schon besser: Digitale Signaturen.
Nachtrag: RSA-PSS erlaubt es, die Nachricht (oder einen Teil davon) direkt in der Signatur unterzubringen. Wenn die zu unterschreibende Nachricht als nur eine kurze Nummer ist, kann man die per RSA-PSS komplett in der Signatur unterbringen. Und eine solche Signatur wirst Du ohne Probleme in einen QR-Code verwandeln können --- also von der Größe her (ich denke da so an die Grßenordnung 2048 Bits).
Mit ECDSA bekommt man auch kürzere Signaturen bei gleicher Sicherheit hin. Aber das ganze EC-Zeug ist glaub'ich mit Patenten überladen. Das RSA Patent ist nämlich schon abgelaufen. Wobei Du Dich bzgl PSS vielleicht noch um Lizenzen kümmern müsstest. Was Patente angeht, bin ich kein Fachmann.
QR-Code, Bezahlsystem & co klingt aber schonmal so, als ob ihr wirklich einen Kryptofachman bezahlen solltet, der sich mal intensiv mit dem Problem beschäftigt. Wenn man sich da ein System überlegt hat, ist man nämlich nicht einfach fertig. Dann muss man erstmal selbst nach allen möglichen Angriffsmöglichkeiten suchen, um vllt eine Lücke zu finden. Neben der Kundennummer gehört sicherlich auch eine einmalige Transaktionsnummer dazu, die vielleicht noch mit einem Gültigkeitszeitraum kombiniert wird, so dass man sich vernünftig gegen Replay-Attacken schützen kann, zB. Oder willst Du irgendwann als Entwickler eines schlecht durchdachten Sicherheitssystems bekannt werden?