跨平台.NET5应用在Linux端如何安全存储仅当前用户可访问的对称密钥

匹配核心需求的最高优先级方案 #

完全对标Windows上DPAPI的用户级隔离逻辑，依托Linux原生能力实现，不需要跨平台统一适配：

• 基于Linux文件权限模型的用户专属目录隔离
  把加密密钥文件存放到当前运行用户的家目录下的应用专属隐藏路径，比如~/.config/[你的应用唯一标识]/smtp_secret.key，创建文件时直接将Unix权限设置为0600——即仅文件属主（运行应用的当前用户）拥有读、写权限，同组用户、系统内其他所有用户完全没有访问权限。
  .NET 5 可直接通过内置API完成权限设置，无需引入第三方依赖：创建文件后调用File.SetUnixFileMode将文件模式配置为UnixFileMode.UserRead | UnixFileMode.UserWrite，移除所有组、其他用户的读、写、执行权限即可。
  这种方式的隔离效果和Windows DPAPI的用户级加密完全一致：Linux内核会在系统调用层直接拦截非属主的访问请求，就算同主机的其他普通用户拿到了文件的绝对路径，也无法读取文件内容。
  注意：绝对不要把密钥文件放到全局可写、权限宽松的系统路径下，比如/tmp、全局共享的/var目录，这类路径下的文件本身就对所有用户开放，权限隔离完全失效。

可选的加固增强方案 #

• 对接Linux系统原生的用户级密钥管理服务
  桌面环境下可直接对接GNOME Keyring、KDE Wallet：这类服务的设计逻辑就是将用户敏感凭据加密存储，加密密钥基于用户登录密码派生，只有用户登录解锁本地会话后才能读取，完全满足“仅依托应用运行的用户账户可读取”的要求。服务器无GUI场景下，可直接调用libsecret的无界面运行模式完成对接，不需要依赖桌面交互组件。
  对接时只需要通过P/Invoke调用系统原生的密钥读写接口即可，不需要引入额外的加密类库，和已有的.NET 5 内置对称加密逻辑完全不冲突。
• 加密密钥的上下文派生加固
  如果不想依赖系统密钥链组件，可在0600权限的专属文件存储基础上，将加密密钥的派生输入和当前用户的系统上下文绑定：比如结合用户UID、家目录真实路径、用户登录会话标识这类其他普通用户无法篡改的系统信息，通过.NET内置的PBKDF2算法派生加密密钥，就算出现权限配置失误导致密文泄露，没有当前用户的运行上下文也无法解密拿到明文密钥。

落地注意事项 #

• 不需要为了跨平台统一强行找兼容方案：已有的运行时平台判断逻辑可以直接复用，Windows分支走DPAPI，Linux分支走上述用户级隔离逻辑即可，额外的跨平台适配只会引入不必要的依赖和安全风险。
• 不要把加密密钥的派生输入硬编码到应用二进制中：硬编码的密钥会让权限隔离完全失效，只要有人反编译拿到硬编码值，就能直接绕过权限读取解密后的密钥内容。
• 注意收敛应用的运行权限：如果应用以root权限运行，存储的密钥文件属主会变成root，普通用户虽然还是读不到，但一旦应用存在命令执行漏洞，密钥就会直接暴露，建议应用始终以普通用户身份运行。

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