简体   繁体   中英

Verify Java Signature Class Signature With OpenSSL

I'm working on some code trying to sign some data. I am using the Java Signature class with SHA256withRSA, after having converted an openssl generated private key into a Java Keystore. I am trying to confirm the signature given back from the Java class in openssl, but for some reason I cannot get openssl to verify. I am going to eventually need to implement this signature verification in iOS Swift 3, but before I found a library I wanted to try and check the Java signature against the openssl standard.

For example, I get this response from our login server (signature is given as a base64 encoded version of the byte array given by Signature.sign()):

HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Undertow/1
TokenSignature: WtHSxFAy6yO2Bepb4NgRxYhRUEmKS793gd1NBX/bDErBjD3CTiLA8p05RNIG8U96bkwyi/ZySmQVwQf2w4meHMDBBpf7AnCSd1yZeBDeuWChiP3pGdUb3yuGIAnJdlKFHjaElDaJ3eqZD7JZcpcNeZv6xSQUZVi+xgZiUCtnZTYUZmkoRltkcEEbIv0rkERIsMhuuKAuLli7x76/XCpwNZ8dGc356Zzsq/gRhh8BrGejGKDJh/1D1iWAI6tfnBufs0EBe0E5kVm++3QVHNawETSjglBtUvre4ineSW9eTgzYfamijw2fvXOLVYf0p7iCdXJDFb9Pgm5ZDLGW4t/y6A==
Server: WildFly/10
Content-Type: application/json
Content-Length: 343
Date: Mon, 06 Mar 2017 23:28:57 GMT

{"tokenId":8728935,"studentID":8580329,"username":"pkirkland","deviceName":"iPhone","expirationDate":1488842937819,"blacklisted":false,"employeeType":"student","groups":[{"id":9235,"name":"Software","ldapName":"cn=Software, cn=Groups, dc=example, dc=com"},{"id":9257,"name":"Students","ldapName":"cn=Students, cn=Groups, dc=example, dc=com"}]}

from the Java Signature class using the private key.

The following is the public key in the keystore:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzX3f7gRMdClWmI1c03Ut
u60JYJuHiSEnm8bfBhfa/UuGSY7dIGPE9tBt83lF9t2VvEz3GYsqWidrasUEbnf+
zAIYddk/6Z4Mdin6qNpYyh71dpDBBnvB2GB2atAhJlmS8BkaSt8nRBi9kFppTciJ
TxpA7w+TucHV7YabSObyRUif+bRRYhNB2sY1I2zHB5fsg2SpBVYlYGnff5O7boKY
o0QPW5WBtBL84xRJcvPBG8Azz4nPZuuW5gGCWY4kMj6fdT5n3yBAj0VeOxR9DO9e
zG+BtTnJj9+F12lSZanIQlxjKjYRebuBsF9WKelLuW0iNTUVObMIyc+CmJs45rOg
VQIDAQAB
-----END PUBLIC KEY-----

The following is the private key in the keystore (we are not on prod):

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAzX3f7gRMdClWmI1c03Utu60JYJuHiSEnm8bfBhfa/UuGSY7d
IGPE9tBt83lF9t2VvEz3GYsqWidrasUEbnf+zAIYddk/6Z4Mdin6qNpYyh71dpDB
BnvB2GB2atAhJlmS8BkaSt8nRBi9kFppTciJTxpA7w+TucHV7YabSObyRUif+bRR
YhNB2sY1I2zHB5fsg2SpBVYlYGnff5O7boKYo0QPW5WBtBL84xRJcvPBG8Azz4nP
ZuuW5gGCWY4kMj6fdT5n3yBAj0VeOxR9DO9ezG+BtTnJj9+F12lSZanIQlxjKjYR
ebuBsF9WKelLuW0iNTUVObMIyc+CmJs45rOgVQIDAQABAoIBAAkeOL16+1l8LBeA
zkmjvW/CcdQTkqQHEJbc8DB5BoKOw1qoOC+jva2l+fr/upcFpgtA7wX3It31OdL3
AwdT076BqUwxY6CeHrdvjWvIpH/zd7jXG3mKLEPJo/eBXLcy6k41DvGbjUZ8Qo0R
NfL5nv4fkBoLeuaXL0Lm4iUN+loQlocfIbc0LSd4xk84S8OcjflBkBt/YdV7YsO5
4QMgDdFJ6nZVNcGRnwoiCsIS+cdDNjukvuqFMnSz12/IZ3/HXBycy3GGB4cgVRJS
iKtTckH7hr5iT07XT/McuUVEXKotxTzqAEoPwG07hqx4WQeTFnXakKBOyx1LLZSx
dt64IwECgYEA8VSi+kOu3mMusaVTkHpvzRBDLCWYvyub+hgaix4OUMxcglFfxBqq
EISx33ri2uIuwcfDXNqte0O7Cz80E/hTWKUDFlQu8u+yNvgPFkNAlGoqNz0/9oqA
2vDHjDhGTpTkGWJ//8CYpFJe6NO75ewoPpzUhLxz+S/HeITD7LV4+lECgYEA2fuL
zv16MHBhIOVlXPEiWWRhztPP8e02z0xNdZiMJIIQa5DA0y/TNrCwKBwu1/FLPU+z
NP1EXEJLB9y+IdEVisb/GVmDspVgE6ksk7JukCgDBrDts+6aSMt1Xy3y+aFIcxhq
m2a70rdyhrDC6/iSLc/sfqE3A0T3PHGXmaUrAMUCgYA4c1XUOLTU7Fplz4hmiV1R
mHY+A2Vhgm/v5md/Fz6+A6+4BBTkqGATkRaScgpSrQnG5lV6iOR/qu47yUMDUNke
KSs5s+NvjEYhuZC94mlezh6l4TvvDaLqk9v5nshDZWydy36pcoHCHkp5J94SAFXB
n6nOis6OAXElbdjuq9xqoQKBgQC+Btf+fmKCz7UcpF4VA/FZ1HSfhW8GDDF3zaDJ
H08slGYUH4C5mjuatbUbglYj0ioxLMWhMBjkBLa8B+eIO2l4Lbo9MxfoGuhCu3ws
1aQk73yT3LGb5imBxDxx2PC0RbGPBH4LMygRrfKdEIMcivmEDnqweYIny3tsqenq
+13dsQKBgE+OkJgU8cJgvVhI8QmFwJekfbB9HFOX7xZrcGdTA3/TaEPiuxiUvLaS
jEOIi5nDW4ZfEPeggFQcaKdbTvbCRjfkJFye6ftm8soNhayuy35atZX7u9RYjvJ8
PZptOTd/xFTWxpux4xfu6BrBRsJF73DLkOo2JLgcQTYVZEs0cFR6
-----END RSA PRIVATE KEY-----

which is the same public key from the openssl keys. I know the private keys look different because one is PKCS#1 and one is PKCS#8, but I don't think that matters, since it is just a different storage format.

The problem is, when I go to use openssl to verify that signature using the public key in the original .pub form, openssl tells me "verification failed". Is there a difference in the padding or encoding somewhere? If so, what can I do to check using openssl?

Edit

I am trying to verify a signature on a JSON object with user information in it. The code is basic Java Signature code, but here it is anyway.

byte[] unsigned = objString.getBytes("UTF-8");
Signature signer = Signature.getInstance("SHA256withRSA");
signer.initSign(cs.getPrivateKey());
signer.update(unsigned); //prepare for signature
byte[] signature = signer.sign(); 

Where objString is the JSON object and cs is a Crypto Singleton being used to access the keys from the database.

EDIT: My partner confirmed that we are checking the binary version against the data and that is what is failing.

To verify in openssl, I saved the signature to a txt file and passed it to

base64 -d sig.txt> sig.bin
openssl dgst -sha256 -verify pubkey.pub -signature sig.bin data.json

Aside: The Java Signature API, and PKC signature in general, uses a hash but produces a signature not a hash. An RSA signature is sometimes loosely described as an 'encrypted hash' but this is technically wrong, and for other signature schemes there is not even a concept of encryption.

The actual signature produced by Signature.sign() is (as your code indicates) a byte[] containing binary. The value you posted is apparently base64-encoded , which is a common way of representing modern cryptographic data and other binary data. If you convert that base64 back to binary it does verify at least as far as recovering a valid PKCS1v1.5 'type 1' block for a SHA256 hash. Try:

openssl base64 -d -A <sig.txt >sig.bin   # if version 1.1.0+ can omit -A
openssl dgst -sha256 -verify pubkey.pub -signature sig.bin data.json

Another aside: RSA at size 1024 bits, although not actually broken so far as is publicly known, is no longer (since 2014) rated as providing a sufficient margin for acceptable security. Most authorities now require 2048, and technically you should use at least 1280 or 1536 -- barring significant advances in quantum computing, which is not presently predictable. However, that's a matter for security.SX or maybe crypto.SX, not SO.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM