基于C#/.NET开发Cryptographic Service Provider相关问题咨询

三点认知准确性验证 #

你的三个认知大部分符合实际情况，具体说明如下：

• CSP是一项legacy技术：该认知完全正确。CSP是Windows NT时期推出的初代加密服务架构，微软自Windows Vista/Server 2008起就已经推出CNG（Cryptography Next Generation）作为下一代加密架构替代CSP，目前CSP已被官方列为弃用技术，仅保留兼容支持，不会再有功能更新。
• 自定义CSP需要使用C++开发：该认知完全正确。CSP的接口是原生Win32风格的底层接口，要求DLL导出符合规范的原生C入口函数，运行在系统高权限信任上下文，不支持托管运行时加载，因此只能使用C/C++开发，无法直接用托管语言实现。
• 自定义CSP的dll需要经过微软签名：该认知部分正确，分场景判定。如果CSP仅用于普通用户态业务应用调用，只需要在目标机器上注册对应注册表项、将CSP加入系统CSP列表即可使用，无需微软签名；如果需要用于内核级场景（如BitLocker、系统启动加密、驱动调用）或需要通过Windows徽标认证，则必须提交微软完成WHQL签名，部分高安全级别的智能卡类CSP也要求微软签名才能正常调用。

能否使用C#/.NET开发自定义CSP？ #

完全不可以，原因如下：

• CSP要求DLL导出原生非托管函数入口，C#/.NET生成的托管程序集默认无法导出符合CSP接口规范的原生函数，即使使用C++/CLI混合开发，也会因为托管运行时的加载依赖、安全上下文限制，无法在CSP要求的运行环境中正常工作，微软官方从未提供托管语言开发CSP的支持方案。
• 部分CSP调用场景发生在进程启动早期、甚至CLR运行环境尚未加载的阶段，托管代码完全无法在这类环境中运行。

2021年开发自定义CSP是否属于合理技术选型？ #

仅在唯一强制约束场景下属于合理选择，否则极不推荐：

• 唯一合理场景：你使用的第三方文档管理系统仅支持通过CSP扩展签名/验签能力，无任何其他扩展路径（如插件体系、自定义加密接口、CNG支持等），且你无法替换该系统，此时只能开发自定义CSP满足需求。
• 其他所有场景均不合理：CSP本身已停止迭代，随着Windows版本更新兼容性会持续下降，同时开发门槛高、调试难度大，优先选择推动第三方系统支持CNG，或者在业务层直接对接远程加密服务完成签名验签，绕开CSP开发。

是否有C#开发自定义CSP的分步教程？ #

不存在相关教程。因为C#/.NET本身不支持开发CSP，所有正规的CSP开发教程均基于C++和Cryptographic Provider Development Kit实现。

内容的提问来源于stack exchange，提问作者user3125174