Verify Java Signature Class Signature With OpenSSL

Question

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:

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

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

dave_thompson_085 dave_thompson_085 · Accepted Answer · 2017-03-04T10:01:53

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.

Verify Java Signature Class Signature With OpenSSL

1 Answers