macOS下RSA.Decrypt()偶现CSSMERR_CSP_OPERATION_AUTH_DENIED权限错误

核心原因 #

1. KeyChain ACL顺序敏感性：Apple KeyChain的权限校验逻辑对ACL条目顺序存在隐性依赖，BouncyCastle 1.9.6在自动生成并写入ACL条目时，未保证条目的固定排序，导致重启进程后，权限匹配逻辑无法正确识别当前进程的访问权限，抛出CSSMERR_CSP_OPERATION_AUTH_DENIED。
2. 重复哈希条目干扰：私钥ACL中存在重复的哈希条目，会导致KeyChain的权限解析逻辑出现歧义，触发间歇性验证失败——缓存机制或匹配算法在处理重复条目时可能出现不稳定的匹配结果，表现为时而正常时而报错。
3. .NET Core AppleCrypto层的严格校验：.NET Core的AppleCrypto互操作层对KeyChain权限的校验比原生Objective-C代码更严格，进程重启后PID变化，原有自动生成的ACL条目因为顺序问题无法通过校验。

可行解决方案 #

• 显式控制ACL条目顺序：在使用BouncyCastle创建私钥并写入KeyChain时，不要依赖默认的ACL生成逻辑，手动构造ACL条目列表，将当前应用的权限条目放在首位，确保每次写入的条目顺序完全一致。
• 清理重复ACL哈希项：完成私钥写入后，通过KeyChain Access工具或代码检查私钥的ACL配置，移除重复的哈希条目，保证每个ACL条目唯一且无冗余。
• 替换为原生Apple Security API：绕过BouncyCastle的KeyChain封装，通过P/Invoke直接调用Apple的SecItemAdd、SecAccessCreate等原生API，精确配置私钥的访问控制列表，避免第三方库带来的条目顺序或格式问题。
• 绑定Bundle ID而非PID：在配置ACL时，直接指定应用的Bundle ID作为允许访问的对象，而非依赖自动检测的进程ID，这样即使进程重启，权限匹配仍能准确生效，消除间歇性问题。

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