Microsoft MSCAPI-CSP与CNG的兼容性

我们以前开发了一个RSA MSCAPI CSP，用于经典的Windows crypto API，多年来一直运行良好。不幸的是，在AES加密的情况下，较新版本的Outlook拒绝使用此CSP。它仍然支持3DES，但不支持AES。这很奇怪，因为实际上处理对称解密的不是CSP，但显然微软不想支持MS-CAPI的AES案例。对于AES支持，RSA密钥需要采用更新的提供程序类型，即符合CNG框架的密钥存储提供程序。 好吧，但问题是：对于拥有依赖MS-CAPI接口的软件的客户端，如何确保向后兼容性？
根据我的理解（这可能是错误的），MSCAPI和CNG的证书存储是相同的。区别在于如何引用私钥。证书具有一个属性“CERT\u KEY\u PROV\u INFO\u PROP\u 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内容，并有一个开关：如果它是provider type=0，这是CNG provider中的一个键，因此程序将使用新的CNG功能。另一方面，如果提供程序类型>0，则程序应使用遗留函数。但当然，遗留程序不会有这种逻辑，因此在CNG提供商中的密钥的情况下会失败。这意味着不可能同时满足新程序和旧程序的需求，因为您必须在CERT\u KEY\u PROV\u INFO\u PROP\u ID中输入对旧程序提供程序的引用或新提供程序的引用，但您不能同时拥有这两种程序。Outlook只希望引用新的提供者，而旧程序只能与旧提供者一起使用

---

但这真的是真的吗？还是我的理解中有什么遗漏或错误？微软似乎有多种方法可以帮助程序实现某种类型的互操作性（例如，旧程序可以使用新的KSP，使用旧的API）。

据我所知，没有任何解决方案可以完全解决上述问题。但新的CNG API提供了一个函数NCryptTranslateHandle（），程序可以使用该函数将旧式引用从CERT_KEY_PROV_INFO_PROP_ID转换为相应KSP的句柄。当KSP注册自身时，它可以指定一个或多个“别名”，即它是经典MS-CAPI提供者别名的名称。如果程序随后调用经典MS-CAPI CSP句柄上的NCryptTranslateHandle（）句柄，Windows将查看是否有已安装的KSP已注册为该CSP的别名。如果是这样，句柄将被转换为相应CSP的句柄。然后，程序可以继续并在该句柄上使用新的CNG函数，该句柄将调用新的提供者

那么该怎么做：1）在证书中保留CERT\u KEY\u PROV\u INFO\u PROP\u ID引用（即指向旧CSP），2）注册一个以旧CSP为别名的KSP提供商（现在我面前没有SDK，但它是您可以提供的注册参数之一。如果找不到，请告诉我！）

对此有点不满意的是，它完全依赖于调用NCryptTranslateHandle（）句柄的调用程序。在CNG出现之前编写的一个旧的遗留程序显然不会调用此函数，因为该函数在开发时并不存在。但是Microsoft Outlook（至少是更新的函数）——这是一个非常常见的用例——确实知道如何调用此函数。因此，如果您提供了一个双CSP+KSP解决方案，正如我在前面几段中所描述的那样，它将正常工作：由于使用了translate函数，Outlook最终将通过KSP API调用您的解决方案

---

在实施解决方案时，您应该在使用Outlook进行测试之前编写一个程序对其进行测试。让程序以老式的方式获得键的句柄，然后使用转换函数，查看您是否获得了句柄，然后在生成的句柄上使用KSP函数。

您解决了这个问题吗？我们也有这个问题Hi TaLz，很抱歉我忘了写信和回答。现在将这样做…请参阅补充答案