标签: authenticode

例如,在这里阅读了.NET中的强名称后,我有以下问题:

我们有一个Authenticode代码签名证书,我们用它来签署所有EXE,DLL和MSI文件.这样做的好处是,Windows知道MSI来自可靠的来源,并且如果需要,还可以验证每个文件的真实性.

我们目前不使用.NET强名称.我已经读过,强命名文件本质上意味着它使用自签名证书进行数字签名.我对此的看法是,由受信任的证书颁发机构签名的Authenticode证书比自签名证书更有价值,该证书的真实性无论如何都无法验证,因为它们缺少根证书(我们不打算将其分发给最终用户,是我们!？).

问题:如果已使用Authenticode签名,是否还有其他强命名程序集的值？

有许多站点可以解释如何signtool.exe在.pfx证书文件上运行,该文件归结为:

signtool.exe sign /f mycert.pfx /p mypassword /t http://timestamp.server.com \
  /d "My description"   file1.exe file2.exe

我有一个持续集成的CI流程设置(使用TeamCity),它像大多数CI流程一样,完成所有工作:检查源代码,编译,签署所有.exes,将软件包签入安装程序,然后签署安装程序.exe.目前有3个构建代理程序,运行相同的VM,其中任何一个都可以运行此过程.

不安全的实施

为了实现这一目标,就安全性而言,我做了一些Bad Things(TM):.pfx文件在源代码管理中,并且它的密码在构建脚本中(也在源代码管理中).这意味着任何能够访问源代码存储库的开发人员都可以获取pfx文件并执行他们喜欢的任何恶意内容.(我们是一个相对较小的开发商店,相信每个人都可以访问,但显然这仍然不好).

最终的安全实施

我能找到"正确"做到这一点,就是你:

• 将pfx和密码保存在某些安全介质上(如带有手指解锁的加密USB驱动器),可能不在一起
• 仅指定几个人可以访问签名文件
• 只签署一个非连接的专用机器上的最终版本,该机器保存在一个锁定的保险库中,直到您需要将其带出来进行此代码签名仪式.

虽然我可以看到这个安全性的优点..这是一个非常繁重的过程,并且在时间方面很昂贵(运行此过程,安全地保留证书备份,确保代码签名机器处于工作状态等) ).

我确信有些人会跳过步骤,只需手动签署存储在他们个人系统上的证书的文件,但这仍然不是很好.

它也与安装程序中使用的签名文件(也由构建服务器构建)不兼容 - 当您安装了具有UAC提示以获得管理员访问权限的.exe时,这一点很重要.

中间地带？

我更关心的是没有向用户提供可怕的"不受信任的应用程序"UAC提示,而不是证明它是我的公司.同时,将私钥和密码存储在每个开发人员(以及QA和高级技术支持)都可以访问的源代码存储库中显然不是一个好的安全实践.

我想要的是CI服务器在构建过程中仍然像今天一样签名,但没有密码(或证书的私钥部分)可供访问源代码存储库的每个人访问.

有没有办法将密码保留在构建之外或以某种方式保护？我应该告诉signtool使用证书存储区(我如何使用3个构建代理程序和构建作为非交互式用户帐户运行)？别的什么？

我正在为安装程序DLL编写一个函数来验证已安装在系统上的EXE文件的Authenticode签名.

该功能需要:

A)验证签名是否有效.
B)验证签名者是我们的组织.

因为这是在安装程序,因为这需要运行在旧的Win2k设施,我不想要依靠的CAPICOM.dll,因为它可能不是在目标系统上.

该的WinVerifyTrust API的伟大工程,以解决(A).

我需要找到一种方法来比较已知证书(或其中的属性)与签署有问题的EXE的证书.

我正在尝试编写从DLL或EXE读取签名(证书)的代码.大多数DLL或EXE只有一个签名,我的代码正确读取与此签名关联的所有证书.更具体地说,它读取签名证书,它是发行者(不是root),签名证书(带有时间戳)和它的发行者(不是root).我有2个C++和C#示例程序,它们都返回相同的证书.这是C#代码,C++是100倍长:)

static void Main(string[] args)
{
    X509Certificate2Collection collection = new X509Certificate2Collection();
    collection.Import(args[0]);
}

但是有一些DLL有2个签名,如文件属性/数字签名所示,例如C:\ Program Files(x86)\ Microsoft SQL Server\80\Tools\Binn\msvcr71.dll:

对于此DLL,我的代码只读取与第一个签名关联的证书.

我也尝试使用signtool,它返回与我的代码相同的信息:first cert(带有它的路径)和counterignature(带有它的路径).但最后还要注意错误.

C:\Windows>signtool verify /d /v "C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\msvcr71.dll"

Verifying: C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\msvcr71.dll
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 33BBCCF6326276B413A1ECED1BF7842A6D1DDA07

Signing Certificate Chain:
Issued to: Microsoft Root Certificate Authority
Issued by: Microsoft Root Certificate Authority
Expires:   Sun May 09 19:28:13 2021
SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072

    Issued to: Microsoft Code Signing PCA
    Issued by: Microsoft …

我最近从globalsign购买了authenticode证书,但在部署文件时遇到问题.有一些.exe文件由项目生成,然后放入.msi.当我使用signtool签署.exe文件时,证书有效并且运行正常.问题是,当我构建.msi(使用visual studio安装项目)时,.exe文件会丢失其签名.所以我可以在构建后签署.msi,但安装的.exe文件继续整个"未知的发布者"业务.如何在这些文件上保留签名以便在客户端计算机上安装？

在我的C#/ .NET应用程序中,我必须检查给定的可执行文件是否经过数字签名 (最好不Exception进行测试).

然后我需要检查其证书是否有效 (基于已安装的根证书)以及文件内容是否对签名有效.

这里有很多课程BCL,我不知道从哪里开始和使用什么,到目前为止我发现的任何东西并没有消除我的困惑......

如果没有 P/Invoke可能,我想做这样的事情:

bool IsSignedFile(string path);  
Cert GetCertificateFromSignedFile(string path);
bool IsValidCertificate(Cert cert)
Sig GetSignatureFromSignedFile(string path);
bool IsValidSignature(string path, Sig sig, Cert cert);  

补充说明:

我目前遇到的一个大问题是,我找不到一种方法来轻松获取此类文件的签名.仍然希望有一个提供的,可管理的BCL解决方案,因为如果缺少这一部分,我会感到惊讶.(对于证书,这可以通过公正的方式完成,也可以进行X509Certificate.CreateFromSignedFile验证)
我不希望将50%的工作与P/Invoke代码或大型不同的库混合使用.

我找到了一个AuthenticodeSignatureInformation类,但没有关于为给定的可执行文件使用它的信息.

我有两个代码签名证书(一个SHA-1,一个SHA-256),我想将它们应用于同一个文件.我试图附加SHA-256证书,但这失败了:

:: Signs with the SHA-1 certificate
signtool sign /sha1 8f52fa9db30525dfabb35b08bd1966693a30eccf /t http://timestamp.verisign.com/scripts/timestamp.dll my_app_here.exe
:: Signs with the SHA-2 certificate
signtool sign /sha1 8b0026ecbe5bf245993b26e164f02e1313579e47 /as /t http://timestamp.verisign.com/scripts/timestamp.dll my_app_here.exe

这失败并出现错误:

Done Adding Additional Store
SignTool Error: SignedCode::Sign returned error: 0x80070057
        The parameter is incorrect.
SignTool Error: An error occurred while attempting to sign: my_app_here.exe

如果从第二个命令中删除时间戳URL,则签名成功完成,但SHA-2签名没有时间戳.(我是否在第一个签名上加上时间戳没有效果)

这里的目的是允许某人使用更强大的证书验证应用程序,如果他们在支持此功能的操作系统上,但是为了避免在不支持更强版本的操作系统(Vista,XP)上验证失败.

这种事情甚至可能吗？

我正在实现自动更新功能,并需要一些有关如何使用最佳实践安全地执行此操作的建议.我想使用下载文件的Authenticode签名来验证它是否可以安全运行(即来自我们公司并且没有被篡改).我的问题与问题#2008519非常相似.

最底线的问题:检查自动更新功能的Authenticode签名的最佳,最安全的方法是什么？应检查证书中的哪些字段？要求是:(1)检查签名是否有效,(2)检查签名是否有效,(3)旧客户仍然可以在我的证书到期时更新,我得到一个新签名.

以下是我研究的一些背景信息/想法:我相信这可以分为两个步骤:

1. 验证签名是否有效.我相信这应该很容易使用WinVerifyTrust,如http://msdn.microsoft.com/en-us/library/aa382384(VS.85).aspx中所述 - 我不认为这里有问题.

2. 验证签名是否与我们公司相对应,而不是其他公司.这似乎是一个更难回答的问题:

一种可能性是检查签名中的一些字符串.可以通过MS KB文章#323809的代码获得,但是本文不会就应该为这种类型的应用程序(或任何其他类似的)检查哪些字段提出建议. 问题#1072540还说明了如何获取某些证书信息,但同样不建议实际检查哪些字段.我担心的是字符串可能不是最好的检查:例如,如果另一个人能够获得具有相同名称的证书,该怎么办？或者,如果我们有正当理由在将来更改字符串？

有问题的人#2008519有一个非常相似的要求.他对"TrustedByUs"功能的需求与我的相同.但是,他通过比较公钥来进行检查.虽然这可以在短期内起作用,但似乎它不适用于自动更新功能.这是因为代码签名证书最长有效期为2 - 3年.因此,在将来,当我们在2年内购买新证书时,由于公钥的更改,旧客户将无法再更新.

我有一个C++ Windows应用程序.我签署了我们的安装程序和我的可执行文件,但我目前没有签署我的DLL(例如zlib1.dll).签署这些并不是什么大不了的事,但有人可以解释一下这样做的好处吗？例如,如果所有依赖项都已签名,我的程序是否会与AV或防火墙软件有任何不同？用户会得到任何不同的警告吗？

我最近考虑获得一个authenticode签名密钥,并对它们的价格感到震惊.这让我想到 - 大多数类型的签名密钥,无论是Authenticode,SSL等 - 都非常昂贵.

是否有技术上的原因使得维护CA和生成密钥变得昂贵,或者这归结为简单的垄断经济学？