有关efi和window系统的理解

It is common to refer to the kernel as trusted, due to its inherently higher level of privilege and isolation
通常认为内核值得信任，由于相对用户模式，内核本就 做了高等级的隔离和特权限制。
from user-mode applications. Yet, countless third-party drivers are written each month—Microsoft has

但是还是有无数的第三方驱动被写入。微软表示有100万驱动哈希值被看见----用这个遥测技术。

stated that a million unique driver hashes are seen through telemetry, monthly! Each of these can contain any number of vulnerabilities, not to mention purposefully malicious kernel-mode code. In
每个驱动都有弱点。更不用说以内核为目标性的危险性代码

such a reality, the idea that the kernel is a small, protected component, and that user-mode applications are
在这样的一个现实情况下，内核要小，被保护的组件，用户的应用要 安全

“safe” from attack, is clearly an unrealized ideal. This state of affairs leads to an inability to fully trust
的想法是不可实现的。 这个影响状态下 不可能完全信任内核

the kernel, and leaves key user-mode applications, which may contain highly private user data, open to
并且让关键的用户模式的应用----这些应用具有高度私密的用户数据，对第三方企业开放

compromise from other malicious user-mode applications (which exploit buggy kernel-mode components) or malicious kernel-mode programs.
有危险的 —其他危险的用户模式的应用会带来危险

As discussed in Chapter 2, “System architecture,” Windows 10 and Server 2016 include a virtualizationbased security (VBS) architecture that enables an additional orthogonal level of trust: the
像第二章说的，系统架构------win10和服务器2016包含了一个基于虚拟化的安全架构-----启用了虚拟信任等级 ----vTL

virtual trust

level (VTL). In this section, you will see how Credential Guard and Device Guard leverage VTLs to protect
在这个章节，我 将会看见凭证保护和设备保护等级如何去保护

user data and provide an additional hardware-trust-based layer of security for digital code-signing purposes. At the end of this chapter, you will also see how Kernel Patch Protection (KPP) is
用户的数据并且提供一个额外的硬件信任基础层 为了数字代码签名这个目标。这个章节的结束，你将会看到KPP被提供

provided through the PatchGuard component and enhanced by the VBS-powered HyperGuard technology.
通过Patch守卫组件和被加强通过VBS电影，超及守卫技术----由VBS驱动

As a reminder, normal user-mode and kernel code runs in VTL 0 and is unaware of the existence of
像被提到的，正常的用户模式和核心代码运行在VTL 0 并且 不知道VTL1的存在。

VTL 1. This means anything placed at VTL 1 is hidden and inaccessible to VTL 0 code. If malware is able
意思就是任何放置在VTL1的东西，VTL0代码看不见。

to penetrate the normal kernel, it still cannot gain access to anything stored in VTL 1, including even
如果危险能够穿透正常内核，他也不能获得权限去到VTL 1 ，

user-mode code running in VTL 1 (which is called Isolated User Mode). Figure 7-2 shows the main VBS
用户模式运行在vtl1层。7-2图展示了主要的VBS组件。

components we’ll be looking at in this section:

■ Hypervisor-Based Code Integrity (HVCI) and Kernel-Mode Code Integrity (KMCI), which power
虚拟层代码和内核模式代码整合，可以给设备供电
Device Guard

■ LSA (Lsass.exe) and isolated LSA (LsaIso.exe), which power Credential Guard
lsa和被隔离的lsa，驱动凭据守卫
Additionally, recall that the implementation of Trustlets, which run in IUM, was shown in Chapter 3, “Process and jobs.
另外，重新调用，信任的实现，运行在IUM，在第三章介绍。

FIGURE 7-2 VBS components.
VBS组件
Of course, like any trusted component, VTL 1 also makes certain assumptions that the components it depends on can also be trusted. As such, VTL 1 requires Secure Boot (and thus,

当然，像任何被信任的组件，vtl1也创造某些假设，这样他依靠的组件可以被信任。VTL1 需要安全启动。
firmware) to function correctly, the hypervisor to not have been compromised, and hardware elements such as the IOMMU and Intel Management Engine to be free of VTL 0–

然后才能正常运行。虚拟层不会被损害，硬件元素没有 来自VTL 0 的弱点。
accessible vulnerabilities. For more information on the hardware chain of trust and boot-related security technologies, see Chapter 11, “Startup and shutdown,” in Part 2.
要得到更多的信息有关硬件链，看11章

Credential Guard
凭据保护
To understand the security boundary and protection that Credential Guard provides, it is important to understand the various components that provide access to a user’s resources
为了了解这个安全边界和保护----凭据保护提供的，理解各种组件----这些组件提供权限去访问用户的资源和数据

and data or login capabilities on a networked environment:

或者去登录网络环境。
Password This is the primary credential used by interactive users to identify themselves on the machine. This credential is used for 密码，这个是主要的凭据被使用的。可以让识别用户。

authentication and to derive the other components
这个凭据是有用的获得其他组件

of the credential model. It is the most highly sought after piece of a user’s identity.

用户就常用的就是密码
NT one-way function (NT OWF) This is a hash used by legacy components to identify the user (after a successful password logon)

NTOWF是一个哈希-----被用户传统组件，可以识别用户

using the NT LAN Manager (NTLM) protocol. While

它使用NT局域网协议。
modern networked systems no longer use NTLM to authenticate the user, many local components still do, as do some types of
同时现代网络系统不再使用NTLM去授权用户。许多局域网组件仍旧用NTLM

legacy network components (such as NTLM-based

authenticating proxies). Because NTOWF is an MD4 hash, its algorithmic complexity in the face of today’s hardware, and its lack
以为NTOWF是MD4哈希，

of anti-repeatability protection, means that

intercepting the hash leads to instant compromise and even possible recovery of the password.

Ticket-granting ticket (TGT) This is the equivalent of the NTOWF when a much more modern remote authentication mechanism is used: Kerberos. This is the default on Windows

Active Directory–based domains and is enforced on Server 2016. The TGT and a corresponding key are provided to the local machine after a successful logon (just like the NTOWF on

NTLM), and

Secure communication
As shown in Chapter 2, VTL 1 has a minimal attack surface, as it does not have the full regular “NT” kernel, nor does it have any 像第二章说的，VTL 1 有一个最小的攻击面，不是全的NT内核，它

drivers or access to I/O of hardware of any kind. As such, isolated LSA, which is a VTL 1 Trustlet, cannot directly communicate with
没有任何的驱动。它被LSA隔离， 不能直接和KDC交流。

the KDC. This is still the responsibility of the Lsass process, which serves as a proxy and protocol implementer, communicating

和KDC交互由lsass进程负责，是服务代理和协议的执行者，它与KDC交流，然后授权用户
with the KDC to authenticate the user and to receive the TGT and the key and NTOWF, as well as communicating with the file
和文件服务交互。去授权用户，接受TGT。 也和文件服务器交互----通过使用服务器门票。

server by using service ticket. This seemingly results in a problem: the TGT and its key/NTOWF transiently pass through Lsass

这个好像导致一个问题：TGT和它的 暂时的通过 lsass进程在授权的时候
during authentication, and the TGT and its key are somehow available to Lsass for the generation of service tickets. This leads to

并且TGT和它的密钥以某种方式能够用lsass生成。
two questions: How does Lsass send and receive the secrets from isolated ISA, and how can we prevent an attacker from doing

这导致两个问题，如何lsass进程发送和接受密钥从被隔离的ISA，我怎么防止攻击者
the same

UEFI lock
Because disabling Credential Guard (which is ultimately nothing more than a registry setting) is trivial for an attacker, Secure Boot
因为禁用凭证保护对攻击者来说是很简单的，安全启动和uefi可以被

and UEFI can be leveraged to prevent a non-physically present administrator (such as malware with admin rights) from disabling 利用去阻止一个非固定资产管理员的操作-----比如禁用凭证保护

Credential Guard. This is done by enabling Credential Guard with UEFI Lock. In this mode, an EFI runtime variable is written to
可以使用UEFI锁定。一个EFI系统运行变量被写入固件内存

firmware memory and a reboot is required. At the reboot, the Windows boot loader, which still operates in EFI Boot Services
并且需要重启。重启阶段，windows启动加载器，这个加载器可以操作EFI启动服务模式

mode, will write an EFI boot variable (which has the property of not being readable or writeable once EFI Boot Services mode is

会写一个EFI启动变量
exited) to record the fact that Credential Guard is enabled. Additionally, a Boot Configuration Database (BCD) option will be

recorded.

When the kernel boots, it will automatically rewrite the required Credential Guard registry key in the presence of the BCD option
当核心启动，它会自动重写凭证保护注册表在 BCD阶段

and/or UEFI runtime variable. If the BCD option is deleted by an attacker, BitLocker (if enabled) and based remote

如果BCD被删了，bitlocker和TMP
attestation (if enabled) will detect the change and require physical input of the admin’s recovery key before booting, which will

将会发现系统被改变了，需要物理输入用户的回复密钥，在重启的时候
then restore the BCD option based on the UEFI runtime variable. If the UEFI runtime variable is deleted, the Windows boot loader

然后回复BCD操作。如果UEFI的变量被删了
will restore it based on the UEFI boot variable. As such, without special code to delete the UEFI boot variable—which can only be

window启动加载器有备份的。UEFI启动变量没被删，就从EFI启动模式启动，
done in EFI Boot Services mode—there is no way to disable Credential Guard in UEFI lock mode.

没办法去禁用凭据保护的。
The only such code that exists is in a special Microsoft binary called SecComp.efi. This must be downloaded by the administrator,

who must then either boot the computer from an alternate EFI-based device and manually execute it (which will require the

BitLocker recovery key as well as physical access) or modify the BCD (which will require the BitLocker recovery key). At the reboot,

SecComp.efi will require user confirmation while in UEFI mode (which can only be done by a physical user).