Ich habe bis jetzt zwei Tage damit verbracht und jede mir zur Verfügung stehende Quelle durchgekämmt, also ist dies der letzte Ausweg.
Ich habe ein X509-Zertifikat, dessen öffentlicher Schlüssel ich im Schlüsselbund des iPhones gespeichert habe (Simulator nur an dieser Stelle). Auf der ASP.NET-Seite habe ich das Zertifikat im Zertifikatsspeicher mit einem privaten Schlüssel. Wenn ich eine Zeichenfolge auf dem iPhone verschlüssle und sie auf dem Server entschlüssle, bekomme ich eine CryptographicException "Bad data". Ich habe versucht, das Array.Reverse vorgeschlagen auf der RSACryptoServiceProvider Seite auf eine Longshot, aber es hat nicht geholfen.
Ich habe die Basis-64-Saiten auf beiden Seiten verglichen und sie sind gleich. Ich habe die rohen Byte-Arrays nach der Decodierung verglichen und sie sind auch gleich. Wenn ich auf dem Server mit dem öffentlichen Schlüssel verschlüsseln, unterscheidet sich das Byte-Array von der iPhone-Version und entschlüsselt leicht mit dem privaten Schlüssel. Die rohe Klartext-Zeichenfolge besteht aus 115 Zeichen und liegt damit innerhalb der 256-Byte-Begrenzung meines 2048-Bit-Schlüssels.
Hier ist die iPhone-Verschlüsselungsmethode (ziemlich wörtlich aus der CryptoExercise Beispiel App ) s wrapSymmetricKey Methode):
Und hier ist die serverseitige C # Entschlüsselungsmethode:
%Vor% Mein Verdacht war, dass es zwischen den Plattformen einige Verschlüsselungsprobleme gab. Ich weiß, dass der eine Big-Endian ist und der andere Little-Endian ist, aber ich weiß nicht genug, um zu sagen, was oder wie man den Unterschied überwinden kann. Mac OS X, Windows und das iPhone sind alle Little-Endian, das ist also nicht das Problem.
Neue Theorie: Wenn Sie den booleschen Booleschen Wert für OAEP auf false setzen, wird standardmäßig PKCS # 1 1.5-Padding verwendet. Offenbar ist SecKey hat nur SecPadding -Definitionen von PKCS1 , PKCS1MD2 , PKCS1MD5 und PKCS1SHA1 . Vielleicht Microsofts PKCS # 1 1.5! = Apple's PKCS1 und so beeinflusst das Auffüllen die binäre Ausgabe der Verschlüsselung. Ich habe versucht, kSecPaddingPKCS1 mit dem fOAEP auf false zu setzen und es hat immer noch nicht funktioniert. kSecPaddingPKCS1 Äquivalent zu PKCS # 1 1.5. Zurück zum Zeichenbrett über Theorien ...
Andere neu erprobte Theorien:
Erfolg!
Es stellte sich heraus, dass ich in meinem Schlüsselbund auf dem iPhone Simulator etwas Crust hatte, der sozusagen die Gewässer verdreckte. Ich habe die Schlüsselbund-Datenbank bei ~/Library/Application Support/iPhone Simulator/User/Library/Keychains/keychain-2-debug.db gelöscht, damit sie neu erstellt wird und es funktioniert. Danke für all deine Hilfe. Zahlen, es wäre etwas Einfaches, aber nicht offensichtlich. (Zwei Dinge, die ich gelernt habe: 1) die App aus dem Simulator zu deinstallieren, löscht nicht ihre Schlüsselbund-Einträge und 2) startet absolut regelmäßig in regelmäßigen Abständen.)
HINWEIS: Der generische Pfad für die Schlüsselbunddatei hängt von der iOS-Version ab: ~ / Bibliothek / Anwendungsunterstützung / iPhone Simulator / [version] /Library/Keychains/keychain-2-debug.db z.B., ~ / Bibliothek / Anwendungsunterstützung / iPhone Simulator / 4.3 / Bibliothek / Schlüsselanhänger / keychain-2-debug.db
Nun ... der erste Schritt (wie Sie sagen, dass Sie getan haben) ist, die gleichen Nachrichten mit den gleichen Initialisierungsvektoren zu verschlüsseln, die sowohl die iPhone- als auch die C # -Implementierung verwenden. Sie sollten die gleiche Ausgabe erhalten. Du hast gesagt, dass du es nicht getan hast, also gibt es ein Problem.
Dies bedeutet entweder:
Ich würde vorschlagen, dass die ersten beiden unwahrscheinlich sind, aber sie sind entfernt möglich.
Sie sagen: "Installierte .cer-Datei in verschiedenen Cert-Speicher und Server-verschlüsselte Zeichenfolge abgerundet einfach gut" ... das beweist nichts: all dies beweist, dass eine bestimmte zufällige Reihe von Zahlen Sie verschlüsseln können / auf einer Plattform erfolgreich entschlüsseln. Sie garantieren nicht, dass beide Plattformen die gleichen Zufallszahlen sehen.
Also schlage ich vor, dass Sie es hier auf die niedrigste mögliche Stufe bringen. Überprüfen Sie die direkten (Byte-Array-) Ein- und Ausgänge der Verschlüsselung auf beiden Plattformen. Wenn Sie mit genau den gleichen (binären) Eingängen nicht die gleiche Ausgabe erhalten, haben Sie ein Plattformproblem. Ich denke, das ist unwahrscheinlich, also ich vermute, Sie werden feststellen, dass die IVs unterschiedlich interpretiert werden.
dies ist meine erste Antwort auf stackoverflow, also bitte vergib mir, wenn ich es falsch mache!
Ich kann Ihnen keine vollständige Antwort geben, aber ich hatte sehr ähnliche Probleme, als ich versuchte, in PHP zu integrieren - es scheint, dass das Format der Zertifikatsdateien von Apple ein wenig anders ist als das, was andere Software erwartet (einschließlich openssl) .
So entschlüssele ich eine verschlüsselte Signatur in PHP: Ich extrahiere tatsächlich den Modulus und PK aus dem übertragenen öffentlichen Schlüssel und verwende diesen für den RSA-Code, anstatt zu versuchen, den Schlüssel zu importieren:
%Vor%Das Ziel-c, das diesen öffentlichen Schlüssel erzeugt, ist:
%Vor%Verwenden von SecKeyWrapper aus Apples Beispielprojekt CryptoExercise (Sie können die Datei hier anzeigen: Ссылка )
Ich hoffe, das hilft?
Wird Ihnen das helfen?
Asymmetrische Schlüsselverschlüsselung mit .NET & amp; C #
Da Sie beide Seiten kontrollieren, wäre meine Empfehlung (wenn Sie die Bibliotheksverschlüsselungsalgorithmen nicht auf beiden Plattformen zusammenarbeiten können), die Verschlüsselung auf beiden Seiten mit demselben Algorithmus zu schreiben.
Auf diese Weise haben Sie die Kontrolle und wären in der Lage, die internen Verschlüsselungsfunktionen zu debuggen, um zu sehen, was schief läuft.
Es ist ein letzter Ausweg (natürlich), hätte aber wahrscheinlich weniger Zeit gekostet als die drei Tage, die Sie bereits verbracht haben, und haben eine hohe Erfolgschance.
HTH
Tags und Links c# iphone encryption rsa