代码签名与加密 [英] Code Signing vs. Encryption

问题描述

因此，我正在寻求一些帮助，大部分是在理解代码签名和加密过程方面，因为我在这两个主题上仍然不满意。

So, I'm looking for some help, most with understanding the process of code-signing and encryption because I'm still shaky on both topics.

我想我理解的是：

• 首先需要使用加密算法（RSA）生成的密钥/ SHA1 / etc）


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


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


• 关于中间CA和更多证书的事情



• 然后，除了中间CA之外，还可以使用此证书 sign 文件，这样基本上就可以在文件上标上您的名字，收件人可以放心，这就是您希望他们收到的文件。

• First thing needed is a KEY, which is generated using some encryption algorithm (RSA/SHA1/etc)
• With this key we create a certificate signing request or CSR (something to do with X509?) which holds all of our information that will be on the certificate (Name, Location, Email, Domain)
• Both the KEY and the CSR get sent to the Root CA who then issues a certificate - in the form of a .pem or .p12 file (using the CSR and key for generation).
• Something about intermediate CAs and more certificates

• This cert can then be used in addition to the intermediate CAs to sign a file so that it basically has your name on it and recipients can be assured it's the what you intended them to receive.

对 ：

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

QUESTION: When I sign code using a certificate, does the payload also get encrypted? How is this different than SSL security for a website, ensuring the security and privacy of a connection? It seems like they all use the same technology to accomplish many different tasks.

推荐答案

在这里，我将逐点回答摘要/关于误解的注释：

I'll respond point by point here with some summary / notes about misconceptions later:

首先需要的是一个密钥，该密钥是使用某种加密算法（RSA / SHA1 / etc）生成的

First thing needed is a KEY, which is generated using some encryption algorithm (RSA/SHA1/etc)

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

Yes for the key being the start. Actually in case of signing it's a key pair - you're generating a public / private key pair. You keep the private part, everyone may know the public part. Small correction on algorithms - Sha1 is for hashing, not for encryption. So for certificates it's RSA/DSA/ECDSA normally.

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

With this key we create a certificate signing request or CSR (something to do with X509?) which holds all of our information that will be on the certificate (Name, Location, Email, Domain)

是，要获取典型的网站证书（x509标准），您需要签名请求/ CSR / PKCS＃11（相同）。

Yes, to get a typical website certificate (x509 standard) you need a signing request / CSR / PKCS#11 (same thing).

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

Both the KEY and the CSR get sent to the Root CA who then issues a certificate - in the form of a .pem or .p12 file (using the CSR and key for generation).

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

No, only the public part of the key (which is already included in the CSR) gets sent to the CA who issues a certificate. Nobody apart from you needs the private key.

关于中间CA和更多证书的事情

Something about intermediate CAs and more certificates

根CA不会对您的证书进行签名（出于与提高安全性和使其脱机有关的各种原因）。中级CA可以执行，并且由根CA签名。这意味着，如果要使用证书来保护访问浏览器的流量，则通常需要包括中间证书。您可以通过检查 https://www.ssllabs.com/ssltest/-它会告诉您链中是否缺少某些证书。

Root CAs don't sign your certificate (for various reasons related to better security and keeping them offline). Intermediate CAs do, and they're signed by the root CA. It means that if you want to use your certificate for protecting traffic to the browser, you need to include the intermediate certs usually. You can verify if everything is in place by checking on https://www.ssllabs.com/ssltest/ - it will tell you if some certificate is missing from the chain.

然后，除了中间CA之外，还可以使用此证书。在文件上签名，以便基本上在其上带有您的名字，收件人可以放心，这就是您希望他们收到的文件。

This cert can then be used in addition to the intermediate CAs to sign a file so that it basically has your name on it and recipients can be assured it's the what you intended them to receive.

是。它可以用于对文件（S / MIME格式）进行签名，但也可以用于协商安全的Internet连接。

Yes. It can be used to sign a file (S/MIME format), but it can be also used to negotiate a secure internet connection.

证书内部的公钥用于使用aes加密文件的内容，因此，在安装加密文件之前，必须将证书安装在目标位置。 （这似乎很安全，但不是人们想要的，人们无法读取或解码但仍具有功能的秘密代码）

The public key inside of the certificate is used to encrypt the contents of the file using aes and as a result the certificate must be installed on the destination before installing the encrypted file. (this seems secure but not what people would want, secret code that people can't read or decode but still has function)

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

What you describe is more like DRM. Only people who have the key are able to read the file, but that doesn't make a lot of sense from security point of view, because you need to give them the key in the first place. You can make the procedure more complex and confusing, but in the end they have to know the other part of the key.

即使在这种情况下，您也应该分发公钥，而不是私钥。您可以从私钥中生成公钥，但不能反过来。

Also, even in that case, you should distribute the public key, not private. You can generate your public key from your private key, but not the other way around.

我想您不能使文件完全加密，因为需要对其解码才能在目标上执行。我可以吗？

I guess it makes sense that you can't make the file entirely encrypted because it needs to be decoded to be executed on the target. Am I off on this?

您是对的。安全执行加密软件的唯一方法是，将执行引擎/密钥放在软件无法访问的范围内-例如嵌入在硬件中。对于纯软件解决方案，这是不现实的。

You're right. The only way you can securely execute encrypted software is if you keep the execution engine / key out of reach of software - for example embedded in hardware. This is not realistic for software-only solutions.

当我使用证书对代码签名时，有效载荷也会被加密吗？

When I sign code using a certificate, does the payload also get encrypted?

有效负载是什么意思？

• 应用程序发送的数据-不。需要明确完成


• 应用程序代码-否。它没有加密，签名唯一说的是拥有证书的人对代码进行了签名，之后就没有更改。更准确地说，是从应用程序二进制文件中计算出某种哈希，然后使用您的私钥对短哈希进行加密。分发您的应用程序时，每个人都可以使用您的公共密钥解密签名并将哈希与您提供的哈希进行比较。

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

How is this different than SSL security for a website, ensuring the security and privacy of a connection?

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

Completely different. TLS is about agreeing on a secret key you use for encryption of data in flight. Code signing is about proving that the code has not been modified and comes from the same entity you (possibly) trust.

所有人都使用相同的技术来完成许多不同的任务。

It seems like they all use the same technology to accomplish many different tasks.

是的。全部基于私钥/公钥对。它可以用于许多不同的目的。 X509证书实际上包括它们可以用于的用途的列表。列表为：

Yes. It's all based on private/public key pairs. It can be used for many different purposes. X509 certificates actually include a list of purposes they can be used for. The list is:

• TLS WWW服务器身份验证


• TLS WWW客户端身份验证


• 可下载的可执行代码签名


• 电子邮件保护


• 将对象的哈希值绑定到时间


• 签署OCSP响应

• TLS WWW server authentication
• TLS WWW client authentication
• Signing of downloadable executable code
• Email protection
• Binding the hash of an object to a time
• Signing OCSP responses

这篇关于代码签名与加密的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！