RSA_public_decrypt und MS Crypto API entsprechen

8

Ich versuche eine Lizenzüberprüfungslösung zu entwickeln. Lizenzen werden auf dem Server mit der Funktion RSA_private_encrypt von OpenSSL codiert.

Für Mac OX X verwende ich RSA_public_decrypt und es funktioniert wie ein Zauber. Unter Windows muss ich sehr wenig Code verwenden, also kann ich nicht mit OpenSSL oder einer anderen Bibliothek verknüpfen UND ich muss MS Crypto API verwenden.

Ich habe mehrere Tage damit verbracht, herauszufinden, was falsch ist, aber ohne Glück. Ich kann den öffentlichen Schlüssel erfolgreich importieren, aber hier endet mein Erfolg. Ich bin mir bewusst, dass ich Byte-Reihenfolge mit CAPI umkehren muss, damit dies nicht das Problem sein kann.

Ich habe alles versucht, einschließlich CryptVerifyMessageSignatureWithKey und CryptDecodeObject , um den Blob mit verschiedenen Parametern zu laden, aber immer noch kein Glück.

Es endet immer mit GetLastError() == CRYPT_E_ASN1_BADTAG , was bedeutet, dass das BLOB nicht ASN1 formatiert ist ... Google sagt nichts über das Ausgabeformat von RSA_private_encrypt ... also bin ich hier völlig verloren.

>

Hier ist der OS X-Code, der auf OpenSSL basiert:

%Vor%

Dieser Teil des Codes unter Windows funktioniert gut, also nehme ich an, dass der öffentliche Schlüssel kein Problem ist.

%Vor%

Aber danach führt alles, was ich mit der Nachricht versuche, zu CRYPT_E_ASN1_BADTAG . Ich probierte CryptMsgOpenToDecode mit CryptMsgUpdate , CryptDecodeObject , CryptVerifyMessageSignatureWithKey - nichts funktioniert.

Grundsätzlich denke ich, dass das Problem in pkcs1 und pkcs7 Inkompatibilität liegt, wie bereits erwähnt. Hat jemand Erfahrung mit pkcs1 Format importieren / konvertieren / etc mit MS CAPI?

Jede Hilfe oder auch nur ein Hinweis wird sehr geschätzt! Vielen Dank im Voraus!

    
strannik 25.01.2013, 18:15
quelle

3 Antworten

4

Sie mischen Signaturformate höherer und niedrigerer Ebenen. OpenSSL akzeptiert standardmäßig PKCS # 1 v1.5-Signaturen, die nur die Signaturdaten enthalten. Windows scheint PKCS # 7-Container zu übernehmen. Diese können ein PKCS # 1 v1.5 enthalten, aber diese und andere Daten werden mit dem Format ASN.1 BER tag / length umgebrochen. Wenn die Microsoft API versucht, dies zu decodieren, wird davon ausgegangen, dass die rohe Signatur das Containerformat ist und die Decodierung fehlschlägt.

    
Maarten Bodewes 25.01.2013 23:28
quelle
1

Wenn das nicht so offensichtlich ist, dass Sie es versucht haben, es aber weggelassen haben oder ich Ihre Frage falsch verstanden habe, sollten Sie CryptDecrypt , um die Lizenz zu entschlüsseln, nicht die Funktionen, die Sie in der Frage erwähnen. Beachten Sie, dass, da Sie anscheinend OpenSSL mit PKCS # 1 v1.5 padding verwenden und CryptoAPI das nicht zu unterstützen scheint (nicht getestet, aber die Spezifikationen nur PKCS # 1 v2 OAEP auflisten), Sie wahrscheinlich% co_de verwenden müssen % und überprüfen und entfernen Sie das PKCS # 1 v1.5 Padding nach der Entschlüsselung manuell.

    
Daniel Roethlisberger 26.01.2013 14:59
quelle
0

OpenSSL exportiert Schlüssel mit extra Header, was CryptoAPI nicht erwartet.

Header für privaten Schlüssel (in ASN.1 Notation):

%Vor%

Kopfzeile für öffentlichen Schlüssel (in ASN.1 Notation):

%Vor%

Diese Header bewirken, dass CryptDecodeObjectEx erstickt. Es erwartet RAW-Schlüsseldaten ohne Header.

Also, im Grunde brauchen Sie:

  1. (Optional) Konvertieren von .PEM in .DER mit CryptStringToBinary.
  2. Überprüfen Sie, ob DER mit den oben genannten Headern beginnt. Dazu müssen Sie ASN.1-codierte Daten lesen.
  3. (Optional) Überspringen Sie den oben genannten Header und suchen Sie direkt nach den Daten des Schlüssels (beginnt mit SEQUENCE, die 2 INTEGER für den öffentlichen Schlüssel oder 9 INTEGER für den privaten Schlüssel enthält).
  4. Liefern Sie das Ergebnis an CryptDecodeObjectEx (X509_ASN_ENCODING, RSA_CSP_PUBLICKEYBLOB / PKCS_RSA_PRIVATE_KEY).
  5. Importieren Sie Schlüssel mit CryptImportKey.
Alex 04.12.2015 16:43
quelle