代码签名与加密答案

【问题标题】：Code Signing vs. Encryption代码签名与加密
【发布时间】：2015-12-13 16:54:13
【问题描述】：

所以，我正在寻求一些帮助，主要是了解代码签名和加密的过程，因为我在这两个主题上仍然摇摆不定。

我认为我理解的：

首先需要一个 KEY，它是使用某种加密算法 (RSA/SHA1/etc) 生成的
使用此密钥，我们创建一个证书签名请求或 CSR（与 X509 相关？），其中包含我们将在证书上的所有信息（名称、位置、电子邮件、域）
KEY 和 CSR 都被发送到根 CA，然后根 CA 以 .pem 或 .p12 文件的形式（使用 CSR 和密钥生成）颁发证书。
关于中间 CA 和更多证书的信息
除了中间 CA 之外，还可以使用此证书签署一个文件，这样文件上基本上就有您的姓名，并且收件人可以确信这是您希望他们收到的内容。

对比：
与获得证书的过程相同
证书内的公钥用于使用 aes 加密文件的内容，因此在安装加密文件之前必须在目标上安装证书。（这看起来很安全，但不是人们想要的，人们无法阅读或解码但仍然具有功能的密码）
我想你不能使文件完全加密是有道理的，因为它需要被解码才能在目标上执行。我不介意了吗？

问题：当我使用证书签署代码时，有效负载是否也会被加密？这与网站的 SSL 安全性有何不同，确保连接的安全性和隐私性？似乎他们都使用相同的技术来完成许多不同的任务。

【问题讨论】：

正常的 SSL/TLS 连接不使用签名（除了可选的 MAC），而只使用不同形式的加密。代码签名是仅不加密的签名。 RSA 可用于加密和签名，但其他大多数都不能。
@ArtjomB。那么获取 SSL 连接证书的整个过程是如何工作的呢？您颁发了证书，这意味着您可以“受信任”，因此启动了 TLS 连接？

标签： security ssl encryption certificate code-signing

【解决方案1】：

稍后我将在这里逐点回复一些关于误解的摘要/注释：

首先需要一个 KEY，它是使用某种加密算法 (RSA/SHA1/etc) 生成的

是的，关键是开始。实际上，在签名的情况下，它是一个密钥对 - 您正在生成一个公钥/私钥对。你保留私人部分，每个人都可能知道公共部分。对算法的小修正 - Sha1 用于散列，而不是用于加密。所以对于证书，它通常是 RSA/DSA/ECDSA。

使用此密钥，我们创建一个证书签名请求或 CSR（与 X509 有关？），其中包含我们将在证书上的所有信息（名称、位置、电子邮件、域）

是的，要获得典型的网站证书（x509 标准），您需要签名请求/CSR/PKCS#11（同样的事情）。

KEY 和 CSR 都被发送到根 CA，然后根 CA 以 .pem 或 .p12 文件的形式颁发证书（使用 CSR 和密钥生成）。

不，只有密钥的公共部分（已包含在 CSR 中）被发送给颁发证书的 CA。除了你之外，没有人需要私钥。

关于中间 CA 和更多证书

根 CA 不会签署您的证书（出于与更好的安全性和保持离线相关的各种原因）。中间 CA 会这样做，并且它们由根 CA 签名。这意味着如果你想使用你的证书来保护浏览器的流量，你通常需要包含中间证书。您可以通过检查 https://www.ssllabs.com/ssltest/ 来验证是否一切就绪 - 它会告诉您链中是否缺少某些证书。

除了中间 CA 之外，此证书还可以用于签署文件，这样文件上基本上就有您的姓名，并且收件人可以确信这是您希望他们收到的内容。

是的。它可用于签署文件（S/MIME 格式），但也可用于协商安全的互联网连接。

证书内的公钥用于使用 aes 加密文件的内容，因此必须在安装加密文件之前将证书安装在目标上。（这看起来很安全，但不是人们想要的，人们无法阅读或解码但仍有功能的密码）

您所描述的更像是 DRM。只有拥有密钥的人才能读取文件，但从安全的角度来看，这没有多大意义，因为您首先需要给他们密钥。你可以让程序变得更复杂和混乱，但最终他们必须知道密钥的另一部分。

此外，即使在这种情况下，您也应该分发公钥，而不是私钥。您可以从您的私钥生成您的公钥，但反之则不行。

我想你不能使文件完全加密是有道理的，因为它需要被解码才能在目标上执行。我不介意了吗？

你是对的。您可以安全地执行加密软件的唯一方法是将执行引擎/密钥放在软件无法触及的地方 - 例如嵌入硬件中。这对于纯软件解决方案是不现实的。

当我使用证书签署代码时，有效负载是否也会被加密？

有效载荷是什么意思？

应用程序发送的数据 - 没有。这需要明确地完成
应用程序代码 - 没有。它没有加密，签名唯一说的是拥有证书的人签署了代码并且之后没有更改。或者更准确地说，某种哈希值是从应用程序二进制文件中计算出来的，并且这个短哈希值是用你的私钥加密的。当您分发您的应用时，每个人都可以使用您的公钥解密签名并将哈希值与您提供的哈希值进行比较。

这与网站的 SSL 安全性有何不同，确保连接的安全性和隐私性？

完全不同。 TLS 是关于就用于加密传输中的数据的密钥达成一致。代码签名是为了证明代码未被修改并且来自您（可能）信任的同一实体。

似乎他们都使用相同的技术来完成许多不同的任务。

是的。这一切都基于私钥/公钥对。它可以用于许多不同的目的。 X509 证书实际上包括它们可以用于的目的列表。名单是：

TLS WWW 服务器身份验证
TLS WWW 客户端身份验证
签署可下载的可执行代码
电子邮件保护
将对象的哈希值绑定到时间
签署 OCSP 响应

【讨论】：

所以当我签署一个我希望我的最终用户执行的文件时，如果它是一个自签名证书（我认为这意味着我创建了一个根证书，然后是一个中间证书来签署代码) 这未验证，因为系统尚未清除 rootCA，但已清除 Verisign/COMODO 证书签名文件，因此它显示为已验证？
这取决于用户信任谁。如果您将软件分发给“互联网上的随机人”，那么是的，没错。但是，如果您创建的应用程序仅在本地办公室分发（例如），您可以确保您的代码签名证书已安装在所有用户计算机上，并且它变得与 Verisign 一样“有效”。
啊，所以每个版本的证书的过程或质量没有本质上的不同，只是谁在信任链中，谁不在（如果机器上安装了根证书）
这是一个哲学问题 :) 我会说是的，总的来说是这样。除非您比自己更信任威瑞信。（我会，因为我不认识你；但你可能不会）但从技术上讲，证书本身没有区别。只要您使用足够大的键，它们也一样好。