tpm 证书_在Windows上创建tpm支持的证书

tpm 证书

I’ve started experimenting with exposing some of my home lab services to the world without needing a VPN. Instead, I use Caddy (which is an excellent web server, and much easier to work with than Nginx) as a reverse proxy with TLS client certificates for authentication. Caddy’s built-in Let’s Encrypt functionality provides the server certificate, and my internal PKI provides the client certificates. I still want to have 2-factor authentication, though — a certificate is merely “something you have”, and I want to require “something you know,” too. Since all my PCs are recent enough to feature a TPM, I decided to store the keys on said TPM and configure it to require a password before allowing any authentication to take place. I was inspired by Microsoft Hello for Business — which is really cool and I can’t wait to work with it some day — but using the TPM directly is much lighter weight as no domain controller or Windows AD Domain is needed. The previous iteration of Microsoft’s “Passwordless Future,” TPM-backed virtual smart cards would be exactly what I want, except the docs come with a big ol’ deprecation warning. Instead, I found how to interact with the base TPM crypto provider to generate certificates.

我已经开始尝试在不使用VPN的情况下将我的一些家庭实验室服务暴露给全世界。 相反，我使用Caddy (这是一台出色的 Web服务器，并且比Nginx更容易使用)作为带有TLS客户端证书进行身份验证的反向代理。 Caddy的内置“让我们加密”功能提供服务器证书，而我的内部PKI提供客户端证书。 不过，我仍然想进行两要素身份验证-证书只是“您拥有的东西”，我也想要求“您知道的东西”。 由于我的所有PC都足够新，可以使用TPM，因此我决定将密钥存储在TPM上，并配置它以要求输入密码，然后再进行任何身份验证。 我受到Microsoft Hello for Business的启发-确实很棒，我迫不及待地想使用它-但是直接使用TPM的重量要轻得多，因为不需要域控制器或Windows AD域。 TPM支持的虚拟智能卡是Microsoft的“ Passwordless Future”的上一版，正是我所需要的，除了文档带有很大的弃用警告。 相反，我发现了如何与基本TPM加密提供程序进行交互以生成证书。

为什么使用TPM支持的证书？ (Why use TPM-backed certificates?)

Normally when you generate a certificate, the full certificate and private key are stored in your user certificate store. This is encrypted with your log-in password, and you can mark certificates as non-exportable. However, anyone that is able to execute code as your user (e.g., malware), or gains administrative access to the computer can bypass that restriction and steal the certificate and key. Disk encryption (which you should be using) will protect against some ways of doing this, but not all of them. Also, the default certificate store’s encryption can be attacked offline, which means anyone with a large AWS budget can probably get into it.

通常，当您生成证书时，完整的证书和私钥会存储在用户证书存储中。 这是用您的登录密码加密的，您可以将证书标记为不可导出。 但是，任何能够以您的用户身份执行代码(例如，恶意软件)或获得对计算机的管理访问权限的人都可以绕过该限制并窃取证书和密钥。 磁盘加密( 应使用的磁盘加密)可以防止某些方式执行此操作，但不是全部。 此外，默认证书存储的加密可以脱机攻击，这意味着任何拥有大量AWS预算的人都可以进入其中。

By generating the key in the TPM, we solve all of those issues. The TPM stores the key material and does all the cryptographic operations on itself, so the key cannot be stolen. When you supply a password at generation (which is optional but recommended), the TPM also requires that password before performing any operations, providing a second layer of protection. This forms the second factor of 2FA if done properly. The TPM has physical protections in-place to prevent attackers from gaining access to its data through side channels or chip decapping, and it has anti-hammering protections to prevent password brute-forcing. Taken together, this is probably the strongest form of key protection (and therefore, authentication) the average user has access to short of a physical crypto dongle like a Yubikey. Since every relatively recent Intel/AMD processor has a firmware TPM and Microsoft requires some kind of TPM in new Windows machines, you probably have one already! There really isn’t a reason not to use this method of storing keys unless you need the key to be long-lived (such as disk or mail encryption certificates).

通过在TPM中生成密钥，我们解决了所有这些问题。 TPM会存储密钥材料并对其自身执行所有加密操作，因此密钥无法被窃取。 当您在生成时提供密码时(可选，但建议使用)，TPM在执行任何操作之前也需要该密码，从而提供了第二层保护。 如果做得好，这将成为2FA的第二个因素。 TPM具有适当的物理保护，可防止攻击者通过边信道或芯片封盖访问其数据，并且具有防锤击保护，可防止强行使用密码。 综上所述，这可能是最普通的密钥保护形式(因此是身份验证)，普通用户无法使用Yubikey之类的物理加密狗。 由于每个相对较新的Intel / AMD处理器均具有固件TPM，而Microsoft在新的Windows计算机中需要某种TPM，因此您可能已经拥有一个！ 除非您需要密钥是长寿的(例如磁盘或邮件加密证书)，否则确实没有理由不使用这种存储密钥的方法。

关于什么是“两个因素”的注释 (A note on what counts as “2 Factors”)

If you’ve been paying attention, you’ll notice that this is not 2 factor authentication as typically understood: the server that validates the credential (Caddy, in my case) is only validating the certificate, which is under normal circumstances a single factor (“something you have”). The certificate is password-protected (“something you know”), but the web server doesn’t have any way of verifying that — if you had a valid certificate signed by my CA that wasn’t password protected, the server would still accept it. In my small case, the second factor is basically enforced by my personal policy, as I won’t issue certificates for this use that I haven’t personally verified are protected by hardware security and a PIN/Password in some way (such as via a TPM, smart card, or Yubikey).

如果您一直在关注，您会注意到这不是通常所理解的2因子身份验证：验证凭据的服务器(在我的情况下为Caddy)仅对证书进行验证，通常情况下这是一个因素(“您拥有的东西”)。 证书受密码保护(“您知道的事”)，但是Web服务器无法进行任何验证-如果您的CA签署了不受密码保护的有效证书，则服务器仍会接受它。 在我的小情况下，第二个因素基本上是我的个人政策所强制执行的，因为我不会为此用途签发未经过个人验证的证书，这些证书受到硬件安全性和PIN /密码的某种保护(例如通过TPM，智能卡或Yubikey)。

In an enterprise deployment such as Hello For Business, this check to ensure the keys are hardware protected is accomplished cryptographically by the provisioning server that signs new certificates. When provisioning a new device, the platform security module provides a certificate signing request as normal. It also provides a statement signed with a burned-in manufacturer key that attests to the certificate’s parameters (non-exportability, password protection, etc.). The provisioning server validates this statement before signing the CSR, which allows it to enforce the second factor policy across an entire enterprise. Highly secure applications will additionally require this attestation on every authentication request; this isn’t really possible with the standard TLS client authentication, so it’s traditionally done using Kerberos — the Kerberos server requires both the credential certificate and the attestation before issuing tickets. The same attestation key can combine with the TPM’s Trusted Boot functionality to remotely attest that the system is in a given state, allowing the authentication server to ensure that clients are in a secure state (e.g., using an up-to-date firmware and operating system and configured according to company policy) before granting them access to secure resources.

在企业部署(例如Hello For Business)中，此确保密钥受硬件保护的检查由签署新证书的预配置服务器以密码方式完成。 在配置新设备时，平台安全模块会正常提供证书签名请求。 它还提供了签署的声明一烧屏制造商的关键在于证明证书的参数(非出口能力，密码保护等)。 设置服务器在签署CSR之前先验证此语句，这使它可以在整个企业中实施第二因素策略。 高度安全的应用程序还将在每个身份验证请求中要求此证明； 使用标准的TLS客户端身份验证实际上是不可能的，因此传统上是使用Kerberos来完成的-Kerberos服务器在发出票证之前既需要证书证书又需要证明。 相同的证明密钥可以与TPM的Trusted Boot功能结合使用，以远程证明系统处于给定状态，从而允许身份验证服务器确保客户端处于安全状态(例如，使用最新的固件并进行操作)系统并根据公司政策进行配置)，然后授予他们访问安全资源的权限。

如何生成TPM支持的证书 (How to generate a TPM-backed certificate)

Make an INF file with the following (I called mine tpm_csr.inf):

使用以下命令制作INF文件(我称为mine tpm_csr.inf )：

[NewRequest]
Subject = "CN=email@example.com" ; can be anything, can also be changed when signing
Keylength = 2048 ; your TPM may support higher key lengths
Exportable = FALSE
UserProtected = TRUE
MachineKeySet = FALSE
ProviderName = "Microsoft Platform Crypto Provider"
ProviderType = 1
RequestType = PKCS10
KeyUsage = 0xB0 ; this is a https client certificate, can change when signing
FriendlyName = "My super secure certificate"

Then issue the command certreq -new -f .\tpm_csr.inf csr_name.csr. You will get a prompt offering to protect the generated key with a password — this is the second factor in your 2FA, so I recommend it. After that, sign the certificate request with your enterprise CA (this is out of scope of this blog post, but you probably know how to do this if you've gotten this far) and import the resulting certificate into your user's certificate store (double click on the crt file and click next a bunch of times) and you'll have a TPM-backed certificate ready for usage.

然后发出命令certreq -new -f .\tpm_csr.inf csr_name.csr 。 您将获得一个提示，提示您使用密码保护生成的密钥-这是2FA中的第二个因素，因此我建议使用。 之后，用您的企业CA签署证书请求(这不在本博客文章的讨论范围之内，但是如果您已经了解了这一点，您可能知道如何执行此操作)，然后将生成的证书导入用户的证书存储区(两次)单击crt文件，然后单击下一步很多次)，您便可以使用TPM支持的证书了。

Warning: You cannot export this key from the TPM. Ever. If you lose your PC, or if the TPM gets reset accidentally (this can happen if you use multiple operating systems and accidentally try to use it with both, or if the BIOS on your machine is reset), you will lose the key. Ensure that you have an alternate way of accessing anything you protect this way.

警告：您不能从TPM导出此密钥。 曾经 如果你失去了你的电脑，或者如果TPM得到意外复位(如果你使用多个操作系统会发生这种情况时，不慎尝试使用都使用它，或者如果你的机器上的BIOS复位)， 你将失去的关键 。 确保您有另一种方法来访问以此方式保护的所有内容。

You can also use this for SSH, by the way, using putty-cac. If you want to integrate it with the built-in Windows SSH tools (either the native Windows port or via WSL), see my next blog post for more information.

顺便说一下，您也可以使用putty-cac将其用于SSH。 如果要将其与内置的Windows SSH工具(本机Windows端口或通过WSL)集成，请参阅我的下一篇博客文章以获取更多信息。

Shea Polansky is a Security Analyst at Independent Security Evaluators, a firm of security specialists that provide a wide range of services including custom security assessments and software development. ISE also runs IoT Village, which hosts talks by expert security researchers who dissect real-world exploits and hacking contests consisting of off-the-shelf IoT devices.

Shea Polansky 是 独立安全评估 公司(一家 独立 的安全专家公司)的安全 分析师 ，该公司提供广泛的服务，包括自定义安全评估和软件开发。 ISE还运行 IoT Village ，该论坛主持了由专家安全研究人员主持的演讲，这些研究人员剖析了由现成的IoT设备组成的真实漏洞和黑客竞赛。

Twitter: @ISESecurity, @0x5ca1e5

Twitter的 ： @ISESecurity ， @ 0x5ca1e5

Sign up to get our latest blogs.

注册以获取我们的最新博客。

翻译自: https://blog.securityevaluators.com/creating-tpm-backed-certificates-on-windows-3013c4abd78a

tpm 证书