В чем разница между различными типами заполнения в iOS?

В iOS Сертификат, ключ и доверенные службы API содержит следующие типы заполнения:

  • kSecPaddingNone
  • kSecPaddingPKCS1
  • kSecPaddingPKCS1MD2
  • kSecPaddingPKCS1MD5
  • kSecPaddingPKCS1SHA1

Пользователь в списке рассылки Apple CDSA говорит, что "kSecPaddingPKCS1 [...] совпадает с PKCS # 1 1.5". В справочнике "Сертификат", "Ключ" и "Доверенные службы" аннотируются последние три типа заполнения (kSecPaddingPKCS1MD2, kSecPaddingPKCS1MD5 и kSecPaddingPKCS1SAH) с "Стандартным заполнением ASN.1", а также заполнением PKCS1 базовой операции RSA ".

  • В чем разница с kSecPaddingPKCS1?
  • Является ли kSecPaddingPKCS1 только исходное дополнение базовой операции RSA в соответствии с RFC 3447?
  • При подписании SHA-256, SHA-384 или SHA-512 дайджест с SecKeyRawSign(), нужно ли разработчику использовать kSecPaddingPKCS1 и выполнять прошивку ASN.1? Требуется ли заполнение ASN.1 или его можно опустить?

Любой намек, который указывает мне в правильном направлении, высоко ценится.

ОТВЕТЫ

Ответ 1

PKCS # 1 содержит два "paddings" для подписей с RSA, "новый" (называемый PSS, добавленный в версии 2.1) и "старый" (переименован "v1.5", поскольку он уже был в версии 1.5 PKCS # 1). Мы говорим о дополнении v1.5.

Когда некоторые данные подписаны, он сначала хэшируется с подходящей хеш-функцией (например, SHA-1), тогда хеш-значение (20 байтов при использовании SHA-1) завернуто в два последовательных слоя:

  • Хэш-значение кодируется в структуру на основе ASN.1, которая также указывает, какая хэш-функция была использована. На практике, если хеш-значение H, то первая упаковка приводит к последовательности байтов A || H, где "||" является конкатенацией, а "A" - это заголовок, который специфичен для хэш-функции (обычно от 15 до 20 байтов).

  • "A || H" расширяется с помощью дополнительных байтов:

0x00 0x01 0xFF 0xFF... 0xFF 0x00 || A || Н

Число байтов значения 0xFF настраивается так, чтобы общий размер равнялся размеру модуля RSA (т.е. 128 байтов для 1024-битного ключа RSA).

Второй шаг - это то, что PKCS # 1 вызывает "заполнение типа 1".

kSecPaddingPKCS1 означает, что функция выполняет только второй шаг: предполагается, что входные данные уже являются правильными "A || H". Обратите внимание, что SSL/TLS (до версии 1.1) использует вариант подписи, который требует этого режима (там нет "A" , но есть две функции хэш-функции). С помощью kSecPaddingPKCS1SHA1 функция подписи ожидает значение хэша в качестве входного сигнала и добавляет сам заголовок "A" .

Для правильной, совместимой с стандартами подписи, которая может быть проверена сторонними реализациями, заголовок "A" должен быть добавлен в какой-то момент. Вы можете добавить его самостоятельно и использовать kSecPaddingPKCS1, или использовать kSecPaddingPKCS1SHA1, и пусть двигатель добавит его сам, что, вероятно, менее подвержено ошибкам.

(По состоянию на 2011 год использование SHA-1 не рекомендуется, вам лучше переключиться на SHA-256 или SHA-512. Кроме того, API, который вы пытаетесь использовать, выглядит довольно низкоуровневым, и все подозрительно выглядит так, как будто вы привязываетесь к реализации собственного криптографического протокола вместо использования существующей библиотеки или фреймворка.)