在 exe 和 Service 之间交换安全数据
我有一个 Windows exe，它必须将一些安全数据写入 HKEY_LOCAL_MACHINE (HKLM)。我还有一个作为 NetworkService 帐户运行的服务，它必须读取该安全数据。请注意，exe 和服务以不同的用户身份运行。
这里的问题是保护数据。我尝试使用 CryptProtectData，但是问题是服务无法解密，因为数据未使用 NetworkService 帐户加密。我不想在调用 CryptProtectData 时使用 CRYPTPROTECT_LOCAL_MACHINE 标志，因为任何用户都可以解密它，从而本质上使其不安全。
我猜测这是一个常见的用例，但无法找到任何解决方案。有什么想法吗？
仅供参考，我正在使用 Visual C++ 编写 exe 和服务。
I have a windows exe which has to write some secure data to HKEY_LOCAL_MACHINE (HKLM). I also have a service running as NetworkService account which has to read that secure data. Note that exe and service run as different users.
Problem here is with securing the data. I tried with CryptProtectData, but the problem is that service cannot decrypt because the data was not encrypted using NetworkService account. I don't want to use CRYPTPROTECT_LOCAL_MACHINE flag while calling CryptProtectData as any user can decrypt it and essentially making it unsecure.
I am guessing that this is a common use case, but unable to find any solution. Any ideas please?
FYI, i am using visual C++ to write the exe and the service.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您尝试使用注册表作为进程间通信 (IPC) 机制，但您发现它不是很优雅。
对于您正在寻找的更好的架构是完全在服务内处理加密/解密，并使用真正 IPC 机制（TCP 套接字、邮槽等）从 EXE 传输数据到服务进行加密。
编辑：
除了加密之外，注册表听起来不像是存放这些数据的正确位置。戴上我的“系统管理员帽子”，我宁愿将您的数据放在文件系统中，而不是放在注册表中。使用注册表作为存储转发队列机制让我很兴奋。
就加密架构而言，我认为使用非对称加密最适合您。让 EXE 使用服务的公钥加密数据。该服务可以使用其私钥解密数据。
You're trying to use the registry as an inter-process communication (IPC) mechanism and you're finding that it's not very elegant.
A better architecture for what you're looking for would be to handle the encryption / decryption totally within the service and use a real IPC mechanism (TCP sockets, mailslot, etc) to transfer the data from the EXE to the service for encryption.
Edit:
The registry doesn't sound like the right place for this data, encryption aside. Putting on my "sysadmin hat" I'd much rather have your data in the filesytem than in the registry. Using the registry as a store-and-forward queue mechanism gives me the willies.
Insofar as cryptographic architecture I think you'd be best served using assymetric encryption. Let the EXE encrypt the data using the service's public key. The service can decrypt the data with its private key.