Проверка подписи сертификата на контроллерах Microchip PIC - PullRequest
Новая
       36

Проверка подписи сертификата на контроллерах Microchip PIC

1 голос
/ 18 октября 2011

Я пытаюсь реализовать проверку подписи сертификата на контроллере Microchip pic (сертификаты создаются и подписываются с использованием OpenSSL).Контроллер Microchip PIC не поддерживает библиотеки OpenSSL, но у него есть функция шифрования / дешифрования.Мне удалось получить SSL-соединение между контроллером PIC и веб-сервером.Мой следующий шаг - настроить проверку подписи на контроллере PIC.

После прочтения стандарта шифрования RSA PKCS # 1 V2.1 (http://www.rsa.com/rsalabs/node.asp?id=2125) я понял, что шифрование по сути то же самое, что проверка подписи, а дешифрование - это то же самое, что и подписывание. Более конкретно, для шифрования и проверки используютсяоткрытый ключ и следующая формула:

m = s ^ e mod n

Где s - подпись или сообщение, e - открытый показатель степени, n -модуль и m - это зашифрованное сообщение или декодированная подпись. Поэтому я пытаюсь использовать предоставленный алгоритм шифрования для проверки подписи.

Для проверки сертификата я сгенерировал хэш SHA1 сертификата; Декодированная подпись с использованием открытого ключа CA и алгоритма шифрования. Удалите заполнение из декодированной подписи, результирующий хэш должен быть равен хешу SHA1 сертификата.

Однако я не могу получить два значения хеша, чтобыЯ пытался проверить свои предположения и результаты контроллера PIC, используя OpenSSL cомандная строка.

Это хеш-значение, которое я получил из командной строки OpenSSL и контроллера PIC

openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem -pubin
db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65

Это то, что я получил от проверки подписи с использованием OpenSSL.После удаления "ff" дополнений я получу хэш сертификата в формате asn1.

openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump
00 01 ff ff ff ff ff ff ff-ff ff ff ff 00 30 21 30
09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb
78 19 3c 0f fd 961c 4f-ed bd b2 34 45 60 bf 65

Однако это то, что я получил от контроллера PIC, который сильно отличается от описанного выше

8efb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c
9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43
b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22af b9 fb

Это моя подпись

7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4
0f66 db3a a3c1 a254 5be5 11d3 a691 63ef
0bf225ad 8881 9ed2 5230 bcd6

Это мой открытый ключ (я использую очень маленький ключ только для тестирования, увеличу его, когда все будет работать)

96FE CB 59 37 AE 8C9C 6C 7A 01 50 0F D6 4F B4
E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1
B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B
Экспонент 01 00 01

Мне интересно, не верны ли мои предположения, что я не могу использовать алгоритм шифрования для декодирования подписи?или я что-то не так делаю?

1 Ответ

1 голос
/ 17 ноября 2011

Оказалось, что метод, который я описал выше, является правильным.Мне удалось получить результат сопоставления путем хеширования сертификата и подписи подписи с использованием шифрования.

Проблема, которая вызвала мои предыдущие неудачные попытки, заключалась в том, что endianess использовался контроллером Microchip Pic.Они используют переменные с прямым порядком байтов, а не с прямым порядком байтов.Я не обращал внимания на порядковый номер степени, поскольку 01 00 01 одинаково в любом формате.Однако я был неправ, оказывается, Microchip рассматривает 4-байтовое значение как показатель степени (стандарт RSA ??).Таким образом, он набивает 00 спереди, получая 00 01 00 01 .Следовательно, порядок байтов теперь имеет значение, поскольку 00 01 00 01 отличается от 01 00 01 00 .И 01 00 01 00 - это формат с прямым порядком байтов, который использует Microchip Pic.

...