BitLocker 自动设备加密
BitLocker 自动设备加密
想必大家都知道 BitLocker，可以帮助我们对磁盘数据加密，确保其在系统脱机时不会被篡改或窃取。迄今为止 BitLocker 仍然是公认的最为安全的磁盘数据加密技术之一，受到不少企业用户的青睐。现在当我们采购来预装有Windows 10的设备后，完成OOBE就会发现当前磁盘已经是加密状态，十分的方便。
那么这些 Windows 10 设备是如何确保 BitLocker 能够自动加密呢？！要实现自动设备加密硬件需要满足如下要求：
- 设备包含 TPM，包括 TPM 1.2或2.0。
- 基于 UEFI 启用。
- 已启用 Secure Boot。
- 已启用 DMA（直接内存访问）保护。
在 Windows 10 启用自动加密前，会进行如下测试：
- TPM 必须包括支持 PCR7 的 TPM
- 启用了 UEFI 和 Secure Boot
- 支持 Modern Standby 或 HSTI 验证
- 启动分区有 250MB 的可用空间
- 操作系统版本不应早于 Windows 10 1703
此外，需要注意的是仅当使用 MSA 或 AAD 账户登录，才会启用 BitLocker 自动设备加密特性。但这是否意味着如果我使用本地账号在符合 BitLocker 自动加密的设备上完成 OOBE 就会禁用自动加密呢？！
gOxiA 对此进行了研究和测试，实践表明在满足 BitLocker 自动加密的设备上，即使你在 OOBE 阶段用本地账号配置计算机，但之后系统还是会对磁盘进行加密，只是保护状态是未激活的。如果一些企业用户需要使用非 BitLocker 的磁盘加密保护，就需要考虑在标准化部署中禁用 BitLocker 自动设备加密。
为此，我们可以修改企业标准化映像的应答文件（Unattend.xml），添加 “Microsoft-Windows-SecureStartup-FilterDriver” 组件，并将 “PreventDeviceEncryption” 设置为 “true”。注意：该组件支持 offlineServing、specialize、auditSystem 和 oobeSystem 阶段。
我们也可以修改注册表来阻止 BitLocker 自动设备加密，同样是 “PreventDeviceEncryption”，REG_DWORD 类型，值为 1，其位于注册表 “HKLM\SYSTEM\CurrentControlSetControl\Bitlocker”，我们可以在 OOBE 阶段执行，即可停用自动加密。或者 IT 人员也可以编写脚本调用“Manage-bde –off [driverletter:]”命令关闭 BitLocker 加密。
正确认识和理解 Windows Hello 的人脸验证
正确认识和理解 Windows Hello 的人脸验证
今天 gOxiA 来分享这个话题的起因是因为回到家中按照社区要求需要独自隔离14天，所以也就一直没有刮胡子，今天是最后一天于是一早在微信上发了一条关于 Windows Hello 的信息，说自己即使满脸长胡子也能够被 Windows Hello 识别出来，感觉非常惊喜。也正是因为这条信息，了解到圈里的一些朋友对微软的 Windows Hello 没有正确的理解，一直认为是与市面上其他识别技术一样采集“用户的图像”来进行比对认证，所以 gOxiA 认为非常有必要整理一下 Windows Hello 的知识，让广大用户正确认识 Windows Hello。
本文不会做与其他识别技术的对比和分析，只从 Windows Hello 和 Surface 设备角度来进行介绍。
相信大家有知道 Surface 的都会了解其出彩之一的功能特性就是带有支持 Windows Hello 人脸识别的红外摄像头（近红外传感器），通过 Windows 10 中的 Microsoft人脸身份验证（一种企业级身份验证机制）可以用来进行身份验证和解锁 Windows 设备，而且现在已经支持解锁 Microsoft Passport（在使用微软账号访问相关服务时可通过人脸识别进行登录验证）。
那么在使用 Surface 的近红外成像摄像头（IR Camera）通过 Windows Hello 进行人脸识别登录时是怎样的一种机制或者说过程呢？！其会有普通大众所担心的安全问题吗？因为从开篇曾提到 gOxiA 的一些朋友会认为“这是一种采集更多人脸图片来进行比对的一种功能”，恐会担心隐私问题。那么接下来我们先了解 Windows Hello 的运行方式。
首先，用户需要发起一个脸部识别的注册，如下图在 Windows 设置中找到 账户 设置，里面有个 登录选项，你就能看到 Windows Hello 人脸，它就是人脸识别注册入口。
接下来 Windows Hello 会通过 Surface 的 IR Camera 识别人脸，其算法将检测 IR Camera 中的用户面部，然后找到与眼睛，鼻子，嘴巴等相应的面部界标点（也称为对齐点）。为了确保算法有足够的面孔来做出认证决策，还会识别头部的方向。然后使用地标位置作为锚点，这种算法将从人脸的不同区域获取数千个样本来构建表示，其基本形式的表示即直方图，表示特点点周围的明暗差异。
可以理解，以上过程中通过人脸识别出来的只是一种“代表”，不是存储脸部的图像。通俗理解就是利用算法识别出当前脸部特征用作后续的验证，这一过程是生成自己的一个表示或一组表示的步骤（例如，如果我们有眼镜，则可能需要在不戴眼镜的情况下进行注册），这种表示形式的集合称为我们的注册资料，并存储在本地系统上以备将来比较。
所以呢，进一步的认识是：微软不会且永远不会存储实际的图像来用于对比验证。而且，这些注册数据也不会发送到网站或应用程序进行身份验证。当然，也不用想什么脸部注册漫游了，不要指望换台电脑登录账号就能直接启用脸部识别，需要在当前设备的 Windows 系统上重新注册以生成脸部特征表示。
接下来，当我们要通过 Windows Hello 进行人脸识别登录时，只需要面对 Surface 的 IR Camera，其会将获取的当前面部特征表示与当前设备系统上的已注册用户进行比较，该表示形式必须超过机器学习的阈值，然后算法才能将其接受为正确的匹配项。
前面，我们提过在过程中要生成自己的一个表示或一组表示步骤，其中的"一组"表示步骤会发生在以下几个情形中，此时我们可以通过“提高识别能力”再次进行识别，例如摘掉眼镜做一次识别。
- 偶尔戴某些类型的眼镜
- 面部形状或质地发生了重大变化
- 转移到周围环境光线较近的红外光下（例如：设备在室外阳光下）
转回 Surface 来说说它采用 IR Camera 的好处或优势，可以通过下面几张图来进行了解。
在以弱光为代表的如看电视或做PPT演示文稿情景下，使用普通摄像头和 Surface 近红外摄像头获取到的图像如下，可以看出 IR Camera 不会受到弱光和摄像头彩色成像系统的影响，能够生成清晰的图像。
（普通摄像头获取到的彩色图像） 
（IR Camera 获取到的红外图像）
下来，再看看如果在窗户或台灯前受到侧面照明时的情景，图像如下，IR Camera 仍能生成清晰完整的图像。
（普通摄像头获取到的彩色图像） 
（IR Camera 获取到的红外图像）
此外，由于使用了 IR Camera 还可以防止图像欺骗，因为红外采像时物体的波长会有所不同，也就是说你拿一张人像照片在 IR Camera 下是获取不到照片中的人像的，只能生成照片这个物体的外观，而其他材质下也是一样，例如手机的屏幕或者电脑屏幕。如下图所示：
在测量精度方面，微软的 Windows Hello 又是如何做的呢？！它使用了三种主要度量：错误肯定，正确肯定，错误否定。
- 错误肯定：有时也被计算为错误接受率，表示获得对你设备的物理访问权的随机用户被识别为你的可能性。该数字应尽可能的低。基线为小于0.001%或1/100000FAR。
- 正确肯定：即：真实肯定率，表示用户每次位于传感器前面时，将正确匹配其已注册个人资料的可能性。该数字应该尽可能的高。基线为单个注册用户大于95%。
- 错误否定：表示用户与他们的注册个人资料不匹配的可能性。该数字应尽可能的低。基线为单个注册用户不到5%。
考虑到测量误差非常重要，因此微软还通过两种方式对它们进行了分类：偏差误差（系统误差）和随机误差（采样）。
- 偏差误差：由于不使用 代表使用算法的环境和条件的数据，可能会导致偏差错误。此类错误可能是由于不同的环境条件（例如：照明，与传感器的角度，距离等）以及硬件导致的。
- 随机误差：随机错误是由于使用的数据与实际使用该功能的总体多样性不匹配而导致的。（例如：专注于少数没有眼镜，胡须或独特面部特征的脸部。）
通过以上内容的学习和理解，希望有助于大家正确认识 Windows Hello，排除误解。我们要知道 Windows Hello 的人脸识别技术不是靠存储图像来进行比对分析的！！！“Windows Hello 是科学、智能、严谨、合规，具备操守的。-- gOxiA”
虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG
虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG
当 IT 人员通过 PPKG (Provisioning Package - 预配包)来实现 Windows 10 的动态部署时，不免要对 PPKG 进行测试已验证是否达到预先设计的目标，通常我们会在管理员工作站上常见 PPKG，然后拷入到 U盘或网络共享中供目标设备测试或使用，但由于 PPKG 会对系统进行配置，虽然其提供了卸载功能，但一些特定的设置仍然会保留在系统中，如此反复会增加 IT 人员的成本。
利用虚拟环境，如虚拟机能够很好的帮助我们来进行测试验证，我们可以创建一个干净的环境状态下创建一个检查点，然后再应用 PPKG，当需要的时候还原检查点便可以从头开始。
但是，如果我们需要在 Windows 10 OOBE 阶段测试部署 PPKG 呢？常规的做法是将 PPKG 拷贝到可移动媒体，如 U盘上。（注意：PPKG必须存储在 U盘的根目录下），然后启动目标设备进入 OOBE，然后插入包含 PPKG 的 U盘，此时会自动开始应用 PPKG。当需要重复测试时，我们需要耗费大量的等待时间来重置 Windows 10 安装，使其恢复到最初的状态，重新开始 OOBE。
你可能会想到利用虚拟机（Hyper-V）来实现方便快捷的测试，但接下来会发现由于不能添加虚拟的 USB存储设备，将导致无法检索到 PPKG。也许你也跟 gOxiA 有一样的想法，将 PPKG 拷贝到一个虚拟磁盘根目录下，并加载到虚拟机中，然后在 OOBE 界面上连续按下五次 Windows 键来激活配置选项，但结果并不能如尝所愿，因为“安装预配包”向导无法检索到这个 PPKG。或者，你会考虑使用 DISM 或 PowerShell 命令来应用 PPKG，但由于处于 OOBE 这个特殊阶段，将会无法正常应用 PPKG。
难道，我们就没有办法了吗？？？！！！
其实，在 OOBE 阶段除了能够自动识别 U盘和 SD卡这类的可移动媒体外，还支持光盘驱动器。没错，我们可以利用虚拟机中的虚拟光驱来实现我们的需求，只需要为 PPKG 创建一个 ISO，加载到虚拟机中便可以在 OOBE 阶段检索到 PPKG。
为 PPKG 创建一个 ISO 有很多方法，除了第三方软件外，gOxiA 强烈建议你使用 Windows ADK 中自带的 Oscdimg.exe 工具，对于要跟桌面部署打交道的 IT 人员来说，相信每一位都会在管理员工作站上安装 Windows ADK。现在，我们只需要将 Oscdimg.exe 所在的目录位置添加到用户变量中即可在任意目录中执行该命令。
Oscdimg.exe 所在的目录位置是：
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg
为 PPKG 生成 ISO 的命令行很简单，如下参考：
在 OOBE 阶段，将生成的 ISO 加载到虚拟机中，然后连续按下五次 Windows 键，选择“安装预配包”，便会自动检索并应用这个 ISO 中的 PPKG。
现在，我们就可以开始轻松的测试 PPKG 动态部署 Windows 10 了。文末，分享 PPKG 在 OOBE 阶段执行部署时的一些重点知识。
- 配置引擎会始终应用保留在 C:\Revovery\Customizations 目录下的 PPKG。
- PPKG 将会被复制到 %ProgramData%\Microsoft\Provisioning 目录下。
- 在 OOBE 阶段可以直接应用未签名信任的 PPKG。
- 当配置引擎在 OOBE 阶段应用 PPKG 时，仅将运行时设置从 PPKG 包中应用到设备。运行时设置可以是系统范围的配置设置，包括：安全策略、Windows应用程序安装和卸载，网络配置，引导 MDM 注册，账户和域配置，Windows 版本升级等。配置引擎还会检查设备上的配置设置（如：区域设置或 SIM 卡），并应用具有匹配条件的多变量设置。
