Совместимость Microsoft MSCAPI-CSP и CNG

Question

Ранее мы разработали RSA MSCAPI CSP для использования с классическим Windows Crypto API, и это работало отлично в течение многих лет. К сожалению, новые версии Outlook отказываются работать с этим CSP в случае шифрования AES. Он все еще поддерживает 3DES, но не AES. Это довольно странно, потому что на самом деле не CSP обрабатывает симметричное дешифрование, но, видимо, Microsoft не хочет поддерживать AES-случай для MS-CAPI. Для поддержки AES ключ RSA должен относиться к более новому типу провайдера, а именно к провайдеру хранилища ключей, соответствующему структуре CNG. Хорошо, хорошо, но вот в чем проблема: как я могу обеспечить обратную совместимость для клиентов, у которых есть программное обеспечение, основанное на интерфейсе MS-CAPI?
Насколько я понимаю (что может быть неправильно), хранилище сертификатов одинаково для MSCAPI и CNG. Разница заключается в том, как на закрытый ключ ссылаются. Сертификат имеет атрибут «CERT_KEY_PROV_INFO_PROP_ID», содержащий ряд полей, включая имя поставщика, имя контейнера и тип поставщика. Если тип провайдера равен «0» (что не было допустимым значением в старом API), это означает, что указанный провайдер фактически является одним из новых провайдеров CNG.

Старое приложение будет использовать значения из CERT_KEY_PROV_INFO_PROP_ID для получения криптографического контекста с использованием устаревших функций, то есть CryptAcquireContext (). Однако эта функция завершается с ошибкой в ​​случае провайдера CNG (то есть тип провайдера = 0) - здесь кажется, что программе придется использовать новые функции CNG, т.е. NCryptOpenStorageProvider, NCryptOpenKey и т. Д., Снова передавая значения из CERT_KEY_PROV_INFO_PROP_ID. Таким образом, если это понимание / тестирование правильное, это означает, что невозможно перейти к поставщику CNG и при этом иметь те же сертификаты / ключи, работающие с точки зрения устаревших прикладных программ. Я не смог найти это в явном виде в документации, но, похоже, каждая прикладная программа должна будет просматривать содержимое CERT_KEY_PROV_INFO_PROP_ID и иметь переключатель: если это тип провайдера = 0, это ключ в CNG провайдер, поэтому программа будет использовать новые функции CNG. С другой стороны, если тип провайдера> 0, программа должна использовать устаревшие функции. Но, конечно, унаследованная программа не будет иметь такой логики и, таким образом, потерпит неудачу в случае ключей в поставщиках CNG. Это означает, что невозможно удовлетворить потребности как новых, так и устаревших программ, потому что вы должны либо указать ссылку на старого поставщика, либо нового поставщика в CERT_KEY_PROV_INFO_PROP_ID, но вы не можете иметь и то, и другое. А Outlook хочет только ссылку на нового провайдера, а старые программы могут работать только со старыми провайдерами.

Но так ли это на самом деле, или я что-то упускаю, или какая-то ошибка в моем понимании? Похоже, что у Microsoft было бы несколько способов помочь программам иметь некоторый тип взаимодействия (например, чтобы старые программы могли использовать новые KSP с использованием старого API).

Answer 1

Насколько мне известно, нет решения, которое могло бы решить проблему точно так, как указано. НО новый API CNG предоставляет функцию NCryptTranslateHandle (), которую программа может использовать для преобразования ссылки старого стиля из CERT_KEY_PROV_INFO_PROP_ID в дескриптор соответствующего KSP. Когда KSP регистрируется сам, он может указать один или несколько «псевдонимов», то есть имен классических поставщиков MS-CAPI, для которых он является псевдонимами. Если программа затем вызывает дескриптор NCryptTranslateHandle () для дескриптора из классического CSP MS-CAPI, Windows посмотрит, есть ли установленный KSP, который зарегистрировал себя как псевдоним этого CSP. Если это так, дескриптор будет переведен в дескриптор для соответствующего CSP. Затем программа может продолжить работу и использовать новые функции CNG для этого дескриптора, что вызовет нового поставщика.

Так что же делать: 1) Сохраните ссылку CERT_KEY_PROV_INFO_PROP_ID в сертификате на то, чем она является сейчас (т.е. указывает на старый CSP), 2) Зарегистрируйте провайдера KSP, у которого старый CSP является псевдонимом (SDK в передо мной сейчас, но это один из параметров регистрации, который вы можете предоставить. Дайте мне знать, если вы не можете его найти!).

Что неудовлетворительно в этом, так это то, что все это опирается на вызывающую программу, вызывающую дескриптор NCryptTranslateHandle (). Старая унаследованная программа, написанная до появления CNG, очевидно, не будет вызывать эту функцию, поскольку функция не существовала на момент разработки. Но Microsoft Outlook (по крайней мере, более новые функции), который является очень распространенным вариантом использования, знает, как вызывать эту функцию. Поэтому, если вы предложите двойное решение CSP + KSP, как я описал в предыдущих параграфах, все будет хорошо: Outlook в конечном итоге вызовет ваше решение через API KSP из-за использования функций перевода.

При реализации решения вы должны написать программу для тестирования перед тестированием в Outlook. Позвольте программе получить дескриптор ключа старомодным способом, а затем используйте функцию перевода и увидите, что вы получите дескриптор, а затем используйте функции KSP для получающегося дескриптора.