Подписанное сообщение с использованием OpenSSL; не могу проверить с помощью Android Java

Я использую SHA256 и RSA для подписи сообщения на моем компьютере с Ubuntu с помощью OpenSSL. Моя цель - проверить это сообщение на Android с помощью Android Java.

В Ubuntu использовались следующие команды:

openssl genrsa -out private.pem 1024 
openssl rsa -in private.pem -out public.pem -outform PEM -pubout
echo 'foobar' > data.txt
openssl dgst -sha256 < data.txt > hash
openssl rsautl -sign -inkey private.pem -keyform PEM -in hash  > signature
openssl rsa -in private_key.pem -pubout -outform DER -out public_key.der
openssl enc -base64 -in signature -out base64_signature

Теперь я создал ключи, подписал сообщение, создал файл .der для открытого ключа, к которому должен быть доступ в Java, и закодировал сообщение с помощью Base64. Затем я помещаю открытый ключ .der на свое устройство и успешно загружаю ключ в класс PublicKey.

Этот метод используется для проверки сообщения:

public static boolean verify(PublicKey publicKey,String data,String verification){
    java.security.Signature sig;
    try {
        sig = java.security.Signature.getInstance("SHA256WithRSA");
        sig.initVerify(publicKey);
        try {
            sig.update(verification.getBytes());
        } catch (Exception e) {
            ...
        }

        if (!sig.verify(Base64.decode(data, Base64.DEFAULT))) {
            return false;
        }
        return true;
    }
    catch ....
    return false;
}

Параметры при вызове метода:

verify(PublicKey, Base64 encoded data in a String that is to be verified, "foobar");

Очевидно, проверка не удалась, но я не могу понять, почему. Я предполагаю, что это должно что-то делать с кодировкой (?).


Обновлять! Так что мне удалось записать результаты Base64.decode(data, Base64.DEFAULT)) в файл и сравнить его с исходным файлом подписи с помощью шестнадцатеричного редактора. Полностью отличается!


person GilCol    schedule 23.06.2015    source источник
comment
Кодирование текста может быть проблемой. Вы можете проверить это, создав SAH256 MessageDigest вашего используемого verification и сравнив вывод с хешем OpenSSL. Вы также можете проверить содержимое своей подписи, расшифровав ее на Java с помощью RSA/ECB/NoPadding.   -  person Robert    schedule 23.06.2015


Ответы (1)


Java создает и ожидает получать подписи в несколько иной форме. Хэш сообщения должен быть закодирован в DER, затем дополнен PKCS#1 и только после этого подписан закрытым ключом. И в Openssl есть команда для этого (поскольку на самом деле это стандартная процедура). Вместо

openssl dgst -sha256 < data.txt > hash
openssl rsautl -sign -inkey private.pem -keyform PEM -in hash  > signature

вы делаете

openssl dgst -sha256 -binary -sign private.pem data.txt > signature

Также обратите внимание:

  • ваш data.txt содержит новую строку, не забудьте об этом в переменной String verification
  • sig.update(verification.getBytes()) должен явно указывать кодировку - ту же кодировку, которая использовалась для заполнения файла data.txt, например: sig.update(verification.getBytes("UTF-8"))

Остальные ваши команды/код выглядят нормально.


UPD - чтобы ответить @GilCol о различиях:

Заполнение одинаково для обоих подписанных сообщений (PKCS#1). Но сообщения разные.

Когда вы используете openssl dgst -sha256 < data.txt > hash, hash будет содержать (в зависимости от версии openssl):

(stdin)= aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f

or

aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f

Это просто текст, и это сообщение, которое вы подписываете с помощью openssl rsautl -sign .... Мы можем видеть это с openssl rsautl -verify ...:

# raw message as-is - we can see the padding
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -raw -hexdump
0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0070 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0080 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0090 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00a0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00b0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff 00 61   ...............a #
00c0 - 65 63 30 37 30 36 34 35-66 65 35 33 65 65 33 62   ec070645fe53ee3b #
00d0 - 33 37 36 33 30 35 39 33-37 36 31 33 34 66 30 35   3763059376134f05 # your plain-text message
00e0 - 38 63 63 33 33 37 32 34-37 63 39 37 38 61 64 64   8cc337247c978add #
00f0 - 31 37 38 62 36 63 63 64-66 62 30 30 31 39 66 0a   178b6ccdfb0019f. # we can even see newline char (0a) at the end

# strip the padding
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -pkcs -hexdump
0000 - 61 65 63 30 37 30 36 34-35 66 65 35 33 65 65 33   aec070645fe53ee3
0010 - 62 33 37 36 33 30 35 39-33 37 36 31 33 34 66 30   b3763059376134f0
0020 - 35 38 63 63 33 33 37 32-34 37 63 39 37 38 61 64   58cc337247c978ad
0030 - 64 31 37 38 62 36 63 63-64 66 62 30 30 31 39 66   d178b6ccdfb0019f
0040 - 0a                                                .

Если использовать openssl dgst -sha256 -binary < data.txt > hash для получения хэша в бинарном (чистом) виде, а затем подписать его, результат будет лучше, но все же не то:

# raw message as-is - we can see the same padding
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -raw -hexdump
0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0070 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0080 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0090 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00a0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00b0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00c0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00d0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff 00   ................
00e0 - ae c0 70 64 5f e5 3e e3-b3 76 30 59 37 61 34 f0   ..pd_.>..v0Y7a4. # the hash - now in binary form
00f0 - 58 cc 33 72 47 c9 78 ad-d1 78 b6 cc df b0 01 9f   X.3rG.x..x...... #

# strip the padding
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -pkcs -hexdump
0000 - ae c0 70 64 5f e5 3e e3-b3 76 30 59 37 61 34 f0   ..pd_.>..v0Y7a4. # just the hash, nothing else
0010 - 58 cc 33 72 47 c9 78 ad-d1 78 b6 cc df b0 01 9f   X.3rG.x..x...... #

Но когда вы используете openssl dgst -sha256 -sign ..., сообщение отличается — теперь это стандартная структура ASN.1 для дайджестов сообщений (хэшей). Посмотрим:

# raw message as-is - we can see the same padding
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -raw -hexdump
0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0070 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0080 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0090 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00a0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00b0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00c0 - ff ff ff ff ff ff ff ff-ff ff ff ff 00 30 31 30   .............010 #
00d0 - 0d 06 09 60 86 48 01 65-03 04 02 01 05 00 04 20   ...`.H.e.......  # the message - it's different
00e0 - ae c0 70 64 5f e5 3e e3-b3 76 30 59 37 61 34 f0   ..pd_.>..v0Y7a4. # <- we can see the hash (in binary form) starting at this line
00f0 - 58 cc 33 72 47 c9 78 ad-d1 78 b6 cc df b0 01 9f   X.3rG.x..x...... #

# strip the padding
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -pkcs -hexdump
0000 - 30 31 30 0d 06 09 60 86-48 01 65 03 04 02 01 05   010...`.H.e.....
0010 - 00 04 20 ae c0 70 64 5f-e5 3e e3 b3 76 30 59 37   .. ..pd_.>..v0Y7
0020 - 61 34 f0 58 cc 33 72 47-c9 78 ad d1 78 b6 cc df   a4.X.3rG.x..x...
0030 - b0 01 9f                                          ...

# parse the message and show the underlying ASN.1 structure
$ openssl rsautl -in signature -pubin -inkey public.pem -verify -pkcs -asn1parse 
    0:d=0  hl=2 l=  49 cons: SEQUENCE          
    2:d=1  hl=2 l=  13 cons:  SEQUENCE          
    4:d=2  hl=2 l=   9 prim:   OBJECT            :sha256               # type of hash
   15:d=2  hl=2 l=   0 prim:   NULL              
   17:d=1  hl=2 l=  32 prim:  OCTET STRING      
      0000 - ae c0 70 64 5f e5 3e e3-b3 76 30 59 37 61 34 f0   ..pd_.>..v0Y7a4. # the hash in binary form
      0010 - 58 cc 33 72 47 c9 78 ad-d1 78 b6 cc df b0 01 9f   X.3rG.x..x...... # and no extra newline chars

Как видите, только последний файл signature имел правильную структуру ASN.1, предыдущие два были просто "какими-то произвольными" сообщениями, подписанными приватным ключом RSA.

person Roman    schedule 24.06.2015
comment
Спасибо, это решило мою проблему. Я также нашел эту тему: stackoverflow.com/questions/13419201/ Но я до сих пор не понимаю криптографической разницы между этими командами. Прокладка разная или что? - person GilCol; 25.06.2015
comment
Вы просто спасли мне жизнь этим объяснением, спасибо! - person GregorMohorko; 05.02.2017