自动代码签名-保护私钥 [英] Automated Code Signing - Protecting the private key
问题描述
我想自动化一些ClickOnce部署工件的代码签名-应用程序exe和清单.我正在使用 signtool 来完成此操作.为了使私钥可用于签名并保护包含私钥的证书文件(.pfx文件)，我的计划是使用不可导出的密钥将证书安装到本地计算机证书存储中. (我知道有一些方法可以导出密钥，即使将其标记为不可导出.)该计算机是连续集成服务器，只有少数服务器可以访问.我希望以某种方式进行设置，以便每当需要使用私钥时，都需要输入私钥密码.然后，我将设置一个自动化作业(使用 Jenkins )，该作业将需要一个构建参数来收集私钥密码. Mask Passwords插件将用于在输入密码和在控制台中掩盖密码输出.
I want to automate the code signing of some ClickOnce deployment artifacts - application exe's and manifests. I am using signtool to accomplish this. In an attempt to make the private key available for signing and yet protect the certificate file containing the private key (.pfx file), my plan is to install the certificate into the local machine certificate store with a non-exportable key. (I am aware that there are ways of exporting the key even if it is marked non-exportable.) The machine is a continuous integration server that will be accessible to a select few. My hope was to set it up in such a way that any time the private key needed to be used, it would require the private key password to be entered. I would then set up an automated job (using Jenkins) which would require a build parameter that would collect the private key password. The Mask Passwords plugin would be used to mask the password while being entered and in the console output.
但是，我遇到了一些障碍.首先，即使存在启用强私钥保护.如果启用此选项，则每次应用程序使用私钥时都会提示您".导入证书时，该证书仅在将其导入当前用户存储而不是本地计算机存储中时才可用.其次，即使此选项可用，signtool工具也不会提供使用商店中的证书进行签名时设置密码的选项.密码参数"/p"仅在将pfx文件用作私钥的源("/f"选项)时才适用.鉴于此，这似乎不是一个可行的选择.注意:即使启用强大的私钥保护".可用于机器存储中的证书，我的测试表明，尝试使用启用了此选项的证书只会弹出一个对话框，询问使用该证书的权限，这显然不适用于自动化作业.我本来以为提示"表示会要求输入密码.
However, I've run into a couple of roadblocks. First of all, even though there is the "Enable strong private key protection. You will be prompted every time the private key is used by an application if you enable this option." when importing a certificate, it appears to be only available when importing it into the current user store, not the local machine store. Secondly, even if this option were available, the signtool tool doesn't provide an option for setting the password when signing using a certificate in a store. The password parameter, '/p', is only applicable when using a pfx file as the source of the private key ('/f' option). Given that, this doesn't appear to be a viable option. Note: Even if "Enable strong private key protection." is available for certificates in the machine store, my testing shows that attempting to use a certificate with this option enabled just pops up a dialog asking for permission to use it, which obviously wouldn't work for an automated job. I originally thought "prompting" meant it would ask for the password.
我考虑过的另一个选择是创建ACL，以保护证书存储区中的私钥.可以通过右键单击证书并选择所有任务..."来完成. 管理私钥..."对话框.这会将私钥的使用限制为仅授权的人员. (注意:当没有私钥权限的用户尝试使用它进行签名时，他们会收到消息"SignTool错误:未找到满足所有给定条件的证书.")但是，我不想授予访问权限到Jenkins构建服务使用的凭据，因为这样任何构建作业都将能够对代码进行签名.我可以创建一个作业，该作业将执行脚本以特定用户身份运行签名命令.这将需要使用域用户名和密码作为构建参数.我可以使用Jenkins Mask Passwords插件执行此操作.不过，我真的不是很喜欢，因为我不认为Mask Passwords可以提供足够的保护以防止暴露域凭据，如果该凭据遭到破坏，则将提供比私钥更多的访问权限.
One other option I've considered is to create ACLs to secure the private key within a certificate store. This can be done by right clicking on the certificate and selecting All Tasks... | Manage Private Keys... dialog. This would restrict the private key usage to only those authorized. (Note: When a user without permissions on the private key attempts to use it for signing, they get the message "SignTool Error: No certificates were found that met all the given criteria.") However, I don't want to give access to the credentials being used by the Jenkins build service because then any build job would be able to sign code. I could create a job that would execute a script to run the signing command as a specific user. This would require taking the domain user name and password in as build parameters. I could do this using the Jenkins Mask Passwords plugin. I don't really like that, though, because I'm not comfortable that Mask Passwords is sufficient protection against exposing the domain credentials, which, if compromised, would give access to a lot more than just the private key.
如果我放弃了将证书存储在计算机存储中的最初想法，则可以选择将证书pfx文件放置在仅具有构建过程和签名用户权限的构建计算机上的ACL受保护的文件夹中.这样做可以使我创建一个构建作业，以使用包含的私钥，而不会将该文件暴露给有权访问该计算机的其他人.要使用私钥，构建参数将需要收集私钥密码.
If I abandon my original idea of storing the certificate in the machine store, there is the option of placing the certificate pfx file in an ACL secured folder on the build machine that only the build process and signing users have permissions on. Doing that would allow me to create a build job to use the contained private key while not exposing the file to others that have access to the machine. To use the private key, the build parameters would need to collect the private key password.
最后，可以选择使用智能卡来存储证书，但我们已决定不这样做.
Finally, there is the option of using a smart card for storing the certificate but we've decided against that.
所以，我的问题是，是否有其他方法可以做到这一点:1)保护私钥不被复制，2)防止未经授权的用户使用私钥对代码进行签名，以及3)给定私钥密钥密码是由授权用户提供的，是否使私钥通过构建服务进行签名?
So, my question is, are there any other ways to do this that 1) protects the private key from being copied, 2) prevents the private key from being used by unauthorized users to sign code and 3), given the private key password is provided by an authorized user, makes the private key for signing by build service?
推荐答案
首先，我将尝试分别回答您的问题:
First of all I will try to answer your questions separately:
- 保护私钥不被复制:
只有加密硬件(智能卡或hsm)才能真正保护密钥不被复制. Windows证书存储区(即使您正确地指出了带有不可导出选项的文件)或PKCS#12(PFX)文件也仅提供了错误的保护. - 防止私钥被未经授权的用户用来签署代码:
IMO，这需要用户交互，例如输入密码或PIN.如果您将密码作为参数传递，则总是有其他进程能够从密码，日志等中获取密码的可能性. - 鉴于私钥密码是由授权用户提供的，因此可以通过构建服务对私钥进行签名:
可以通过CSP(Windows证书存储区)访问加密硬件(智能卡或hsm) )使用交互式输入的PIN应该可以与signtool一起正常使用.
我同意，对于自动构建服务而言，用户交互的要求可能并不完全方便，但您可能必须在具有用户交互的安全解决方案与没有用户交互的安全性较低的解决方案之间进行选择.
I agree that the requirement of user interaction may not be exactly convenient for an automatic build service but you will probably have to choose between secure solution with user interaction and less secure solution without user interaction.
便捷但安全性较低的解决方案. 1 :在我看来，您已经找到了可以接受的解决方案，因为您没有提供任何缺点.
Convenient but less secure solution no. 1: It seems to me that you have already found an acceptable solution because you did not provide any of its disadvantages.
如果我放弃了将证书存储在计算机存储中的原始想法，则可以选择将证书pfx文件放置在仅具有构建过程和签名用户权限的构建计算机上的ACL受保护的文件夹中.这样做可以使我创建一个构建作业，以使用包含的私钥，而不会将该文件暴露给有权访问该计算机的其他人.要使用私钥，构建参数需要收集私钥密码.
If I abandon my original idea of storing the certificate in the machine store, there is the option of placing the certificate pfx file in an ACL secured folder on the build machine that only the build process and signing users have permissions on. Doing that would allow me to create a build job to use the contained private key while not exposing the file to others that have access to the machine. To use the private key, the build parameters would need to collect the private key password.
但是请注意，不仅可以从实时系统中而且还可以从备份中不可检测地复制PFX文件.
However please note that PFX file can be copied undetectably not only from the live system but also from the backups.
便捷但安全性较低的解决方案. 2 :将私钥存储在不需要输入PIN的智能卡上，并且仅允许受信任用户访问系统.这样可以确保您的私钥不能被复制，而signtool仍可以轻松访问它.但是，可能需要您有两台单独的构建服务器-一台没有所有用户都可以访问的智能卡，另一台只有受信任的用户可以访问的智能卡.
Convenient but less secure solution no. 2: Store private key on a smartcard that does not require PIN to be entered and allow system access only to the trusted users. This would ensure that your private key cannot be copied while it would remain easily accessible for signtool. However it would probably require you to have two separate build servers - one without the smartcard accessible to all users and one with the smartcard accessible only to the trusted users.
不方便的安全解决方案:在构建过程中需要输入PIN并需要用户交互(输入PIN)的智能卡上存储私钥.
Inconvenient secure solution: Store private key on a smartcard that requires PIN to be entered and require user interaction (entering of the PIN) during the build process.
您还可以考虑在自动模式下使用自签名代码签名证书对开发版本进行签名，并在手动模式下使用受信任的代码签名证书对公共发行版本进行签名.
You could also consider signing development builds with self-signed codesigning certificate in an automatic mode and signing public release builds with trusted codesigning certificate in manual mode.
这篇关于自动代码签名-保护私钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
