aboutsummaryrefslogtreecommitdiff
path: root/zh-cn
diff options
context:
space:
mode:
authorAndroid Partner Docs <noreply@android.com>2017-07-05 15:59:39 -0700
committerClay Murphy <claym@google.com>2017-07-11 13:22:04 -0700
commiteee70913d1765f2e17ed27fbd97b8ed41426a149 (patch)
treea24e12a73c8edf57513ea3d3904d6b00c290042a /zh-cn
parent26a6e1b2badf69ddc616ec51687c1d3ecfd8b646 (diff)
downloadsource.android.com-eee70913d1765f2e17ed27fbd97b8ed41426a149.tar.gz
Docs: Changes to source.android.com
- 161017723 Add warnings about incompatibility of FBE and adoptable s... by claym <claym@google.com> - 160996093 Docs: Nav changes to prep for O + new framework image by hvm <hvm@google.com> - 160984727 Devsite localized content from translation request 76cba1... by Android Partner Docs <noreply@android.com> - 160984408 Add instructions to check for device security update by daroberts <daroberts@google.com> - 160971202 July 2017 Security bulletin updates by daroberts <daroberts@google.com> - 160958735 Update audit2allow commands by daroberts <daroberts@google.com> - 160567793 Redirect old Dumpsys pages to DAC by claym <claym@google.com> - 160553240 Devsite localized content from translation request 29dc8d... by Android Partner Docs <noreply@android.com> - 160550105 Use a SHA-256 checksum, not a SHA-1 checksum, for the lat... by Android Partner Docs <noreply@android.com> - 160448356 Add researcher attribution for CVE-2017-0574 by daroberts <daroberts@google.com> - 160342125 Publish localized June security bulletin by daroberts <daroberts@google.com> - 160293585 Devsite localized content from translation request 3cdce1... by Android Partner Docs <noreply@android.com> - 160292361 Adds link to go/sac-guide at top of README for Googlers. by blamb <blamb@google.com> - 160281439 Include a mention of --cbr in the using-repo docs. by Android Partner Docs <noreply@android.com> PiperOrigin-RevId: 161017723 Change-Id: Ie54ae2e7ac3aec03736d94fd13d6dbc16a804b9a Test: make online-sac-docs
Diffstat (limited to 'zh-cn')
-rw-r--r--zh-cn/devices/tech/debug/gdb.html109
-rw-r--r--zh-cn/security/advisory/2016-03-18.html42
-rw-r--r--zh-cn/security/advisory/index.html44
-rw-r--r--zh-cn/security/apksigning/index.html60
-rw-r--r--zh-cn/security/apksigning/v2.html223
-rw-r--r--zh-cn/security/authentication/fingerprint-hal.html107
-rw-r--r--zh-cn/security/authentication/gatekeeper.html106
-rw-r--r--zh-cn/security/authentication/index.html166
-rw-r--r--zh-cn/security/bulletin/2017-06-01.html1268
-rw-r--r--zh-cn/security/encryption/full-disk.html395
-rw-r--r--zh-cn/security/encryption/index.html38
-rw-r--r--zh-cn/security/enhancements/enhancements41.html57
-rw-r--r--zh-cn/security/enhancements/enhancements42.html49
-rw-r--r--zh-cn/security/enhancements/enhancements43.html63
-rw-r--r--zh-cn/security/enhancements/enhancements44.html49
-rw-r--r--zh-cn/security/enhancements/enhancements50.html38
-rw-r--r--zh-cn/security/enhancements/enhancements60.html35
-rw-r--r--zh-cn/security/enhancements/enhancements70.html37
-rw-r--r--zh-cn/security/enhancements/index.html25
-rw-r--r--zh-cn/security/index.html108
-rw-r--r--zh-cn/security/keystore/features.html217
-rw-r--r--zh-cn/security/keystore/index.html55
-rw-r--r--zh-cn/security/overview/app-security.html154
-rw-r--r--zh-cn/security/overview/implement.html218
-rw-r--r--zh-cn/security/overview/kernel-security.html86
-rw-r--r--zh-cn/security/overview/updates-resources.html183
-rw-r--r--zh-cn/security/selinux/concepts.html106
-rw-r--r--zh-cn/security/selinux/customize.html247
-rw-r--r--zh-cn/security/selinux/device-policy.html193
-rw-r--r--zh-cn/security/selinux/implement.html129
-rw-r--r--zh-cn/security/selinux/index.html67
-rw-r--r--zh-cn/security/selinux/validate.html107
-rw-r--r--zh-cn/security/trusty/index.html95
-rw-r--r--zh-cn/security/verifiedboot/dm-verity.html186
-rw-r--r--zh-cn/security/verifiedboot/index.html59
-rw-r--r--zh-cn/security/verifiedboot/verified-boot.html361
36 files changed, 5455 insertions, 27 deletions
diff --git a/zh-cn/devices/tech/debug/gdb.html b/zh-cn/devices/tech/debug/gdb.html
new file mode 100644
index 00000000..f9c74d5d
--- /dev/null
+++ b/zh-cn/devices/tech/debug/gdb.html
@@ -0,0 +1,109 @@
+<html devsite><head>
+ <title>使用 GDB</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>GNU 项目调试程序 (GDB) 是常用的 Unix 调试程序。本页详细介绍了如何使用 <code>gdb</code> 调试 Android 应用和进程。</p>
+
+<h2 id="running">调试运行中的应用或进程</h2>
+
+<p>要连接到已在运行的应用或本机守护进程,请配合使用 <code>gdbclient</code> 和 PID。例如,要调试 PID 为 1234 的进程,请运行:</p>
+
+<pre class="devsite-terminal devsite-click-to-copy">
+gdbclient 1234
+</pre>
+
+<p>此脚本会设置端口转发,在设备上启动相应的 <code>gdbserver</code>,在主机上启动相应的 <code>gdb</code>,配置 <code>gdb</code> 以找出符号,然后将 <code>gdb</code> 连接到远程 <code>gdbserver</code>。</p>
+
+<h2 id="starts">调试本机进程启动</h2>
+
+<p>要在进程启动时对其进行调试,请使用 <code>gdbserver</code> 或 <code>gdbserver64</code>(适用于 64 位进程)。例如:</p>
+
+<pre class="devsite-terminal devsite-click-to-copy">
+adb shell gdbserver :5039 /system/bin/<var>MY_TEST_APP</var>
+</pre>
+
+<p>输出示例:</p>
+<pre class="devsite-click-to-copy">
+Process <var>MY_TEST_APP</var> created; pid = 3460
+Listening on port 5039
+</pre>
+
+<p>接下来,从 <code>gdbserver</code> 输出中找出应用 PID,并将其用于其他终端窗口。</p>
+
+<pre class="devsite-terminal devsite-click-to-copy">
+gdbclient <var>APP_PID</var>
+</pre>
+
+<p>最后,在 <code>gdb</code> 提示处输入 <strong>continue</strong>。</p>
+
+<p class="note"><strong>注意</strong>:如果您指定了错误的 <code>gdbserver</code>,将会收到没任何帮助的错误消息(例如“<code>Reply contains invalid hex digit 59</code>”)。</p>
+
+<h2 id="app-startup">调试应用启动</h2>
+
+<p>有时,您需要在应用启动时对其进行调试;例如在应用发生崩溃时,您需要逐步检查代码,以查看崩溃之前<em></em>发生的情况。
+<a href="#running">附加</a>调试程序有时能解决问题,有时不能解决问题,因为应用可能会在您可以附加调试程序之前崩溃。<code>logwrapper</code> 方法(用于 <code>strace</code> 和 <code>valgrind</code>)不一定能解决所有的问题,因为应用可能没有权限打开端口,而 <code>gdbserver</code> 会继承这项限制。</p>
+
+<p>要调试应用启动,请使用“设置”中的开发者选项,指示应用等待附加 Java 调试程序:</p>
+
+<ol>
+<li>请依次转到“设置”&gt;“开发者选项”&gt;“选择调试应用”<em></em>,并从列表中选择您的应用,然后按<strong>等待调试程序</strong>。</li>
+
+<li>启动应用,您可以从启动器启动,也可以在命令行中运行以下命令来启动:<pre class="devsite-terminal devsite-click-to-copy">
+am start -a android.intent.action.MAIN -n <var>APP_NAME</var>/.<var>APP_ACTIVITY</var>
+</pre></li>
+
+<li>等待应用加载,然后等待系统显示一个对话框提示您应用正在等待附加调试程序。</li>
+
+<li>正常附加 <code>gdbserver</code>/<code>gdbclient</code>,设置断点,然后继续运行该进程。</li></ol>
+
+<p>要让应用实际运行,请附加 Java 调试网络协议 (JDWP) 调试程序,例如 Java 调试程序 (jdb):</p>
+<pre class="devsite-click-to-copy">
+<code class="devsite-terminal">adb forward tcp:12345 jdwp:<var>XXX</var> # (Where XXX is the pid of the debugged process.)</code>
+<code class="devsite-terminal">jdb -attach localhost:12345</code>
+</pre>
+
+<h2 id="crash">调试崩溃的应用或进程</h2>
+
+<p>如果您希望 <code>debuggerd</code> 暂停崩溃的进程,以便您可以附加 <code>gdb</code>,请设置相应的属性:</p>
+
+<pre class="devsite-click-to-copy">
+# Android 7.0 Nougat and later.
+<code class="devsite-terminal">adb shell setprop debug.debuggerd.wait_for_gdb true</code>
+</pre>
+
+<pre class="devsite-click-to-copy">
+# Android 6.0 Marshmallow and earlier.
+<code class="devsite-terminal">adb shell setprop debug.db.uid 999999</code>
+</pre>
+
+<p>在寻常的崩溃输出结束后,<code>debuggerd</code> 会提供有关如何使用命令连接 <code>gdb</code> 的说明:</p><pre class="devsite-terminal devsite-click-to-copy">
+gdbclient <var>PID</var>
+</pre>
+
+<h2 id="symbols">无符号调试</h2>
+
+<p>对于 32 位 ARM,如果您没有符号,<code>gdb</code> 就会搞不清楚要反汇编的指令集(ARM 或 Thumb)。要在缺失符号信息时指定已选为默认项的指令集,请设置以下属性:</p>
+
+<pre class="devsite-terminal devsite-click-to-copy">
+set arm fallback-mode arm # or thumb
+</pre>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/advisory/2016-03-18.html b/zh-cn/security/advisory/2016-03-18.html
index 16cb18df..222d71d0 100644
--- a/zh-cn/security/advisory/2016-03-18.html
+++ b/zh-cn/security/advisory/2016-03-18.html
@@ -1,8 +1,7 @@
-<html devsite>
- <head>
- <title>Android 安全公告 - 2016 年 3 月 18 日</title>
- <meta name="project_path" value="/_project.yaml" />
- <meta name="book_path" value="/_book.yaml" />
+<html devsite><head>
+ <title>Android 安全建议 - 2016 年 3 月 18 日</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
</head>
<body>
<!--
@@ -21,15 +20,13 @@
limitations under the License.
-->
-
-
<p><em>发布时间:2016 年 3 月 18 日</em></p>
-<p>Android 安全公告是对 Nexus 安全公告的补充。要详细了解安全公告,请参阅我们的<a href="index.html">摘要网页</a>。</p>
+<p>Android 安全建议是对 Nexus 安全公告的补充。如需关于安全建议的更多信息,请参阅我们的<a href="index.html">摘要页面</a>。</p>
<h2 id="summary">摘要</h2>
-<p>Google 注意到,某个 Root 应用会利用部分 Android 设备上的内核中某个未被补丁程序修复的本地提权漏洞 (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1805">CVE-2015-1805</a>)。只有用户在设备上安装该应用后,设备才会受到该应用的影响。Google 已通过<a href="https://support.google.com/accounts/answer/2812853">验证应用</a>功能阻止用户在 Google Play 内外安装会利用该漏洞的 Root 应用。此外,Google 还更新了系统,以便检测会利用这一特定漏洞的应用。</p>
+<p>Google 注意到,某个 Root 应用会利用部分 Android 设备的内核中某个未被补丁程序修复的本地提权漏洞 (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1805">CVE-2015-1805</a>)。只有用户在设备上安装该应用后,设备才会受到该应用的影响。Google 已通过<a href="https://support.google.com/accounts/answer/2812853">验证应用</a>功能阻止用户在 Google Play 内外安装会利用该漏洞的 Root 应用。此外,Google 还更新了系统,以便检测会利用这一特定漏洞的应用。</p>
<p>为了针对该问题提供最后一道防护屏障,我们已在 2016 年 3 月 16 日向合作伙伴提供用于修复该问题的补丁程序。我们正在准备 Nexus 更新版本,近日就会发布。此外,我们还在 Android 开放源代码项目 (AOSP) 代码库中发布了针对该问题的源代码补丁程序。</p>
@@ -43,37 +40,32 @@
<h3 id="scope">范围</h3>
-
-<p>该公告适用于所有搭载内核版本 3.4、3.10 和 3.14 且未安装补丁程序的 Android 设备(包括所有 Nexus 设备)。Linux 内核版本为 3.18 或更高版本的 Android 设备不会受到影响。</p>
+<p>该安全建议适用于所有内核版本为 3.4、3.10 和 3.14 且未安装补丁程序的 Android 设备(包括所有 Nexus 设备)。Linux 内核版本为 3.18 或更高版本的 Android 设备不会受到影响。</p>
<h3 id="mitigations">缓解措施</h3>
-
<p>下列缓解措施有助于降低用户受该问题影响的可能性:</p>
<ul>
<li>“验证应用”功能已进行了更新,能够阻止用户在 Google Play 内外安装会试图利用该漏洞的已知应用。
- <li>Google Play 禁止 Root 应用(例如会试图利用该问题的应用)上架。
- <li><a href="https://support.google.com/nexus/answer/4457705">Linux 内核版本为 3.18</a> 或更高版本的 Android 设备不会受到影响。
-</li></li></li></ul>
+ </li><li>Google Play 禁止 Root 应用(例如会试图利用该问题的应用)上架。
+ </li><li><a href="https://support.google.com/nexus/answer/4457705">Linux 内核版本为 3.18</a> 或更高版本的 Android 设备不会受到影响。
+</li></ul>
<h3 id="acknowledgements">致谢</h3>
-
-<p>Android 非常感谢 <a href="http://c0reteam.org/">C0RE 团队</a>和 <a href="https://www.zimperium.com/">Zimperium</a> 对该公告做出的贡献。</p>
+<p>Android 衷心感谢 <a href="http://c0reteam.org/">C0RE 团队</a>和 <a href="https://www.zimperium.com/">Zimperium</a> 对该安全建议做出的贡献。</p>
<h3 id="suggested_actions">建议操作</h3>
-
<p>Android 建议所有用户在有设备软件更新时,进行相应更新。</p>
<h3 id="fixes">修复程序</h3>
-
<p>Google 已针对多个内核版本在 AOSP 代码库中发布修复程序。我们已向 Android 合作伙伴发出相关修复程序的通知,并建议他们采用。如需进一步更新,Android 会直接将更新内容发布到 AOSP。</p>
<table>
- <tr>
+ <tbody><tr>
<th>内核版本</th>
<th>补丁程序</th>
</tr>
@@ -93,12 +85,10 @@
<td>3.18+</td>
<td>公开 Linux 内核已打了补丁程序</td>
</tr>
-</table>
-
+</tbody></table>
<h2 id="common_questions_and_answers">常见问题和解答</h2>
-
<p><strong>1. 具体问题是什么?
</strong></p>
@@ -126,10 +116,8 @@
<h2 id="revisions">修订版本</h2>
-
<ul>
- <li>2016 年 3 月 18 日:发布了公告。
+ <li>2016 年 3 月 18 日:发布了安全建议。
</li></ul>
- </body>
-</html>
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/advisory/index.html b/zh-cn/security/advisory/index.html
new file mode 100644
index 00000000..444e8a53
--- /dev/null
+++ b/zh-cn/security/advisory/index.html
@@ -0,0 +1,44 @@
+<html devsite><head>
+ <title>Android 安全建议</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 安全建议是对 <a href="/security/bulletin/index.html">Android 安全公告</a>的补充。Android 会发布一些建议,让用户了解如何解决可能不需要安全补丁程序或 Nexus/Pixel 设备更新,但仍可能影响 Android 用户总体安全性的问题。Android 安全公告中会随附<a href="https://developers.google.com/android/nexus/images">设备出厂映像</a>和无线下载 (OTA) 的设备更新,以保护用户免遭 Android 生态系统中已知安全问题的影响。<em></em>Android 安全建议则旨在针对与 Android 有关的安全问题向用户提供详细信息和指导,可能不会随附相应的软件更新。</p>
+
+<p>不过,当有更新可用于解决 Android 安全建议中介绍的问题时,我们会在针对 Nexus 和 Pixel 设备的 Android 安全公告中提供这些更新。在 Android 安全公告中,我们会提到公告中要解决的问题对应的是哪期 Android 安全建议。</p>
+
+<p>和接收公告方面的通知一样,加入 <a href="https://groups.google.com/forum/#!forum/android-security-updates">Android 安全更新</a>论坛后,您便可以在我们发布建议时收到通知。</p>
+
+<table>
+ <tbody><tr>
+ <th>建议</th>
+ <th>语言</th>
+ <th>发布日期</th>
+ </tr>
+ <tr>
+ <td><a href="2016-03-18.html">2016-03-18</a></td>
+ <td>
+ <a href="/security/advisory/2016-03-18.html">English</a> / <a href="/security/advisory/2016-03-18.html?hl=ja">日本語</a> / <a href="/security/advisory/2016-03-18.html?hl=ko">한국어</a> / <a href="/security/advisory/2016-03-18.html?hl=ru">ру́сский</a> / <a href="/security/advisory/2016-03-18.html?hl=zh-cn">中文 (中国)</a> / <a href="/security/advisory/2016-03-18.html?hl=zh-tw">中文 (台灣)</a>
+ </td>
+ <td>2016 年 3 月 18 日</td>
+ </tr>
+</tbody></table>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/apksigning/index.html b/zh-cn/security/apksigning/index.html
new file mode 100644
index 00000000..c0af7d0f
--- /dev/null
+++ b/zh-cn/security/apksigning/index.html
@@ -0,0 +1,60 @@
+<html devsite><head>
+ <title>应用签名</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>通过应用签名,开发者可以标识应用创作者并更新其应用,而无需创建复杂的接口和权限。在 Android 平台上运行的每个应用都必须要有<a href="https://developer.android.com/studio/publish/app-signing.html">开发者的签名</a>。Google Play 或 Android 设备上的软件包安装程序会拒绝没有获得签名就尝试安装的应用。
+</p>
+<p>在 Google Play 上,应用签名可以将 Google 对开发者的信任和开发者对自己的应用的信任联系在一起。这样一来,开发者就知道自己的应用是以未经修改的形式提供给 Android 设备,并且可以对其应用的行为负责。
+</p>
+<p>在 Android 上,应用签名是将应用放入其应用沙盒的第一步。已签名的应用证书定义了哪个用户 ID 与哪个应用相关联;不同的应用要以不同的用户 ID 运行。应用签名可确保一个应用无法访问任何其他应用的数据,通过明确定义的 IPC 进行访问时除外。</p>
+<p>当应用(APK 文件)安装到 Android 设备上时,软件包管理器会验证 APK 是否已经过适当签名(已使用 APK 中包含的证书签名)。如果该证书(或更准确地说,证书中的公钥)与设备上的任何其他 APK 使用的签名密钥一致,那么这个新 APK 就可以选择在清单中指定它将与其他以类似方式签名的 APK 共用一个 UID。
+</p>
+<p>应用可以由第三方(OEM、运营商、其他应用市场)签名,也可以自行签名。Android 提供了使用自签名证书进行代码签名的功能,而开发者无需外部协助或许可即可生成自签名证书。应用并非必须由核心机构签名。Android 目前不对应用证书进行 CA 认证。
+</p>
+<p>应用还可以在“签名”保护级别声明安全权限,以便只有使用同一个密钥签名的应用可以获得此仅限,同时让这些应用可以各自维持单独的 UID 和应用沙盒。通过<a href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">共用 UID 功能</a>,多个应用可以共用一个应用沙盒,从而建立起更紧密的联系。在该功能中,使用同一个开发者密钥签名的两个或更多应用可以在其清单中声明共用的 UID。</p>
+<h2>APK 签名方案</h2>
+<p>Android 支持两种应用签名方案,一种是基于 JAR 签名的方案(v1 方案),另一种是 Android Nougat (Android 7.0) 中引入的 <a href="v2.html">APK 签名方案 v2(v2 方案)</a>。
+</p>
+<p>为了最大限度地提高兼容性,应同时采用 v1 和 v2 这两种方案对应用进行签名。与只通过 v1 方案签名的应用相比,通过 v2 方案签名的应用能够更快速地安装到 Android Nougat 及更高版本的设备上。更低版本的 Android 平台会忽略 v2 签名,这就需要应用包含 v1 签名。
+</p>
+<h3 id="v1">JAR 签名(v1 方案)</h3>
+<p>从一开始,APK 签名就是 Android 的一个有机部分。该方案基于<a href="https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Signed_JAR_File">签名的 JAR</a>。如要详细了解如何使用该方案,请参阅介绍如何<a href="https://developer.android.com/studio/publish/app-signing.html">为您的应用签名</a>的 Android Studio 文档。
+</p>
+<p>v1 签名不保护 APK 的某些部分,例如 ZIP 元数据。APK 验证程序需要处理大量不可信(尚未经过验证)的数据结构,然后会舍弃不受签名保护的数据。这会导致相当大的受攻击面。此外,APK 验证程序必须解压所有已压缩的条目,而这需要花费更多时间和内存。为了解决这些问题,Android 7.0 中引入了 APK 签名方案 v2。
+</p>
+<h3 id="v2">APK 签名方案 v2(v2 方案)</h3>
+<p>Android 7.0 中引入了 APK 签名方案 v2(v2 方案)。该方案会对 APK 的内容进行哈希处理和签名,然后将生成的“APK 签名分块”插入到 APK 中。如要详细了解如何在应用中使用 v2 方案,请参阅 Android N 开发者预览版中的 <a href="https://developer.android.com/about/versions/nougat/android-7.0.html#apk_signature_v2">APK 签名方案 v2</a>。
+</p>
+<p>在验证期间,v2 方案会将 APK 文件视为 Blob,并对整个文件进行签名检查。对 APK 进行的任何修改(包括对 ZIP 元数据进行的修改)都会使 APK 签名作废。这种形式的 APK 验证不仅速度要快得多,而且能够发现更多种未经授权的修改。
+</p>
+<p>新的签名格式向后兼容,因此,使用这种新格式签名的 APK 可在更低版本的 Android 设备上进行安装(会直接忽略添加到 APK 的额外数据),但前提是这些 APK 还带有 v1 签名。
+</p>
+<p>
+ <img src="../images/apk-validation-process.png" alt="APK 签名验证过程" id="figure1"/>
+</p>
+<p class="img-caption"><strong>图 1.</strong> APK 签名验证过程(新步骤以红色显示)</p>
+
+<p>验证程序会对照存储在“APK 签名分块”中的 v2 签名对 APK 的全文件哈希进行验证。该哈希涵盖除“APK 签名分块”(其中包含 v2 签名)之外的所有内容。在“APK 签名分块”以外对 APK 进行的任何修改都会使 APK 的 v2 签名作废。v2 签名被删除的 APK 也会被拒绝,因为 v1 签名指明相应 APK 带有 v2 签名,所以 Android Nougat 及更高版本会拒绝使用 v1 签名验证 APK。
+</p>
+
+<p>如需关于 APK 签名验证过程的详细信息,请参阅 APK 签名方案 v2 的<a href="v2.html#verification">“验证”部分</a>。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/apksigning/v2.html b/zh-cn/security/apksigning/v2.html
new file mode 100644
index 00000000..ac12e74a
--- /dev/null
+++ b/zh-cn/security/apksigning/v2.html
@@ -0,0 +1,223 @@
+<html devsite><head>
+ <title>APK 签名方案 v2</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>APK 签名方案 v2 是一种全文件签名方案,该方案能够发现对 APK 的受保护部分进行的所有更改,从而有助于加快验证速度并<a href="#integrity-protected-contents">增强完整性保证</a>。</p>
+
+<p>使用 APK 签名方案 v2 进行签名时,会在 APK 文件中插入一个 <a href="#apk-signing-block">APK 签名分块</a>,该分块位于“ZIP 中央目录”部分之前并紧邻该部分。在“APK 签名分块”内,v2 签名和签名者身份信息会存储在 <a href="#apk-signature-scheme-v2-block">APK 签名方案 v2 分块</a>中。
+</p>
+
+<p>
+ <img src="../images/apk-before-after-signing.png" alt="签名前和签名后的 APK" id="figure1"/>
+</p>
+<p class="img-caption"><strong>图 1.</strong> 签名前和签名后的 APK</p>
+
+<p>APK 签名方案 v2 是在 Android 7.0 (Nougat) 中引入的。为了使 APK 可在 Android 6.0 (Marshmallow) 及更低版本的设备上安装,应先使用 <a href="index.html#v1">JAR 签名</a>功能对 APK 进行签名,然后再使用 v2 方案对其进行签名。
+</p>
+
+<h2 id="apk-signing-block">APK 签名分块</h2>
+<p>为了保持与当前 APK 格式向后兼容,v2 及更高版本的 APK 签名会存储在“APK 签名分块”内,该分块是为了支持 APK 签名方案 v2 而引入的一个新容器。在 APK 文件中,“APK 签名分块”位于“ZIP 中央目录”(位于文件末尾)之前并紧邻该部分。
+</p>
+
+<p>该分块包含多个“ID-值”对,所采用的封装方式有助于更轻松地在 APK 中找到该分块。APK 的 v2 签名会存储为一个“ID-值”对,其中 ID 为 0x7109871a。
+</p>
+
+<h3 id="apk-signing-block-format">格式</h3>
+<p>“APK 签名分块”的格式如下(所有数字字段均采用小端字节序):</p>
+
+<ul>
+ <li><code>size of block</code>,以字节数(不含此字段)计 (uint64)</li>
+ <li>带 uint64 长度前缀的“ID-值”对序列:<ul>
+ <li><code>ID</code> (uint32)</li>
+ <li><code>value</code>(可变长度:“ID-值”对的长度 - 4 个字节)</li>
+ </ul>
+ </li>
+ <li><code>size of block</code>,以字节数计 - 与第一个字段相同 (uint64)</li>
+ <li><code>magic</code> APK 签名分块 42(16 个字节)</li>
+</ul>
+
+<p>在解析 APK 时,首先要通过以下方法找到“ZIP 中央目录”的起始位置:在文件末尾找到“ZIP 中央目录结尾”记录,然后从该记录中读取“中央目录”的起始偏移量。通过 <code>magic</code> 值,可以快速确定“中央目录”前方可能是“APK 签名分块”。然后,通过 <code>size of
+block</code> 值,可以高效地找到该分块在文件中的起始位置。
+</p>
+
+<p>在解译该分块时,应忽略 ID 未知的“ID-值”对。
+</p>
+
+<h2 id="apk-signature-scheme-v2-block">APK 签名方案 v2 分块</h2>
+<p>APK 由一个或多个签名者/身份签名,每个签名者/身份均由一个签名密钥来表示。该信息会以“APK 签名方案 v2 分块”的形式存储。对于每个签名者,都会存储以下信息:</p>
+
+<ul>
+ <li>(签名算法、摘要、签名)元组。摘要会存储起来,以便将签名验证和 APK 内容完整性检查拆开进行。</li>
+ <li>表示签名者身份的 X.509 证书链。</li>
+ <li>采用键值对形式的其他属性。</li>
+</ul>
+
+<p>对于每位签名者,都会使用收到的列表中支持的签名来验证 APK。签名算法未知的签名会被忽略。如果遇到多个支持的签名,则由每个实现来选择使用哪个签名。这样一来,以后便能够以向后兼容的方式引入安全系数更高的签名方法。建议的方法是验证安全系数最高的签名。
+</p>
+
+<h3 id="apk-signature-scheme-v2-block-format">格式</h3>
+<p>“APK 签名方案 v2 分块”存储在“APK 签名分块”内,ID 为 <code>0x7109871a</code>。
+</p>
+
+<p>“APK 签名方案 v2 分块”的格式如下(所有数字值均采用小端字节序,所有带长度前缀的字段均使用 uint32 值表示长度):</p>
+<ul>
+ <li>带长度前缀的 <code>signer</code>(带长度前缀)序列:<ul>
+ <li>带长度前缀的 <code>signed data</code>:<ul>
+ <li>带长度前缀的 <code>digests</code>(带长度前缀)序列:<ul>
+ <li><code>signature algorithm ID</code> (uint32)</li>
+ <li>(带长度前缀)<code>digest</code> - 请参阅<a href="#integrity-protected-contents">受完整性保护的内容</a></li>
+ </ul>
+ </li>
+ <li>带长度前缀的 X.509 <code>certificates</code> 序列:<ul>
+ <li>带长度前缀的 X.509 <code>certificate</code>(ASN.1 DER 形式)</li>
+ </ul>
+ </li>
+ <li>带长度前缀的 <code>additional attributes</code>(带长度前缀)序列:<ul>
+ <li><code>ID</code> (uint32)</li>
+ <li><code>value</code>(可变长度:附加属性的长度 - 4 个字节)</li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>带长度前缀的 <code>signatures</code>(带长度前缀)序列:<ul>
+ <li><code>signature algorithm ID</code> (uint32)</li>
+ <li><code>signed data</code> 上带长度前缀的 <code>signature</code></li>
+ </ul>
+ </li>
+ <li>带长度前缀的 <code>public key</code>(SubjectPublicKeyInfo,ASN.1 DER 形式)</li>
+ </ul>
+ </li>
+</ul>
+
+<h4 id="signature-algorithm-ids">签名算法 ID</h4>
+<ul>
+ <li>0x0101 - 采用 SHA2-256 摘要、SHA2-256 MGF1、32 个字节的盐且尾部为 0xbc 的 RSASSA-PSS 算法</li>
+ <li>0x0102 - 采用 SHA2-512 摘要、SHA2-512 MGF1、64 个字节的盐且尾部为 0xbc 的 RSASSA-PSS 算法</li>
+ <li>0x0103 - 采用 SHA2-256 摘要的 RSASSA-PKCS1-v1_5 算法。此算法适用于需要确定性签名的编译系统。</li>
+ <li>0x0104 - 采用 SHA2-512 摘要的 RSASSA-PKCS1-v1_5 算法。此算法适用于需要确定性签名的编译系统。</li>
+ <li>0x0201 - 采用 SHA2-256 摘要的 ECDSA 算法</li>
+ <li>0x0202 - 采用 SHA2-512 摘要的 ECDSA 算法</li>
+ <li>0x0301 - 采用 SHA2-256 摘要的 DSA 算法</li>
+</ul>
+
+<p>Android 平台支持上述所有签名算法。签名工具可能只支持其中一部分算法。
+</p>
+
+<p>
+<strong>支持的密钥大小和 EC 曲线:</strong>
+</p>
+
+<ul>
+ <li>RSA:1024、2048、4096、8192、16384</li>
+ <li>EC:NIST P-256、P-384、P-521</li>
+ <li>DSA:1024、2048、3072</li>
+</ul>
+
+<h2 id="integrity-protected-contents">受完整性保护的内容</h2>
+
+<p>为了保护 APK 内容,APK 包含以下 4 个部分:</p>
+
+<ol>
+ <li>ZIP 条目的内容(从偏移量 0 处开始一直到“APK 签名分块”的起始位置)</li>
+ <li>APK 签名分块</li>
+ <li>ZIP 中央目录</li>
+ <li>ZIP 中央目录结尾</li>
+</ol>
+
+<p>
+ <img src="../images/apk-sections.png" alt="签名后的各个 APK 部分" id="figure2"/>
+</p>
+<p class="img-caption"><strong>图 2.</strong> 签名后的各个 APK 部分</p>
+
+<p>APK 签名方案 v2 负责保护第 1、3、4 部分的完整性,以及第 2 部分包含的“APK 签名方案 v2 分块”中的 <code>signed data</code> 分块的完整性。
+</p>
+
+<p>第 1、3 和 4 部分的完整性通过其内容的一个或多个摘要来保护,这些摘要存储在 <code>signed data</code> 分块中,而这些分块则通过一个或多个签名来保护。
+</p>
+
+<p>第 1、3 和 4 部分的摘要采用以下计算方式,类似于两级 <a href="https://en.wikipedia.org/wiki/Merkle_tree">Merkle 树</a>。每个部分都会被拆分成多个大小为 1 MB(2<sup>20</sup> 个字节)的连续块。每个部分的最后一个块可能会短一些。每个块的摘要均通过字节 <code>0xa5</code> 的连接、块的长度(采用小端字节序的 uint32 值,以字节数计)和块的内容进行计算。顶级摘要通过字节 <code>0x5a</code> 的连接、块数(采用小端字节序的 uint32 值)以及块的摘要的连接(按照块在 APK 中显示的顺序)进行计算。摘要以分块方式计算,以便通过并行处理来加快计算速度。
+</p>
+
+<p>
+ <img src="../images/apk-integrity-protection.png" alt="APK 摘要" id="figure3"/>
+</p>
+<p class="img-caption"><strong>图 3.</strong> APK 摘要</p>
+
+<p>由于第 4 部分(ZIP 中央目录结尾)包含“ZIP 中央目录”的偏移量,因此该部分的保护比较复杂。当“APK 签名分块”的大小发生变化(例如,添加了新签名)时,偏移量也会随之改变。因此,在通过“ZIP 中央目录结尾”计算摘要时,必须将包含“ZIP 中央目录”偏移量的字段视为包含“APK 签名分块”的偏移量。
+</p>
+
+<h2 id="rollback-protections">防回滚保护</h2>
+<p>攻击者可能会试图在支持对带 v2 签名的 APK 进行验证的 Android 平台上将带 v2 签名的 APK 作为带 v1 签名的 APK 进行验证。为了防范此类攻击,带 v2 签名的 APK 如果还带 v1 签名,其 META-INF/*.SF 文件的主要部分中必须包含 X-Android-APK-Signed 属性。该属性的值是一组以英文逗号分隔的 APK 签名方案 ID(v2 方案的 ID 为 2)。在验证 v1 签名时,对于此组中验证程序首选的 APK 签名方案(例如,v2 方案),如果 APK 没有相应的签名,APK 验证程序必须要拒绝这些 APK。此项保护依赖于内容 META-INF/*.SF 文件受 v1 签名保护这一事实。请参阅 <a href="#v1-verification">JAR 已签名的 APK 的验证</a>部分。
+</p>
+
+<p>攻击者可能会试图从“APK 签名方案 v2 分块”中删除安全系数较高的签名。为了防范此类攻击,对 APK 进行签名时使用的签名算法 ID 的列表会存储在通过各个签名保护的 <code>signed data</code> 分块中。
+</p>
+
+<h2 id="verification">验证</h2>
+
+<p>在 Android 7.0 中,可以根据 APK 签名方案 v2(v2 方案)或 JAR 签名(v1 方案)验证 APK。更低版本的平台会忽略 v2 签名,仅验证 v1 签名。
+</p>
+
+<p>
+ <img src="../images/apk-validation-process.png" alt="APK 签名验证过程" id="figure4"/>
+</p>
+<p class="img-caption"><strong>图 4.</strong> APK 签名验证过程(新步骤以红色显示)</p>
+
+<h3 id="v2-verification">APK 签名方案 v2 验证</h3>
+<ol>
+ <li>找到“APK 签名分块”并验证以下内容:<ol>
+ <li>“APK 签名分块”的两个大小字段包含相同的值。</li>
+ <li>“ZIP 中央目录”紧跟在“ZIP 中央目录结尾”记录后面。</li>
+ <li>“ZIP 中央目录结尾”之后没有任何数据。</li>
+ </ol>
+ </li>
+ <li>找到“APK 签名分块”中的第一个“APK 签名方案 v2 分块”。如果 v2 分块存在,则继续执行第 3 步。否则,回退至<a href="#v1-verification">使用 v1 方案</a>验证 APK。</li>
+ <li>对“APK 签名方案 v2 分块”中的每个 <code>signer</code> 执行以下操作:<ol>
+ <li>从 <code>signatures</code> 中选择安全系数最高的受支持 <code>signature algorithm ID</code>。安全系数排序取决于各个实现/平台版本。</li>
+ <li>使用 <code>public
+ key</code> 并对照 <code>signed data</code> 验证 <code>signatures</code> 中对应的 <code>signature</code>。(现在可以安全地解析 <code>signed data</code> 了。)</li>
+ <li>验证 <code>digests</code> 和 <code>signatures</code> 中的签名算法 ID 列表(有序列表)是否相同。(这是为了防止删除/添加签名。)</li>
+ <li>使用签名算法所用的同一种摘要算法<a href="#integrity-protected-contents">计算 APK 内容的摘要</a>。</li>
+ <li>验证计算出的摘要是否与 <code>digests</code> 中对应的 <code>digest</code> 相同。</li>
+ <li>验证 <code>certificates</code> 中第一个 <code>certificate</code> 的 SubjectPublicKeyInfo 是否与 <code>public key</code> 相同。</li>
+ </ol>
+ </li>
+ <li>如果找到了至少一个 <code>signer</code>,并且对于每个找到的 <code>signer</code>,第 3 步都取得了成功,APK 验证将会成功。</li>
+</ol>
+
+<p class="note"><strong>注意</strong>:如果第 3 步或第 4 步失败了,则不得使用 v1 方案验证 APK。
+</p>
+
+<h3 id="v1-verification">JAR 已签名的 APK 的验证(v1 方案)</h3>
+<p>JAR 已签名的 APK 是一种<a href="https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Signed_JAR_File">标准的已签名 JAR</a>,其中包含的条目必须与 META-INF/MANIFEST.MF 中列出的条目完全相同,并且所有条目都必须已由同一组签名者签名。其完整性按照以下方式进行验证:</p>
+
+<ol>
+ <li>每个签名者均由一个包含 META-INF/&lt;signer&gt;.SF 和 META-INF/&lt;signer&gt;.(RSA|DSA|EC) 的 JAR 条目来表示。</li>
+ <li>&lt;signer&gt;.(RSA|DSA|EC) 是<a href="https://tools.ietf.org/html/rfc5652">具有 SignedData 结构的 PKCS #7 CMS ContentInfo</a>,其签名通过 &lt;signer&gt;.SF 文件进行验证。</li>
+ <li>&lt;signer&gt;.SF 文件包含 META-INF/MANIFEST.MF 的全文件摘要和 META-INF/MANIFEST.MF 各个部分的摘要。需要验证 MANIFEST.MF 的全文件摘要。如果该验证失败,则改为验证 MANIFEST.MF 各个部分的摘要。</li>
+ <li>对于每个受完整性保护的 JAR 条目,META-INF/MANIFEST.MF 都包含一个具有相应名称的部分,其中包含相应条目未压缩内容的摘要。所有这些摘要都需要验证。</li>
+ <li>如果 APK 包含未在 MANIFEST.MF 中列出且不属于 JAR 签名一部分的 JAR 条目,APK 验证将会失败。</li>
+</ol>
+
+<p>因此,保护链是每个受完整性保护的 JAR 条目的 &lt;signer&gt;.(RSA|DSA|EC) -&gt; &lt;signer&gt;.SF -&gt; MANIFEST.MF -&gt; 内容。
+</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/authentication/fingerprint-hal.html b/zh-cn/security/authentication/fingerprint-hal.html
new file mode 100644
index 00000000..9422812e
--- /dev/null
+++ b/zh-cn/security/authentication/fingerprint-hal.html
@@ -0,0 +1,107 @@
+<html devsite><head>
+ <title>Fingerprint HAL</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="overview">概述</h2>
+
+<p>如果设备配有指纹传感器,用户就可以注册一个或多个指纹,然后使用自己的指纹来解锁设备以及执行其他任务。</p>
+
+<p>Android 会利用 Fingerprint 硬件抽象层 (HAL) 连接到供应商专用库和指纹硬件,例如指纹传感器。</p>
+
+<p>要实现 Fingerprint HAL,您必须在某个供应商专用库中实现 <code>fingerprint.h</code> (<code>/hardware/libhardware/include/hardware/fingerprint.h</code>) 中的<a href="#major_functions_in_the_fingerprint_hal">函数</a>;请参阅 <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/fingerprint.h"><code>fingerprint.h</code></a> 文件中的备注。</p>
+
+<h3 id="fingerprint_matching_flow">指纹匹配流程</h3>
+
+<p>下文概要介绍了指纹匹配流程。该流程假设设备上已经注册了一个指纹,即供应商专用库已为该指纹注册了一个模板。另请参阅<a href="index.html">身份验证</a>。</p>
+
+<p>设备的指纹传感器通常处于闲置状态。但为了响应对 <code>authenticate</code> 或 <code>enroll</code> 函数的调用,指纹传感器会监听触摸操作(并且屏幕可能会在用户触摸指纹传感器时被唤醒)。</p>
+
+<ol>
+ <li>当用户将手指放在指纹传感器上时,供应商专用库会根据当前的已注册模板集判断是否匹配。
+ </li><li>第 1 步的结果会传递到 Fingerprint HAL,后者会将指纹身份验证结果通知给 <code>fingerprintd</code>(Fingerprint 守护进程)。
+</li></ol>
+
+<p>请注意,单个设备上存储的模板越多,进行匹配所需的时间就越长。</p>
+
+<h2 id="architecture">架构</h2>
+
+<p><strong>Fingerprint HAL</strong> 会与以下组件交互:</p>
+
+<ul>
+ <li><strong>FingerprintManager API</strong>:会在应用进程中与应用直接交互。
+ <ul>
+ <li>每个应用都有一个 FingerprintManager 实例。
+ </li><li>FingerprintManager 是与 FingerprintService 进行通信的封装容器。
+ </li></ul>
+ </li><li><strong>FingerprintService</strong>:在系统进程中运行的单例服务,可处理与 <code>fingerprintd</code> 之间的通信。
+ </li><li><strong>fingerprintd(Fingerprint 守护进程)</strong>:FingerprintService 中 Binder 界面的 C/C++ 实现。<code>fingerprintd</code> 守护进程在自己的进程中运行,并会封装 Fingerprint HAL 供应商专用库。
+ </li><li><strong>Fingerprint HAL 供应商专用库</strong>:硬件供应商的 Fingerprint HAL 实现。供应商专用库能够与设备专用硬件进行通信。
+ </li><li><strong>Keystore API 和 Keymaster</strong>:这两种组件可以提供由硬件支持的加密功能,以便在可信执行环境 (TEE) 中安全地存储密钥。
+</li></ul>
+
+<p>如下图所示,供应商专用 HAL 实现需要使用 TEE 要求的通信协议。</p>
+
+<img src="../images/fingerprint-data-flow.png" alt="指纹身份验证的数据流程" id="figure1"/>
+
+<p class="img-caption"><strong>图 1. </strong> 指纹身份验证的概要数据流程</p>
+
+<p>因此,不得将原始图片和处理后的指纹特征传递到不可信内存中。所有此类生物识别数据都需要安全地存储在传感器硬件或可信内存中。(TEE 中的内存被视为可信内存,TEE 之外的内存则被视为不可信内存。)</p>
+
+<p>获取 Root 权限不得损坏生物识别数据。</p>
+
+<p>如下图所示,<code>fingerprintd</code> 会通过 Fingerprint HAL 调用供应商专用库,以便注册指纹以及执行其他操作。</p>
+
+<img src="../images/fingerprint-daemon.png" alt="与 fingerprintd 交互" id="figure2"/>
+<p class="img-caption"><strong>图 2. </strong> Fingerprint 守护进程 (<code>fingerprintd</code>) 与 Fingerprint 供应商专用库之间的交互</p>
+
+<h2 id="fingerprint_implementation_guidelines">Fingerprint 实现准则</h2>
+
+<p>本部分中的准则旨在确保:</p>
+
+<ul>
+ <li>指纹数据不会被泄露</li><li>从设备中移除用户时,一并移除指纹数据</li></ul>
+
+<p>以下是具体准则:</p>
+
+<ol>
+ <li>必须要确保在任何情况下都无法从传感器驱动程序或可信执行环境 (TEE) 以外访问原始指纹数据或衍生内容(例如模板)。只能将硬件访问权限授予 TEE(如果硬件支持它的话),并且必须通过 SELinux 政策对硬件访问权限加以保护。也就是说,串行外设接口 (SPI) 渠道必须只能供 TEE 访问,并且必须有针对所有设备文件的明确 SELinux 政策。
+ </li><li>指纹采集、注册和识别必须在 TEE 内部进行。</li><li>只有加密形式的指纹数据可以存储在文件系统中(即使文件系统本身已加密)。
+ </li><li>指纹模板必须已通过设备专用私钥(例如 AES 密钥)签名,并且必须至少包含绝对文件系统路径、群组和指纹 ID,这样一来,相应模板文件便无法在其他设备上使用,并且无法用于在同一设备上注册的任何其他用户。例如,您将无法复制同一设备上其他用户的指纹数据,也无法从其他设备复制指纹数据。
+ </li><li>实现必须使用 <code>set_active_group()</code> 函数提供的文件系统路径,或提供一种能够在移除用户时一并清空所有用户模板数据的方法。强烈建议将指纹模板文件以加密形式存储在提供的路径中。如果因 TEE 存储要求导致这种做法不可行,实现人员必须添加一些钩子,以确保在移除用户时一并移除相关数据。
+</li></ol>
+
+<h2 id="major_functions_in_the_fingerprint_hal">Fingerprint HAL 中的主要函数</h2>
+
+<p>以下是 <code>/hardware/libhardware/include/hardware/fingerprint.h</code> 文件中的主要函数。您可以查看该文件中的详细说明。</p>
+
+<ul>
+ <li><strong>enroll:</strong> 将 HAL 状态机切换到开始收集和存储指纹模板的状态。注册完成后或超时后,HAL 状态机会立即返回到闲置状态。
+ </li><li><strong>pre_enroll:</strong> 生成一个独一无二的令牌,以指明指纹注册已开始。为 <code>enroll</code> 函数提供令牌,以确保事先已经过身份验证(例如使用密码)。一旦确认了设备凭据,便会开始封装令牌并对其进行相应的处理(例如,进行 HMAC 处理),以防被篡改。在注册期间必须检查令牌,以确认令牌仍然有效。
+ </li><li><strong>get_authenticator_id:</strong> 返回与当前指纹集关联的令牌。
+ </li><li><strong>cancel:</strong> 取消所有待处理的注册或验证操作。HAL 状态机会返回到闲置状态。
+ </li><li><strong>enumerate:</strong> 同步调用,用于枚举所有已知指纹模板。
+ </li><li><strong>remove:</strong> 删除指纹模板。
+ </li><li><strong>set_active_group:</strong> 限定只能对属于指定群组(通过群组标识符 (GID) 来标识)的指纹集执行某项 HAL 操作。
+ </li><li><strong>authenticate:</strong> 验证与指纹相关的操作(通过操作 ID 来标识)。
+ </li><li><strong>set_notify:</strong> 注册将从 HAL 获得通知的用户函数。如果 HAL 状态机处于繁忙状态,该函数会被屏蔽,直到 HAL 不再处于繁忙状态为止。
+</li></ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/authentication/gatekeeper.html b/zh-cn/security/authentication/gatekeeper.html
new file mode 100644
index 00000000..f8463fe1
--- /dev/null
+++ b/zh-cn/security/authentication/gatekeeper.html
@@ -0,0 +1,106 @@
+<html devsite><head>
+ <title>Gatekeeper</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="overview">概述</h2>
+
+<p>Gatekeeper 子系统会在可信执行环境 (TEE) 中执行设备解锁图案/密码身份验证。Gatekeeper 会使用由硬件支持的密钥通过 HMAC 注册和验证密码。此外,Gatekeeper 会限制连续失败的验证尝试次数,并且必须根据指定的超时和指定的连续失败尝试次数拒绝服务请求。</p>
+
+<p>当用户验证其密码时,Gatekeeper 会使用 TEE 派生的共享密钥对身份验证认证签名,以发送至<a href="/security/keystore/index.html">由硬件支持的 Keystore</a>。也就是说,Gatekeeper 认证可让 Keystore 知道可以发布与身份验证绑定的密钥(例如,应用创建的密钥)供应用使用了。</p>
+
+<h2 id="architecture">架构</h2>
+
+<p>Gatekeeper 包括以下 3 个主要组件:</p>
+
+<ul>
+ <li><strong>gatekeeperd(Gatekeeper 守护进程)</strong>。
+一种 C++ Binder 服务,其中包含独立于平台的逻辑,并且与 <code>GateKeeperService</code> Java 接口相对应。
+ </li><li><strong>Gatekeeper 硬件抽象层 (HAL)</strong>。
+<code>hardware/libhardware/include/hardware/gatekeeper.h</code> 中的 HAL 接口,是一个实现模块。
+ </li><li><strong>Gatekeeper (TEE)</strong>。
+<code>gatekeeperd</code> 的 TEE 副本。基于 TEE 的 Gatekeeper 实现。
+</li></ul>
+
+<p>实现 Gatekeeper:</p>
+
+<ul>
+ <li>实现 Gatekeeper HAL,具体来说就是实现 <code>gatekeeper.h</code> (<code>hardware/libhardware/include/hardware/gatekeeper.h</code>) 中的函数。请参阅 <a href="#hal_implementation">HAL 实现</a>。
+ </li><li>实现 TEE 特有的 Gatekeeper 组件,部分基于以下标头文件:<code>system/gatekeeper/include/gatekeeper/gatekeeper.h</code>。该标头文件中包括用于创建和访问密钥以及用于计算签名的纯虚函数。请参阅 <a href="#trusty_and_other_implementations">Trusty 和其他实现</a>。
+</li></ul>
+
+<p>如下图所示,<code>LockSettingsService</code> 会通过 Binder 发出一个请求,该请求会到达 Android 操作系统中的 <code>gatekeeperd</code> 守护进程。<code>gatekeeperd</code> 守护进程会发出一个请求,该请求会到达此守护进程在 TEE 中的副本 (Gatekeeper)。</p>
+
+<img src="../images/gatekeeper-flow.png" alt="Gatekeeper 流程" id="figure1"/>
+<p class="img-caption"><strong>图 1.</strong> GateKeeper 进行身份验证的概要数据流程</p>
+
+<p><code>gatekeeperd</code> 守护进程会向 Android 框架 API 授予访问 HAL 的权限,并且会参与向 Keystore 报告设备<a href="index.html">身份验证</a>的活动。<code>gatekeeperd</code> 守护进程会在自己的进程中运行,与系统服务器隔离开来。</p>
+
+<h2 id="hal_implementation">HAL 实现</h2>
+
+<p><code>gatekeeperd</code> 守护进程会利用 HAL 同 <code>gatekeeperd</code> 守护进程的 TEE 副本进行交互,以进行密码身份验证。HAL 实现必须能够签署(注册)和验证 Blob。所有实现都需要遵循每次密码验证成功时生成的身份验证令牌 (AuthToken) 的标准格式。AuthToken 的内容和语义在<a href="index.html">身份验证</a>中进行了介绍。</p>
+
+<p>具体来说就是,要实现 <code>gatekeeper.h</code> 标头文件(位于 <code>hardware/libhardware/include/hardware</code> 文件夹中),需要实现 <code>enroll</code> 和 <code>verify</code> 函数。</p>
+
+<p><code>enroll</code> 函数会获取一个密码 Blob,为其签名,并以句柄的形式返回签名。返回的 Blob(通过调用 <code>enroll</code>)必须有 <code>system/gatekeeper/include/gatekeeper/password_handle.h</code> 中显示的结构。</p>
+
+<p><code>verify</code> 函数需要将通过收到的密码生成的签名与注册的密码句柄进行比较,并确认两者是否一致。</p>
+
+<p>用于注册和验证的密钥不得更改,并且应该可以在每次设备启动时重新派生。</p>
+
+<h2 id="trusty_and_other_implementations">Trusty 和其他实现</h2>
+
+<p><a href="/security/trusty/index.html">Trusty</a> 操作系统是 Google 的开放源代码信任的操作系统,适用于 TEE 环境。Trusty 中包含一个经过批准的 GateKeeper 实现。不过,<strong>所有 TEE 操作系统</strong>均可用于实现 Gatekeeper。TEE <strong>必须</strong>有权访问一个由硬件支持的密钥,以及一个安全的单调时钟(<strong>在暂停状态下运行</strong>)。</p>
+
+<p>Trusty 会使用内部 IPC 系统直接在 Keymaster 和 Trusty Gatekeeper(Gatekeeper 的 Trusty 实现)之间传达共享的密钥。这个共享的密钥用于签署将发送至 Keystore 的 AuthToken,以便提供密码验证认证。Trusty Gatekeeper 会在每次使用该密钥时向 Keymaster 请求该密钥,而不会保留或缓存该密钥的值。实现能够随意以不会降低安全性的任何方式共享该密钥。</p>
+
+<p>HMAC 密钥用于注册和验证密码,是派生的密钥,单独保存在 GateKeeper 中。</p>
+
+<p>Android 树提供了一种通用的 C++ 版本的 GateKeeper 实现,只需添加设备专用例程即可完成。要使用设备专用代码为您的 TEE 实现 TEE Gatekeeper,请参阅以下文件中的函数和命令:</p>
+<pre>
+system/gatekeeper/include/gatekeeper/gatekeeper.h
+</pre>
+
+<p>对于 TEE GateKeeper,合规实现的主要责任有:</p>
+
+<ul>
+ <li>遵循 Gatekeeper HAL</li><li>返回的 AuthTokens 的格式必须符合 AuthToken 规范(在<a href="index.html">身份验证</a>中进行了介绍)</li><li>TEE Gatekeeper 必须能够通过以下方法与 Keymaster 共享 HMAC 密钥:按需通过 TEE IPC 请求密钥,或始终维护密钥值的有效缓存</li></ul>
+
+<h2 id="user_sids">用户 SID</h2>
+
+<p>用户安全 ID(用户 SID)是用户的 TEE 代码。用户 SID 与 Android 用户 ID 之间没有明显的关联。</p>
+
+<p>每当用户注册新密码时,如果未提供之前的密码,系统就会使用加密 PRNG 生成一个用户 SID。这称为“不可信”重新注册。如果用户提供了之前的有效密码,便会发生“可信”重新注册。在这种情况下,用户 SID 会迁移到新密码句柄,从而保留绑定到它的密钥。在一般情况下,Android 框架不允许进行“不可信”重新注册。</p>
+
+<p>注册密码时,用户 SID 会随密码句柄中的密码一起接受 HMAC 处理。</p>
+
+<p>用户 SID 会写入到 <code>verify</code> 函数返回的 AuthToken 中,并且会同所有与身份验证绑定的 Keystore 密钥相关联。如需关于 AuthToken 格式和 Keystore 的更多信息,请参阅<a href="index.html">身份验证</a>。由于对 <code>enroll</code> 函数的不可信调用会更改用户 SID,因此此类调用会使绑定到相应密码的密钥无法再使用。</p>
+
+<p>攻击者在控制 Android 操作系统后可以更改设备密码,但在此过程中,他们需要破坏掉受 Root 保护的敏感密钥。</p>
+
+<h2 id="request_throttling">请求次数限制</h2>
+
+<p>GateKeeper 必须能够安全地限制对用户凭据进行暴力破解的尝试次数。如 <code>gatekeeper.h</code> 文件(位于 <code>hardware/libhardware/include/hardware</code> 中)中所示,HAL 能够返回一个超时(以毫秒数计)。超时旨在通知客户端在超时过去之前不要再次调用 GateKeeper。如果有待处理的超时,GateKeeper 不应处理相关请求。</p>
+
+<p>Gatekeeper 必须先编写一个失败计数器,然后再验证用户密码。如果密码验证成功,则应清除失败计数器。这可以在发出 <code>verify</code> 调用后防止攻击者发起以下攻击:通过停用嵌入式 MMC (eMMC) 来阻止请求次数限制。此外,<code>enroll</code> 函数还会验证用户密码(如果提供了),因此必须以同样的方式对其加以限制。</p>
+
+<p>如果设备支持,强烈建议将失败计数器写入到安全存储空间。如果设备不支持文件级加密,或如果安全存储空间的速度过慢,实现可以直接使用 RPMB。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/authentication/index.html b/zh-cn/security/authentication/index.html
new file mode 100644
index 00000000..4c52e0a0
--- /dev/null
+++ b/zh-cn/security/authentication/index.html
@@ -0,0 +1,166 @@
+<html devsite><head>
+ <title>身份验证</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="overview">概述</h2>
+
+<p>Android 6.0 中引入了通过用户身份验证把关的加密密钥的概念。为了实现这一概念,需要两种关键组件协同运作。一种是加密密钥存储和服务提供程序,用于存储加密密钥并提供基于加密密钥的标准加密例程。另一种是任意数量的用户身份验证程序,用于证明相应用户存在并/或已成功通过身份验证。</p>
+
+<p>Android 中的加密密钥存储功能由 Keystore 服务和 Keymaster 提供。(另请参阅由 Keystore 服务提供支持的框架级 <a href="https://developer.android.com/training/articles/keystore.html">Android Keystore 系统</a>的相关信息。)对于 Android 6.0,两个受支持的身份验证组件是 Gatekeeper(用于 PIN 码/解锁图案/密码身份验证)和 Fingerprint(用于指纹身份验证)。这两个组件会通过已经过身份验证的渠道与 Keystore 服务沟通身份验证状态。</p>
+
+<ul>
+ <li><strong><a href="/security/keystore/index.html">由硬件支持的 Keystore</a>:</strong>加密服务(其中包括由硬件支持的密钥存储加密服务),可能包括可信执行环境 (TEE)。</li>
+ <li><strong><a href="gatekeeper.html">Gatekeeper</a>:</strong> 用于进行 PIN 码、解锁图案和密码身份验证的组件。</li>
+ <li><strong><a href="fingerprint-hal.html">Fingerprint</a>:</strong> 用于进行指纹身份验证的组件。</li>
+</ul>
+
+<h2 id="architecture">架构</h2>
+
+<p>Gatekeeper 和 Fingerprint 组件能够与 Keystore 及其他组件协同运作,以便支持使用由硬件支持的<a href="#authentication_token_format">身份验证令牌</a>(以下称为“AuthToken”)。</p>
+
+<h3 id="enrollment">注册</h3>
+
+<p>在设备恢复出厂设置后首次启动时,所有身份验证程序均会做好接受用户进行凭据注册的准备。</p>
+
+<p>用户必须先通过 Gatekeeper 注册 PIN 码/解锁图案/密码。这项初始注册会创建一个随机生成的 64 位用户 SID(用户安全标识符,下文中对此进行了介绍),该用户 SID 将用作用户的标识符以及用户加密材料的绑定令牌。该用户 SID 会以加密形式绑定到用户的密码。如下文中详细介绍的,成功通过 Gatekeeper 的身份验证后,将会为相应密码生成包含用户 SID 的 AuthToken。</p>
+
+<p>用户要更改凭据时,必须提供现有凭据。如果现有凭据成功通过验证,与现有凭据关联的用户 SID 将转移到新凭据。这让用户在更改凭据后能够继续访问自己的密钥。如果用户未提供现有凭据,系统会为其注册一个新凭据,其中包含一个完全随机的用户 SID。用户可以访问设备,但会永久丢失基于旧用户 SID 创建的密钥。这种情况称为“不可信注册”。</p>
+
+<p>请注意,在一般情况下,Android 框架不允许进行不可信注册,因此大多数用户根本看不到此功能。不过,如果设备管理员或攻击者强制重置密码,则可能会导致发生这种情况。</p>
+
+<h3 id="authentication">身份验证</h3>
+
+<p>现在,用户已设置凭据并收到了用户 SID,接下来就可以开始进行身份验证了。</p>
+
+<p>在下图中,用户提供 PIN 码、解锁图案、密码或指纹后,身份验证过程便开始了。所有 TEE 组件都共用一个密钥来验证对方的消息。</p>
+
+<img src="../images/authentication-flow.png" alt="身份验证流程" id="figure1"/>
+<p class="img-caption"><strong>图 1. </strong> 身份验证流程</p>
+
+<p>以下步骤中的数字对应于上图中的数字,并包括对 Android 操作系统和 TEE 操作系统的引用:</p>
+
+<ol>
+ <li>用户提供 PIN 码、解锁图案、密码或指纹。<code>LockSettingsService</code> 或 <code>FingerprintService</code> 通过 Binder 向 Android 操作系统中的 Gatekeeperd 或 fingerprintd 守护进程发出请求。请注意,在指纹请求发出后,会异步发生指纹身份验证。
+ </li><li>该步骤涉及 <strong></strong>Gatekeeperd(下方选项 1)<strong>或</strong> fingerprintd(下方选项 2),具体取决于用户提供的是 PIN 码/解锁图案/密码还是指纹。
+ <ul>
+ <li>Gatekeeperd 守护进程将在第 1 步中收到的 PIN 码、解锁图案或密码哈希发送到它在 TEE 内的副本 (Gatekeeper)。如果 TEE 内的身份验证成功,TEE 内的 Gatekeeper 会将包含相应用户 SID 并且已使用 AuthToken HMAC 密钥签名的 AuthToken 发送到它在 Android 操作系统中的副本。</li><li>或者,监听指纹事件的 fingerprintd 守护进程将在第 1 步中收到的数据发送到它在 TEE 内的副本 (Fingerprint)。如果 TEE 内的身份验证成功,TEE 内的 Fingerprint 会将已使用 AuthToken HMAC 密钥签名的 AuthToken 发送到它在 Android 操作系统中的副本。</li></ul>
+ </li><li>Gatekeeperd 或 fingerprintd 守护进程收到经过签名的 AuthToken,并通过 Keystore 服务 Binder 接口的扩展程序将 AuthToken 传递到 Keystore 服务。此外,Gatekeeperd 会在设备被重新锁定以及设备密码发生变化时通知 Keystore 服务。
+ </li><li>Keystore 服务将从 Gatekeeperd 和 fingerprintd 收到的 AuthToken 传递给 Keymaster,以便使用与 Gatekeeper 和 Fingerprint Trustlet 共用的密钥验证 AuthToken。Keymaster 会将令牌中的时间戳视为最后一次身份验证的时间,并根据该时间戳做出密钥发布决定(以允许应用使用相应密钥)。
+</li></ol>
+
+<p class="note"><strong>注意</strong>:每当设备重新启动时,AuthToken 都会作废。</p>
+
+<h2 id="authentication_token_format">身份验证令牌格式</h2>
+
+<p>要共用令牌并在各种语言和组件之间实现兼容性,必须遵循 <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hw_auth_token.h"><code>hw_auth_token.h</code></a> 文件中说明的 AuthToken 格式。请参阅以下文件:</p>
+<pre>
+hardware/libhardware/include/hardware/hw_auth_token.h
+</pre>
+
+<p>下表中定义了一个简单序列化协议的必填字段。这些字段具有固定的大小。</p>
+
+<p>字段说明位于该表下方。</p>
+<table>
+ <tbody><tr>
+ <th><strong>字段</strong></th>
+ <th><strong>类型</strong></th>
+ <th><strong>必填还是选填</strong></th>
+ </tr>
+ <tr>
+ <td>AuthToken 版本</td>
+ <td>1 个字节</td>
+ <td>必填</td>
+ </tr>
+ <tr>
+ <td>质询</td>
+ <td>64 位未签名整数</td>
+ <td>选填</td>
+ </tr>
+ <tr>
+ <td>用户 SID</td>
+ <td>64 位未签名整数</td>
+ <td>必填</td>
+ </tr>
+ <tr>
+ <td>身份验证程序 ID</td>
+ <td>64 位未签名整数,按网络字节序保存</td>
+ <td>选填</td>
+ </tr>
+ <tr>
+ <td>身份验证程序类型</td>
+ <td>32 位未签名整数,按网络字节序保存</td>
+ <td>必填</td>
+ </tr>
+ <tr>
+ <td>时间戳</td>
+ <td>64 位未签名整数,按网络字节序保存</td>
+ <td>必填</td>
+ </tr>
+ <tr>
+ <td>AuthToken HMAC 密钥 (SHA-256)</td>
+ <td>256 位 Blob</td>
+ <td>必填</td>
+ </tr>
+</tbody></table>
+
+<h3 id="field_descriptions">字段说明</h3>
+
+<p>本部分对上方 AuthToken 表中的各个字段进行了说明。</p>
+
+<p><strong>AuthToken 版本</strong>:下方所有字段的组代码。</p>
+
+<p><strong>质询</strong>:一个随机整数,用于防范重放攻击。通常是所请求的加密操作的 ID,目前可供交易指纹授权使用。如果质询存在,AuthToken 仅对包含相应质询的加密操作有效。</p>
+
+<p><strong>用户 SID</strong>:不重复的用户标识符,以加密形式绑定到与设备身份验证关联的所有密钥。如需更多信息,请参阅 Gatekeeper 页面。</p>
+
+<p><strong>身份验证程序 ID (ASID)</strong>:绑定到特定身份验证程序政策时使用的标识符。所有身份验证程序都有自己的 ASID 值,它们可以根据自己的要求更改该值。</p>
+
+<p><strong>身份验证程序类型</strong>:Gatekeeper 或 Fingerprint,如下所示:</p>
+<table>
+ <tbody><tr>
+ <th><strong>身份验证程序类型</strong></th>
+ <th><strong>身份验证程序名称</strong></th>
+ </tr>
+ <tr>
+ <td>0x00</td>
+ <td>Gatekeeper</td>
+ </tr>
+ <tr>
+ <td>0x01</td>
+ <td>Fingerprint</td>
+ </tr>
+</tbody></table>
+
+<p><strong>时间戳</strong>:自最近一次系统启动以来已经过的时间(以毫秒数计)。</p>
+
+<p><strong>AuthToken HMAC 密钥</strong>:除 HMAC 字段以外所有字段的已加密 SHA-256 MAC。</p>
+
+<h2 id="device_boot_flow">设备启动流程</h2>
+
+<p>设备每次启动时,都必须生成 AuthToken HMAC 密钥并与所有 TEE 组件(Gatekeeper、Fingerprint 和 Keymaster)共用该密钥。因此,设备每次重新启动时都必须随机生成 HMAC 密钥,以便加强对重放攻击的防范力度。</p>
+
+<p>关于与所有组件共用此 HMAC 密钥的协议是一项依赖于平台的实现功能。<strong>在任何情况下都不能</strong>将该密钥设为可在 TEE 以外获得。因此,如果 TEE 操作系统缺少内部进程间通信 (IPC) 机制,并且 TEE 需要通过不可信操作系统传输数据,那么传输操作必须通过安全的密钥交换协议进行。</p>
+
+<p>与 Android 并排运行的 <a href="/security/trusty/index.html">Trusty</a> 操作系统就是一种 TEE,不过也可以使用其他 TEE。Trusty 使用内部 IPC 系统在 Keymaster 和 Fingerprint 或 Gatekeeper 之间直接进行通信。HMAC 密钥单独保存在 Keymaster 内。Fingerprint 和 Gatekeeper 会在每次使用该密钥时向 Keymaster 请求该密钥,而不会保留或缓存该密钥的值。</p>
+
+<p>请注意,TEE 中的小程序之间不会进行任何通信,因为 IPC 基础架构中缺少部分 TEE。这还使得 Keystore 服务因知晓系统内的身份验证表而能够快速拒绝注定会失败的请求,从而避免向 TEE 发送会占用大量处理能力的 IPC。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/bulletin/2017-06-01.html b/zh-cn/security/bulletin/2017-06-01.html
new file mode 100644
index 00000000..026af023
--- /dev/null
+++ b/zh-cn/security/bulletin/2017-06-01.html
@@ -0,0 +1,1268 @@
+<html devsite><head>
+ <title>Android 安全公告 - 2017 年 6 月</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+<p><em>发布时间:2017 年 6 月 5 日 | 更新时间:2017 年 6 月 7 日</em></p>
+
+<p>Android 安全公告详细介绍了会影响 Android 设备的安全漏洞。2017 年 6 月 5 日(或之后)的安全补丁程序级别均已解决所有这些问题。请参阅 <a href="https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices">Pixel 和 Nexus 更新时间表</a>,了解如何检查设备的安全补丁程序级别。</p>
+
+<p>我们的合作伙伴在至少一个月前就已收到本公告中说明的这些问题的相关通知。我们将在 Android 开放源代码项目 (AOSP) 代码库中发布针对相关问题的源代码补丁程序,并在本公告中提供相应链接。本公告还提供了 AOSP 之外的补丁程序的链接。</p>
+
+<p>这些问题中危险性最高的是媒体框架中的一个严重程度为“严重”的安全漏洞,在系统处理文件和数据时,该漏洞可让远程攻击者使用特制文件破坏内存。<a href="/security/overview/updates-resources.html#severity">严重程度评估</a>的依据是漏洞被利用后可能会对受影响设备造成的影响大小(假设相关平台和服务缓解措施被成功规避或出于开发目的而被关闭)。</p>
+
+<p>我们尚未收到用户因这些新报告的问题而遭到主动攻击或这些问题遭到滥用的报告。请参阅 <a href="#mitigations">Android 和 Google Play 保护机制缓解措施</a>部分,详细了解 <a href="/security/enhancements/index.html">Android 安全平台防护功能</a>和 <a href="https://www.android.com/play-protect">Google Play 保护机制</a>;这些功能可提高 Android 平台的安全性。</p>
+
+<p>我们建议所有用户都在自己的设备上接受这些更新。</p>
+
+<p class="note"><strong>注意</strong>:如需了解与最新的无线更新 (OTA) 和适用于 Google 设备的固件映像有关的信息,请参阅 <a href="#google-device-updates">Google 设备更新</a>部分。</p>
+
+<h2 id="announcements">公告</h2>
+<ul>
+ <li>我们简化了每月安全公告,以便于轻松阅读。在此次更新中,我们在各安全补丁程序级别内按受影响的组件对漏洞信息进行了分类并按组件名对漏洞信息进行了排序,同时将 Google 设备专属信息划分到了<a href="#google-device-updates">专门的部分</a>中。</li>
+ <li>本公告有两个安全补丁程序级别字符串,目的是让 Android 合作伙伴能够灵活地、更快速地修复所有 Android 设备上类似的一系列漏洞。如需了解详情,请参阅<a href="#common-questions-and-answers">常见问题和解答</a>:
+ <ul>
+ <li><strong>2017-06-01</strong>:部分安全补丁程序级别字符串。此安全补丁程序级别字符串表明与 2017-06-01(以及之前的所有安全补丁程序级别字符串)相关的所有问题均已得到解决。</li>
+ <li><strong>2017-06-05</strong>:完整的安全补丁程序级别字符串。此安全补丁程序级别字符串表明与 2017-06-01 和 2017-06-05(以及之前的所有安全补丁程序级别字符串)相关的所有问题均已得到解决。</li>
+ </ul>
+ </li>
+</ul>
+
+<h2 id="mitigations">Android 和 Google Play 保护机制缓解措施</h2>
+<p>本部分总结了 <a href="/security/enhancements/index.html">Android 安全平台</a>和服务防护功能(如 <a href="https://www.android.com/play-protect">Google Play 保护机制</a>)提供的缓解措施。这些功能可降低 Android 上的安全漏洞被成功利用的可能性。</p>
+<ul>
+ <li>新版 Android 平台中的增强功能让攻击者更加难以利用 Android 上存在的许多问题。我们建议所有用户都尽可能更新到最新版 Android。</li>
+ <li>Android 安全团队会积极利用 <a href="https://www.android.com/play-protect">Google Play 保护机制</a>来监控滥用行为,并在发现<a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">可能有害的应用</a>时向用户发出警告。在预装有 <a href="http://www.android.com/gms">Google 移动服务</a>的设备上,Google Play 保护机制在默认情况下处于启用状态。对于安装来自 Google Play 以外的应用的用户来说,这项功能尤为重要。</li>
+</ul>
+
+<h2 id="2017-06-01-details">2017-06-01 安全补丁程序级别 - 漏洞详情</h2>
+<p>我们在下面提供了 2017-06-01 补丁程序级别涵盖的每个安全漏洞的详细信息,漏洞列在受其影响的组件下,其中包括问题描述,以及一个包含 CVE、相关参考信息、<a href="#vulnerability-type">漏洞类型</a>、<a href="/security/overview/updates-resources.html#severity">严重程度</a>和已更新的 AOSP 版本(如果适用)的表格。在适用的情况下,我们会将 Bug ID 链接到解决相应问题的公开更改记录(如 AOSP 代码更改列表)。如果某个 Bug 有多条相关的更改记录,我们还将通过 Bug ID 后面的数字链接到更多参考信息。</p>
+
+<h3 id="bluetooth">蓝牙</h3>
+<p>这一部分中最严重的漏洞可让本地恶意应用获取超出其权限范围的数据。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>已更新的 AOSP 版本</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0639</td>
+ <td><a href="https://android.googlesource.com/platform/packages/apps/Bluetooth/+/f196061addcc56878078e5684f2029ddbf7055ff">A-35310991</a></td>
+ <td>ID</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0645</td>
+ <td><a href="https://android.googlesource.com/platform/packages/apps/Bluetooth/+/14b7d7e1537af60b7bca6c7b9e55df0dc7c6bf41">A-35385327</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0646</td>
+ <td><a href="https://android.googlesource.com/platform/system/bt/+/2bcdf8ec7db12c5651c004601901f1fc25153f2c">A-33899337</a></td>
+ <td>ID</td>
+ <td>中</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+</tbody></table>
+<h3 id="libraries">库</h3>
+<p>这一部分中最严重的漏洞可让远程攻击者使用特制文件通过非特许进程执行任意代码。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>已更新的 AOSP 版本</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-8871</td>
+ <td>A-35443562<a href="#asterisk">*</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-8332</td>
+ <td>A-37761553<a href="#asterisk">*</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-5131</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/0eff71008becb7f2c2b4509708da4b79985948bb">A-36554209</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-4658</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/8ea80f29ea5fdf383ee3ae59ce35e55421a339f8">A-36554207</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0663</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/521b88fbb6d18312923f0df653d045384b500ffc">A-37104170</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7376</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/51e0cb2e5ec18eaf6fb331bc573ff27b743898f4">A-36555370</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-5056</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/3f571b1bb85cf56903f06bab3a820182115c5541">A-36809819</a></td>
+ <td>RCE</td>
+ <td>中</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7375</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/308396a55280f69ad4112d4f9892f4cbeff042aa">A-36556310</a></td>
+ <td>RCE</td>
+ <td>中</td>
+ <td>4.4.4、5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0647</td>
+ <td><a href="https://android.googlesource.com/platform/system/core/+/3d6a43155c702bce0e7e2a93a67247b5ce3946a5">A-36392138</a></td>
+ <td>ID</td>
+ <td>中</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-1839</td>
+ <td><a href="https://android.googlesource.com/platform/external/libxml2/+/ff20cd797822dba8569ee518c44e6864d6b4ebfa">A-36553781</a></td>
+ <td>DoS</td>
+ <td>中</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+</tbody></table>
+<h3 id="media-framework">媒体框架</h3>
+<p>这一部分中最严重的漏洞可让远程攻击者在系统处理媒体文件和数据时,使用特制文件破坏内存。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>已更新的 AOSP 版本</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0637</td>
+ <td><a href="https://android.googlesource.com/platform/external/libhevc/+/ebaa71da6362c497310377df509651974401d258">A-34064500</a></td>
+ <td>RCE</td>
+ <td>严重</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0391</td>
+ <td><a href="https://android.googlesource.com/platform/external/libhevc/+/14bc1678a80af5be7401cf750ab762ae8c75cc5a">A-32322258</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0640</td>
+ <td>A-33129467<a href="#asterisk">*</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>6.0、6.0.1、7.0、7.1.1</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0641</td>
+ <td><a href="https://android.googlesource.com/platform/external/libvpx/+/698796fc930baecf5c3fdebef17e73d5d9a58bcb">A-34360591</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0642</td>
+ <td><a href="https://android.googlesource.com/platform/external/libhevc/+/913d9e8d93d6b81bb8eac3fc2c1426651f5b259d">A-34819017</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1、7.1.2</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0643</td>
+ <td>A-35645051<a href="#asterisk">*</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>5.0.2、5.1.1、6.0、6.0.1、7.0、7.1.1</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0644</td>
+ <td>A-35472997<a href="#asterisk">*</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>4.4.4、5.0.2、5.1.1、6.0、6.0.1</td>
+ </tr>
+</tbody></table>
+<h3 id="system-ui">系统界面</h3>
+<p>这一部分中最严重的漏洞可让攻击者使用特制文件通过非特许进程执行任意代码。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>已更新的 AOSP 版本</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0638</td>
+ <td><a href="https://android.googlesource.com/platform/external/libgdx/+/a98943dd4aece3024f023f00256607d50dcbcd1e">A-36368305</a></td>
+ <td>RCE</td>
+ <td>高</td>
+ <td>7.1.1、7.1.2</td>
+ </tr>
+</tbody></table>
+<h2 id="2017-06-05-details">2017-06-05 安全补丁程序级别 - 漏洞详情</h2>
+<p>我们在下面提供了 2017-06-05 补丁程序级别涵盖的每个安全漏洞的详细信息,漏洞列在受其影响的组件下,其中包括 CVE、相关参考信息、<a href="#vulnerability-type">漏洞类型</a>、<a href="/security/overview/updates-resources.html#severity">严重程度</a>、组件(如果适用)和已更新的 AOSP 版本(如果适用)等详细信息。在适用的情况下,我们会将 Bug ID 链接到解决相应问题的公开更改记录(如 AOSP 代码更改列表)。如果某个 Bug 有多条相关的更改记录,我们还将通过 Bug ID 后面的数字链接到更多参考信息。</p>
+
+<h3 id="kernel-components">内核组件</h3>
+<p>这一部分中最严重的漏洞可让本地恶意应用通过内核执行任意代码。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>组件</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0648</td>
+ <td>A-36101220<a href="#asterisk">*</a></td>
+ <td>EoP</td>
+ <td>高</td>
+ <td>FIQ 调试程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0651</td>
+ <td>A-35644815<a href="#asterisk">*</a></td>
+ <td>ID</td>
+ <td>低</td>
+ <td>ION 子系统</td>
+ </tr>
+</tbody></table>
+<h3 id="libraries-05">库</h3>
+<p>这一部分中最严重的漏洞可让远程攻击者使用特制文件获取敏感信息。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>已更新的 AOSP 版本</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-7995</td>
+ <td>A-36810065<a href="#asterisk">*</a></td>
+ <td>ID</td>
+ <td>中</td>
+ <td>4.4.4</td>
+ </tr>
+</tbody></table>
+<h3 id="mediatek-components">MediaTek 组件</h3>
+<p>这一部分中最严重的漏洞可让本地恶意应用通过内核执行任意代码。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>组件</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0636</td>
+ <td>A-35310230<a href="#asterisk">*</a><br />
+ M-ALPS03162263</td>
+ <td>EoP</td>
+ <td>高</td>
+ <td>命令队列驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0649</td>
+ <td>A-34468195<a href="#asterisk">*</a><br />
+ M-ALPS03162283</td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>声音驱动程序</td>
+ </tr>
+</tbody></table>
+<h3 id="nvidia-components">NVIDIA 组件</h3>
+<p>这一部分中最严重的漏洞可让本地恶意应用通过内核执行任意代码。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>组件</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-6247</td>
+ <td>A-34386301<a href="#asterisk">*</a><br />
+ N-CVE-2017-6247</td>
+ <td>EoP</td>
+ <td>高</td>
+ <td>声音驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-6248</td>
+ <td>A-34372667<a href="#asterisk">*</a><br />
+ N-CVE-2017-6248</td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>声音驱动程序</td>
+ </tr>
+</tbody></table>
+<h3 id="qualcomm-components">Qualcomm 组件</h3>
+<p>这一部分中最严重的漏洞可让邻近区域内的攻击者通过内核执行任意代码。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>组件</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-7371</td>
+ <td>A-36250786<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?id=e02e63b8014f7a0a5ea17a5196fb4ef1283fd1fd">QC-CR#1101054</a></td>
+ <td>RCE</td>
+ <td>严重</td>
+ <td>蓝牙驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7365</td>
+ <td>A-32449913<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/lk/commit/?id=da49bf21d1c19a6293d33c985066dc0273c476db">QC-CR#1017009</a></td>
+ <td>EoP</td>
+ <td>高</td>
+ <td>引导加载程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7366</td>
+ <td>A-36252171<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=f4c9ffd6cd7960265f38e285ac43cbecf2459e45">QC-CR#1036161</a>
+[<a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=7c4d5736d32f91f0cafe6cd86d00e26389970b00">2</a>]</td>
+ <td>EoP</td>
+ <td>高</td>
+ <td>GPU 驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7367</td>
+ <td>A-34514708<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/lk/commit/?id=07174af1af48c60a41c7136f0c80ffdf4ccc0b57">QC-CR#1008421</a></td>
+ <td>DoS</td>
+ <td>高</td>
+ <td>引导加载程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-5861</td>
+ <td>A-36251375<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-4.4/commit/?id=cf3c97b8b6165f13810e530068fbf94b07f1f77d">QC-CR#1103510</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>视频驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-5864</td>
+ <td>A-36251231<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?id=cbc21ceb69cb7bca0643423a7ca982abce3ce50a">QC-CR#1105441</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>声音驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-6421</td>
+ <td>A-36251986<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-4.4/commit/?id=be42c7ff1f0396484882451fd18f47144c8f1b6b">QC-CR#1110563</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>MStar 触摸屏驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7364</td>
+ <td>A-36252179<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?id=3ce6c47d2142fcd2c4c1181afe08630aaae5a267">QC-CR#1113926</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>视频驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7368</td>
+ <td>A-33452365<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=143ef972be1621458930ea3fc1def5ebce7b0c5d">QC-CR#1103085</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>声音驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7369</td>
+ <td>A-33751424<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-3.10/commit/?id=75ed08a822cf378ffed0d2f177d06555bd77a006">QC-CR#2009216</a>
+[<a href="https://source.codeaurora.org/quic/la//kernel/msm-3.18/commit/?id=ae8f1d5f60644983aba7fbab469d0e542a187c6e">2</a>]</td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>声音驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7370</td>
+ <td>A-34328139<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=970edf007fbe64b094437541a42477d653802d85">QC-CR#2006159</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>视频驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7372</td>
+ <td>A-36251497<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-3.18/commit/?id=1806be003731d6d4be55e5b940d14ab772839e13">QC-CR#1110068</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>视频驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7373</td>
+ <td>A-36251984<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-4.4/commit/?id=e5eb0d3aa6fe62ee437a2269a1802b1a72f61b75">QC-CR#1090244</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>视频驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8233</td>
+ <td>A-34621613<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=64b7bc25e019dd07e8042e0a6ec6dc6a1dd0c385">QC-CR#2004036</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>相机驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8234</td>
+ <td>A-36252121<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=6266f954a52641f550ef71653ea83c80bdd083be">QC-CR#832920</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>相机驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8235</td>
+ <td>A-36252376<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?id=7e4424a1b5f6a6536066cca7aac2c3a23fd39f6f">QC-CR#1083323</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>相机驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8236</td>
+ <td>A-35047217<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-3.18/commit/?id=cf0d31bc3b04cf2db7737d36b11a5bf50af0c1db">QC-CR#2009606</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>IPA 驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8237</td>
+ <td>A-36252377<br />
+ <a href="https://source.codeaurora.org/quic/la//kernel/msm-3.18/commit/?id=342d16ac6fb01e304ec75344c693257e00628ecf">QC-CR#1110522</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>网络驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8242</td>
+ <td>A-34327981<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=6a3b8afdf97e77c0b64005b23fa6d32025d922e5">QC-CR#2009231</a></td>
+ <td>EoP</td>
+ <td>中</td>
+ <td>安全执行环境通讯驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8239</td>
+ <td>A-36251230<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=01db0e012f86b8ba6974e5cb9905261a552a0610">QC-CR#1091603</a></td>
+ <td>ID</td>
+ <td>中</td>
+ <td>相机驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8240</td>
+ <td>A-36251985<br />
+ <a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=22b8b6608174c1308208d5bc6c143f4998744547">QC-CR#856379</a></td>
+ <td>ID</td>
+ <td>中</td>
+ <td>PIN 码控制器驱动程序</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8241</td>
+ <td>A-34203184<br />
+ <a href="https://source.codeaurora.org/quic/la//platform/vendor/qcom-opensource/wlan/qcacld-2.0/commit/?id=90213394b7efb28fa511b2eaebc1343ae3b54724">QC-CR#1069175</a></td>
+ <td>ID</td>
+ <td>低</td>
+ <td>WLAN 驱动程序</td>
+ </tr>
+</tbody></table>
+<h3 id="synaptics-components">Synaptics 组件</h3>
+<p>这一部分中最严重的漏洞可让本地恶意应用获取超出其权限范围的数据。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>组件</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0650</td>
+ <td>A-35472278<a href="#asterisk">*</a></td>
+ <td>EoP</td>
+ <td>低</td>
+ <td>触摸屏驱动程序</td>
+ </tr>
+</tbody></table>
+<h3 id="qualcomm-closed-source-components">Qualcomm 闭源组件</h3>
+<p>以下漏洞会影响 Qualcomm 组件;2014–2016 年的 Qualcomm AMSS 安全公告对这些漏洞进行了详细说明。此 Android 安全公告中也包含这些漏洞,旨在将其修复方案与 Android 安全补丁程序级别建立关联。这些漏洞的修复方案可直接从 Qualcomm 获取。</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="19%" />
+ <col width="9%" />
+ <col width="14%" />
+ <col width="39%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>参考信息</th>
+ <th>类型</th>
+ <th>严重程度</th>
+ <th>组件</th>
+ </tr>
+ <tr>
+ <td>CVE-2014-9960</td>
+ <td>A-37280308<a href="#asterisk">*</a><br />
+ QC-CR#381837</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9961</td>
+ <td>A-37279724<a href="#asterisk">*</a><br />
+ QC-CR#581093</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9953</td>
+ <td>A-36714770<a href="#asterisk">*</a><br />
+ QC-CR#642173</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9967</td>
+ <td>A-37281466<a href="#asterisk">*</a><br />
+ QC-CR#739110</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9026</td>
+ <td>A-37277231<a href="#asterisk">*</a><br />
+ QC-CR#748397</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9027</td>
+ <td>A-37279124<a href="#asterisk">*</a><br />
+ QC-CR#748407</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9008</td>
+ <td>A-36384689<a href="#asterisk">*</a><br />
+ QC-CR#762111</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9009</td>
+ <td>A-36393600<a href="#asterisk">*</a><br />
+ QC-CR#762182</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9010</td>
+ <td>A-36393101<a href="#asterisk">*</a><br />
+ QC-CR#758752</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9011</td>
+ <td>A-36714882<a href="#asterisk">*</a><br />
+ QC-CR#762167</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9024</td>
+ <td>A-37265657<a href="#asterisk">*</a><br />
+ QC-CR#740680</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9012</td>
+ <td>A-36384691<a href="#asterisk">*</a><br />
+ QC-CR#746617</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9013</td>
+ <td>A-36393251<a href="#asterisk">*</a><br />
+ QC-CR#814373</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9014</td>
+ <td>A-36393750<a href="#asterisk">*</a><br />
+ QC-CR#855220</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9015</td>
+ <td>A-36714120<a href="#asterisk">*</a><br />
+ QC-CR#701858</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9029</td>
+ <td>A-37276981<a href="#asterisk">*</a><br />
+ QC-CR#827837</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10338</td>
+ <td>A-37277738<a href="#asterisk">*</a><br />
+ QC-CR#987699</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10336</td>
+ <td>A-37278436<a href="#asterisk">*</a><br />
+ QC-CR#973605</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10333</td>
+ <td>A-37280574<a href="#asterisk">*</a><br />
+ QC-CR#947438</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10341</td>
+ <td>A-37281667<a href="#asterisk">*</a><br />
+ QC-CR#991476</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10335</td>
+ <td>A-37282802<a href="#asterisk">*</a><br />
+ QC-CR#961142</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10340</td>
+ <td>A-37280614<a href="#asterisk">*</a><br />
+ QC-CR#989028</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10334</td>
+ <td>A-37280664<a href="#asterisk">*</a><br />
+ QC-CR#949933</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10339</td>
+ <td>A-37280575<a href="#asterisk">*</a><br />
+ QC-CR#988502</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10298</td>
+ <td>A-36393252<a href="#asterisk">*</a><br />
+ QC-CR#1020465</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10299</td>
+ <td>A-32577244<a href="#asterisk">*</a><br />
+ QC-CR#1058511</td>
+ <td>N/A</td>
+ <td>严重</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9954</td>
+ <td>A-36388559<a href="#asterisk">*</a><br />
+ QC-CR#552880</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9955</td>
+ <td>A-36384686<a href="#asterisk">*</a><br />
+ QC-CR#622701</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9956</td>
+ <td>A-36389611<a href="#asterisk">*</a><br />
+ QC-CR#638127</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9957</td>
+ <td>A-36387564<a href="#asterisk">*</a><br />
+ QC-CR#638984</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9958</td>
+ <td>A-36384774<a href="#asterisk">*</a><br />
+ QC-CR#638135</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9962</td>
+ <td>A-37275888<a href="#asterisk">*</a><br />
+ QC-CR#656267</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9963</td>
+ <td>A-37276741<a href="#asterisk">*</a><br />
+ QC-CR#657771</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9959</td>
+ <td>A-36383694<a href="#asterisk">*</a><br />
+ QC-CR#651900</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9964</td>
+ <td>A-37280321<a href="#asterisk">*</a><br />
+ QC-CR#680778</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9965</td>
+ <td>A-37278233<a href="#asterisk">*</a><br />
+ QC-CR#711585</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2014-9966</td>
+ <td>A-37282854<a href="#asterisk">*</a><br />
+ QC-CR#727398</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9023</td>
+ <td>A-37276138<a href="#asterisk">*</a><br />
+ QC-CR#739802</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9020</td>
+ <td>A-37276742<a href="#asterisk">*</a><br />
+ QC-CR#733455</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9021</td>
+ <td>A-37276743<a href="#asterisk">*</a><br />
+ QC-CR#735148</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9025</td>
+ <td>A-37276744<a href="#asterisk">*</a><br />
+ QC-CR#743985</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9022</td>
+ <td>A-37280226<a href="#asterisk">*</a><br />
+ QC-CR#736146</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9028</td>
+ <td>A-37277982<a href="#asterisk">*</a><br />
+ QC-CR#762764</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9031</td>
+ <td>A-37275889<a href="#asterisk">*</a><br />
+ QC-CR#866015</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9032</td>
+ <td>A-37279125<a href="#asterisk">*</a><br />
+ QC-CR#873202</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9033</td>
+ <td>A-37276139<a href="#asterisk">*</a><br />
+ QC-CR#892541</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-9030</td>
+ <td>A-37282907<a href="#asterisk">*</a><br />
+ QC-CR#854667</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10332</td>
+ <td>A-37282801<a href="#asterisk">*</a><br />
+ QC-CR#906713<br />
+ QC-CR#917701<br />
+ QC-CR#917702</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10337</td>
+ <td>A-37280665<a href="#asterisk">*</a><br />
+ QC-CR#977632</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+ <tr>
+ <td>CVE-2016-10342</td>
+ <td>A-37281763<a href="#asterisk">*</a><br />
+ QC-CR#988941</td>
+ <td>N/A</td>
+ <td>高</td>
+ <td>闭源组件</td>
+ </tr>
+</tbody></table>
+<h2 id="google-device-updates">Google 设备更新</h2>
+<p>以下表格包含最新的无线更新 (OTA) 中的安全补丁程序级别和适用于 Google 设备的固件映像。Google 设备固件映像可在 <a href="https://developers.google.com/android/nexus/images">Google 开发者网站</a>上获取。</p>
+
+<table>
+ <colgroup><col width="25%" />
+ <col width="75%" />
+ </colgroup><tbody><tr>
+ <th>Google 设备</th>
+ <th>安全补丁程序级别</th>
+ </tr>
+ <tr>
+ <td>Pixel/Pixel XL</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+ <tr>
+ <td>Nexus 5X</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+ <tr>
+ <td>Nexus 6</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+ <tr>
+ <td>Nexus 6P</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+ <tr>
+ <td>Nexus 9</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+ <tr>
+ <td>Nexus Player</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+ <tr>
+ <td>Pixel C</td>
+ <td>2017 年 6 月 5 日</td>
+ </tr>
+</tbody></table>
+<h2 id="acknowledgements">致谢</h2>
+<p>非常感谢以下研究人员做出的贡献:</p>
+
+<table>
+ <colgroup><col width="17%" />
+ <col width="83%" />
+ </colgroup><tbody><tr>
+ <th>CVE</th>
+ <th>研究人员</th>
+ </tr>
+ <tr>
+ <td>CVE-2017-0643、CVE-2017-0641</td>
+ <td>趋势科技的徐健</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0645、CVE-2017-0639</td>
+ <td><a href="http://www.ms509.com">MS509Team</a> 的 En He (<a href="https://twitter.com/heeeeen4x">@heeeeen4x</a>) 和 Bo Liu</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0649</td>
+ <td>奇虎 360 科技有限公司 IceSword 实验室的 Gengjia Chen (<a href="https://twitter.com/chengjia4574">@chengjia4574</a>) 和 <a href="http://weibo.com/jfpan">pjf</a></td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0646</td>
+ <td>腾讯电脑管家的郑文选 (<a href="https://twitter.com/VirtualSeekers">@VirtualSeekers</a>)</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0636</td>
+ <td>Shellphish Grill 团队的 Jake Corina 和 Nick Stephens</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8233</td>
+ <td>奇虎 360 IceSword 实验室的 Jianqiang Zhao (<a href="https://twitter.com/jianqiangzhao">@jianqiangzhao</a>) 和 <a href="http://weibo.com/jfpan">pjf</a></td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7368</td>
+ <td><a href="http://c0reteam.org">C0RE 团队</a>的 Lubo Zhang (<a href="mailto:zlbzlb815@163.com">zlbzlb815@163.com</a>)、Yuan-Tsung Lo (<a href="mailto:computernik@gmail.com">computernik@gmail.com</a>) 和 Xuxian Jiang</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8242</td>
+ <td>特斯拉产品安全团队的 Nathan Crandall (<a href="https://twitter.com/natecray">@natecray</a>)</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0650</td>
+ <td>本·古里安大学网络实验室的 Omer Shwartz、Amir Cohen、Asaf Shabtai 博士和 Yossi Oren 博士</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0648</td>
+ <td>HCL 科技公司 <a href="https://alephsecurity.com/">Aleph 研究团队</a>的 Roee Hay (<a href="https://twitter.com/roeehay">@roeehay</a>)</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7369、CVE-2017-6249、CVE-2017-6247、CVE-2017-6248</td>
+ <td>趋势科技的 Seven Shen (<a href="https://twitter.com/lingtongshen">@lingtongshen</a>)</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0642、CVE-2017-0637、CVE-2017-0638</td>
+ <td>Vasily Vasiliev</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0640</td>
+ <td><a href="http://www.trendmicro.com">趋势科技</a><a href="http://blog.trendmicro.com/trendlabs-security-intelligence/category/mobile/">移动威胁响应团队</a>的 V.E.O (<a href="https://twitter.com/vysea">@VYSEa</a>)</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8236</td>
+ <td>腾讯安全平台部门的 Xiling Gong</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0647</td>
+ <td>奇虎 360 Qex 团队的 Yangkang (<a href="https://twitter.com/dnpushme">@dnpushme</a>) 和 Liyadong</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-7370</td>
+ <td>奇虎 360 科技有限公司 IceSword 实验室的 Yonggang Guo (<a href="https://twitter.com/guoygang">@guoygang</a>)</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-0651</td>
+ <td><a href="http://c0reteam.org">C0RE 团队</a>的 Yuan-Tsung Lo (<a href="mailto:computernik@gmail.com">computernik@gmail.com</a>) 和 Xuxian Jiang</td>
+ </tr>
+ <tr>
+ <td>CVE-2017-8241</td>
+ <td>Google 的 Zubin Mithra</td>
+ </tr>
+</tbody></table>
+<h2 id="common-questions-and-answers">常见问题和解答</h2>
+<p>本部分针对阅读本公告后可能产生的常见问题提供了相应的解答。</p>
+
+<p><strong>1. 如何确定我的设备是否已更新到解决了这些问题的版本?
+</strong></p>
+
+<p>要了解如何检查设备的安全补丁程序级别,请阅读 <a href="https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices">Pixel 和 Nexus 更新时间表</a>中的说明。</p>
+<ul>
+<li>2017-06-01(或之后)的安全补丁程序级别解决了与 2017-06-01 安全补丁程序级别相关的所有问题。</li>
+<li>2017-06-05(或之后)的安全补丁程序级别解决了与 2017-06-05 安全补丁程序级别以及之前的所有补丁程序级别相关的所有问题。</li></ul>
+<p>提供这些更新的设备制造商应将补丁程序字符串级别设为:</p>
+<ul>
+<li>[ro.build.version.security_patch]:[2017-06-01]</li>
+<li>[ro.build.version.security_patch]:[2017-06-05]</li></ul>
+<p><strong>2. 为何此公告有 2 个安全补丁程序级别?</strong></p>
+
+<p>本公告有 2 个安全补丁程序级别,目的是让 Android 合作伙伴能够灵活地、更快速地修复所有 Android 设备上类似的一系列漏洞。我们建议 Android 合作伙伴修复本公告中的所有问题并使用最新的安全补丁程序级别。</p>
+<ul>
+<li>使用 2017 年 6 月 1 日安全补丁程序级别的设备必须包含该安全补丁程序级别对应的所有问题的修复方案,以及针对之前的安全公告中报告的所有问题的修复方案。</li>
+<li>使用 2017 年 6 月 5 日或更新的安全补丁程序级别的设备必须包含此(以及之前的)安全公告中的所有适用补丁程序。</li></ul>
+<p>我们建议合作伙伴在一次更新中汇总要解决的所有问题的修复方案。</p>
+
+<p id="vulnerability-type"><strong>3.<em></em>“类型”列中的条目表示什么意思?</strong></p>
+
+<p><em></em>漏洞详情表的“类型”列中的条目是安全漏洞的分类。</p>
+
+<table>
+ <colgroup><col width="25%" />
+ <col width="75%" />
+ </colgroup><tbody><tr>
+ <th>缩写</th>
+ <th>定义</th>
+ </tr>
+ <tr>
+ <td>RCE</td>
+ <td>远程代码执行</td>
+ </tr>
+ <tr>
+ <td>EoP</td>
+ <td>提权</td>
+ </tr>
+ <tr>
+ <td>ID</td>
+ <td>信息披露</td>
+ </tr>
+ <tr>
+ <td>DoS</td>
+ <td>拒绝服务</td>
+ </tr>
+ <tr>
+ <td>N/A</td>
+ <td>没有分类</td>
+ </tr>
+</tbody></table>
+<p><strong>4.<em></em>“参考信息”列中的条目表示什么意思?</strong></p>
+
+<p>漏洞详情表的“参考信息”列中的条目可能包含用于标识参考值所属组织的前缀。<em></em></p>
+
+<table>
+ <colgroup><col width="25%" />
+ <col width="75%" />
+ </colgroup><tbody><tr>
+ <th>前缀</th>
+ <th>参考信息</th>
+ </tr>
+ <tr>
+ <td>A-</td>
+ <td>Android Bug ID</td>
+ </tr>
+ <tr>
+ <td>QC-</td>
+ <td>Qualcomm 参考编号</td>
+ </tr>
+ <tr>
+ <td>M-</td>
+ <td>MediaTek 参考编号</td>
+ </tr>
+ <tr>
+ <td>N-</td>
+ <td>NVIDIA 参考编号</td>
+ </tr>
+ <tr>
+ <td>B-</td>
+ <td>Broadcom 参考编号</td>
+ </tr>
+</tbody></table>
+<p id="asterisk"><strong>5.<em></em>“参考信息”列中的“Android Bug ID”旁边的 <a href="#asterisk">*</a> 表示什么意思?</strong></p>
+
+<p><em></em>如果“参考信息”列的“Android Bug ID”旁边标有 <a href="#asterisk">*</a>,则表示相应问题未公开发布。<a href="https://developers.google.com/android/nexus/drivers">Google Developers 网站</a>上提供的 Nexus 设备的最新二进制驱动程序中通常包含针对此问题的更新。</p>
+
+<h2 id="versions">版本</h2>
+<table>
+ <colgroup><col width="25%" />
+ <col width="25%" />
+ <col width="50%" />
+ </colgroup><tbody><tr>
+ <th>版本</th>
+ <th>日期</th>
+ <th>备注</th>
+ </tr>
+ <tr>
+ <td>1.0</td>
+ <td>2017 年 6 月 5 日</td>
+ <td>发布了本公告。</td>
+ </tr>
+ <tr>
+ <td>1.1</td>
+ <td>2017 年 6 月 7 日</td>
+ <td>修订了本公告,添加了 AOSP 链接。</td>
+ </tr>
+</tbody></table>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/encryption/full-disk.html b/zh-cn/security/encryption/full-disk.html
new file mode 100644
index 00000000..b06a5757
--- /dev/null
+++ b/zh-cn/security/encryption/full-disk.html
@@ -0,0 +1,395 @@
+<html devsite><head>
+ <title>全盘加密</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>全盘加密是使用已加密的密钥对 Android 设备上的所有用户数据进行编码的过程。设备经过加密后,所有由用户创建的数据在写入磁盘之前都会自动加密,并且所有读取操作都会在将数据返回给调用进程之前自动解密数据。</p>
+
+<p>全盘加密是在 Android 4.4 版中引入的,不过 Android 5.0 中又引入了以下新功能:</p>
+<ul>
+ <li>创建了快速加密方式,这种加密方式只会对数据分区中已使用的分块进行加密,以免首次启动用时过长。目前只有 EXT4 和 F2FS 文件系统支持快速加密。
+ </li><li>添加了 <a href="/devices/storage/config.html"><code>forceencrypt</code> fstab 标记</a>,以便在首次启动时进行加密。
+ </li><li>添加了对解锁图案和无密码加密的支持。
+ </li><li>添加了由硬件支持的加密密钥存储空间,该空间使用可信执行环境(TEE,例如 TrustZone)的签名功能。如需更多详细信息,请参阅<a href="#storing_the_encrypted_key">存储已加密的密钥</a>。
+</li></ul>
+
+<p class="caution"><strong>注意</strong>:对于升级到 Android 5.0 的设备,如果升级之后进行了加密,则可以通过恢复出厂设置还原到未加密状态。在首次启动时加密的新 Android 5.0 设备无法还原到未加密状态。</p>
+
+<h2 id="how_android_encryption_works">Android 全盘加密的运作方式</h2>
+
+<p>Android 全盘加密基于在块设备层运行的内核功能 <code>dm-crypt</code>。因此,这种加密方式适用于以块设备的形式呈现给内核的嵌入式多媒体卡<strong> </strong>(eMMC) 和类似闪存设备。YAFFS 会直接与原始 NAND 闪存芯片交互,无法进行全盘加密。</p>
+
+<p>全盘加密采用的是 128 位高级加密标准 (AES) 算法(搭配密码块链接 (CBC) 和 ESSIV:SHA256)。对主密钥进行加密时使用的是 128 位 AES 算法,并会调用 OpenSSL 库。对于该密钥,您必须使用 128 位或更多位(可以选择 256 位)。</p>
+
+<p class="note"><strong>注意</strong>:原始设备制造商 (OEM) 可以使用 128 位或更多位对主密钥进行加密。</p>
+
+<p>Android 5.0 版中有以下 4 种加密状态:</p>
+
+<ul>
+ <li>默认</li><li>PIN 码</li><li>密码</li><li>解锁图案</li></ul>
+
+<p>首次启动时,设备会创建一个随机生成的 128 位主密钥,然后会使用默认密码和存储的盐对其进行哈希处理。默认密码是“default_password”。不过,设备还会通过 TEE(例如 TrustZone)为生成的哈希签名。TEE 会使用相应签名的哈希来加密主密钥。</p>
+
+<p>您可以在 Android 开放源代码项目 <a href="https://android.googlesource.com/platform/system/vold/+/master/cryptfs.c">cryptfs.c</a> 文件中找到定义的默认密码。</p>
+
+<p>当用户在设备上设置 PIN 码/通行码或密码时,只有 128 位的密钥会被重新加密并存储起来(也就是说,更改用户 PIN 码/通行码/解锁图案不会导致重新加密用户数据)。请注意,<a href="http://developer.android.com/guide/topics/admin/device-admin.html">受管理的设备</a>可能受 PIN 码、解锁图案或密码限制。</p>
+
+<p>加密操作由 <code>init</code> 和 <code>vold</code> 管理。
+<code>init</code> 负责调用 <code>vold</code>,然后 vold 会设置相关属性以触发 init 中的事件。系统的其他部分也会查看这些属性以执行各项任务,例如报告状态、提示输入密码,或有严重错误发生时提示恢复出厂设置。为了调用 <code>vold</code> 中的加密功能,系统会使用命令行工具 <code>vdc</code> 的 <code>cryptfs</code> 命令:<code>checkpw</code>、<code>restart</code>、<code>enablecrypto</code>、<code>changepw</code>、<code>cryptocomplete</code>、<code>verifypw</code>、<code>setfield</code>、<code>getfield</code>、<code>mountdefaultencrypted</code>、<code>getpwtype</code>、<code>getpw</code> 以及 <code>clearpw</code>。</p>
+
+<p>要加密、解密或清空 <code>/data</code>,<code>/data</code> 不得处于装载状态。但要显示任何界面,框架都必须启动,而框架需要 <code>/data</code> 才能运行。为了解决这一冲突,<code>/data</code> 上会装载一个临时文件系统。通过该文件系统,Android 可以提示输入密码、显示进度或根据需要建议清除数据。不过,该文件系统会带来以下限制:要从临时文件系统切换到实际的 <code>/data</code> 文件系统,系统必须停止临时文件系统中打开了文件的所有进程,并在实际的 <code>/data</code> 文件系统中重启这些进程。为此,所有服务都必须位于以下其中一个组内:<code>core</code>、<code>main</code> 和 <code>late_start</code>。</p>
+
+<ul>
+ <li><code>core</code>:启动后一直不会关闭。
+ </li><li><code>main</code>:关闭,然后在用户输入磁盘密码后会重启。
+ </li><li><code>late_start</code>:在 <code>/data</code> 未解密并装载之前,一直不会启动。
+</li></ul>
+
+<p>为了触发这些操作,<code>vold.decrypt</code> 属性会被设为<a href="https://android.googlesource.com/platform/system/vold/+/master/cryptfs.c">多种字符串</a>。要结束和重启服务,请使用以下 <code>init</code> 命令:</p>
+
+<ul>
+ <li><code>class_reset</code>:停止相应服务,但允许通过 class_start 重启该服务。
+ </li><li><code>class_start</code>:重启相应服务。
+ </li><li><code>class_stop</code>:停止相应服务并添加 <code>SVC_DISABLED</code> 标记。被停止的服务不会对 <code>class_start</code> 做出响应。
+</li></ul>
+
+<h2 id="flows">流程</h2>
+
+<p>有 4 种针对已加密设备的流程。每个设备只需加密一次,然后会遵循正常的启动流程。</p>
+
+<ul>
+ <li>加密之前未加密的设备:<ul>
+ <li>使用 <code>forceencrypt</code> 加密新设备:首次启动时的强制加密(从 Android L 开始)。
+ </li><li>加密现有设备:由用户启动的加密(Android K 及更低版本)。
+ </li></ul>
+ </li><li>启动已加密的设备:<ul>
+ <li>启动无密码的已加密设备:启动未设置密码的已加密设备(适用于运行 Android 5.0 及更高版本的设备)。
+ </li><li>启动设有密码的已加密设备:启动设置了密码的已加密设备。
+ </li></ul>
+</li></ul>
+
+<p>除了上述流程外,设备还可能无法加密 <code>/data</code>。下文对上述每种流程进行了详细介绍。</p>
+
+<h3 id="encrypt_a_new_device_with_forceencrypt">使用 forceencrypt 加密新设备</h3>
+
+<p>这是 Android 5.0 设备首次启动时的常规流程。</p>
+
+<ol>
+ <li><strong>检测带有 <code>forceencrypt</code> 标记的未加密文件系统</strong>
+
+<p>
+<code>/data</code> 未加密,但需要加密,因为 <code>forceencrypt</code> 强制要求进行此项加密。卸载 <code>/data</code>。</p>
+
+ </li><li><strong>开始加密 <code>/data</code></strong>
+
+<p><code>vold.decrypt = "trigger_encryption"</code> 会触发 <code>init.rc</code>,从而使 <code>vold</code> 对 <code>/data</code> 进行无密码加密。(因为这应该是新设备,还没有设置密码。)</p>
+
+ </li><li><strong>装载 tmpfs</strong>
+
+<p><code>vold</code> 会装载一个 tmpfs <code>/data</code>(使用 <code>ro.crypto.tmpfs_options</code> 中的 tmpfs 选项),并会将 <code>vold.encrypt_progress</code> 属性设为 0。
+<code>vold</code> 会准备 tmpfs <code>/data</code> 以便启动已加密的系统,并会将 <code>vold.decrypt</code> 属性设为 <code>trigger_restart_min_framework</code>
+</p>
+
+ </li><li><strong>启动框架以显示进度</strong>
+
+<p>由于设备上几乎没有要加密的数据,加密过程很快就会完成,因此实际上通常并不会显示进度条。如需关于进度界面的更多详细信息,请参阅<a href="#encrypt_an_existing_device">加密现有设备</a>。</p>
+
+ </li><li><strong><code>/data</code> 加密后,关闭框架</strong>
+
+<p><code>vold</code> 会将 <code>vold.decrypt</code> 设为 <code>trigger_default_encryption</code>,这会启动 <code>defaultcrypto</code> 服务。(这会启动以下流程来装载默认的已加密用户数据。)<code>trigger_default_encryption</code> 会检查加密类型,以了解 <code>/data</code> 加密是否使用了密码。由于 Android 5.0 设备是在首次启动时加密,应该没有设置任何密码,因此我们要解密并装载 <code>/data</code>。</p>
+
+ </li><li><strong>装载 <code>/data</code></strong>
+
+<p>接下来,<code>init</code> 会使用从 <code>ro.crypto.tmpfs_options</code>(在 <code>init.rc</code> 中设置)中选取的参数在 tmpfs RAMDisk 中装载 <code>/data</code>。</p>
+
+ </li><li><strong>启动框架</strong>
+
+<p>将 <code>vold</code> 设为 <code>trigger_restart_framework</code>,这会继续常规启动过程。</p>
+</li></ol>
+
+<h3 id="encrypt_an_existing_device">加密现有设备</h3>
+
+<p>当您加密之前搭载 Android K 或更低版本但已迁移至 L 的未加密设备时,则会发生该流程。</p>
+
+<p>该流程由用户启动,在代码中称为“原地加密”。当用户选择对设备进行加密时,界面中将会提示用户确认电池是否已充满电并且交流电源适配器是否已插好,以便有充足的电量来完成加密过程。</p>
+
+<p class="warning"><strong>警告</strong>:如果设备在完成加密之前耗尽电量并关机,文件数据将会处于部分加密状态。如果出现这种情况,必须将设备恢复出厂设置,而这将导致所有数据都会丢失。</p>
+
+<p>为了进行原地加密,<code>vold</code> 会启动一个循环来读取实际块设备中每个扇区的数据,然后将其写入到加密块设备。在读取每个扇区的数据以及将其写入到加密块设备之前,<code>vold</code> 都会先检查相应扇区是否处于使用状态。对于几乎没有什么数据的新设备来说,这种方式可以大大加快加密速度。</p>
+
+<p><strong>设备状态</strong>:设置 <code>ro.crypto.state = "unencrypted"</code>,并执行 <code>on nonencrypted</code> <code>init</code> 触发器以继续启动。</p>
+
+<ol>
+ <li><strong>检查密码</strong>
+
+<p>界面会使用 <code>cryptfs enablecrypto inplace</code> 命令调用 <code>vold</code>,其中 <code>passwd</code> 是用户的锁定屏幕密码。</p>
+
+ </li><li><strong>关闭框架</strong>
+
+<p><code>vold</code> 会检查是否存在错误。如果无法加密,则返回 -1,并在日志中记录原因。如果可以加密,则会将 <code>vold.decrypt</code> 属性设为 <code>trigger_shutdown_framework</code>。这会使 <code>init.rc</code> 停止 <code>late_start</code> 类和 <code>main</code> 类中的服务。</p>
+
+ </li><li><strong>创建加密页脚</strong></li>
+ <li><strong>创建路径文件</strong></li>
+ <li><strong>重新启动</strong></li>
+ <li><strong>检测路径文件</strong></li>
+ <li><strong>开始加密 <code>/data</code></strong>
+
+<p>接下来,<code>vold</code> 会设置加密映射,这将创建一个映射到实际块设备的虚拟加密块设备,但会在写入每个扇区的数据时对相应扇区进行加密,并在读取每个扇区的数据时对相应扇区进行解密。然后,<code>vold</code> 会创建并写出加密元数据。</p>
+
+ </li><li><strong>在加密时装载 tmpfs</strong>
+
+<p><code>vold</code> 会装载一个 tmpfs <code>/data</code>(使用 <code>ro.crypto.tmpfs_options</code> 中的 tmpfs 选项),并会将 <code>vold.encrypt_progress</code> 属性设为 0。<code>vold</code> 会准备 tmpfs <code>/data</code> 以便启动已加密的系统,并会将 <code>vold.decrypt</code> 属性设为 <code>trigger_restart_min_framework</code> </p>
+
+ </li><li><strong>启动框架以显示进度</strong>
+
+<p><code>trigger_restart_min_framework </code> 会使 <code>init.rc</code> 启动 <code>main</code> 类中的服务。当框架看到 <code>vold.encrypt_progress</code> 已设为 0 时,它会打开进度条界面,该界面每 5 秒查询一次该属性并更新进度条。加密循环会在已加密的分区比例每增加百分之一时更新一次 <code>vold.encrypt_progress</code>。</p>
+
+ </li><li><strong><code> /data</code> 加密后,更新加密页脚</strong>
+
+<p><code>/data</code> 成功加密后,<code>vold</code> 会清除元数据中的 <code>ENCRYPTION_IN_PROGRESS</code> 标记。</p>
+
+<p>当设备成功解锁后,接下来便会使用密码加密主密钥,并且会更新加密页脚。</p>
+
+<p>如果重新启动因某个原因失败了,<code>vold</code> 会将 <code>vold.encrypt_progress</code> 属性设为 <code>error_reboot_failed</code>,并且界面中应显示一条消息,提示用户按某个按钮以重新启动。这种情况不应发生。</p>
+</li></ol>
+
+<h3 id="starting_an_encrypted_device_with_default_encryption">启动已进行默认加密的已加密设备</h3>
+
+<p>当您启动无密码的已加密设备时,则会发生该流程。由于 Android 5.0 设备是在首次启动时加密,应该没有设置任何密码,因此属于“默认加密”状态。<em></em></p>
+
+<ol>
+ <li><strong>检测无密码的已加密 <code>/data</code></strong>
+
+<p>会发现 Android 设备已加密,因为 <code>/data</code> 无法装载,并且设置了 <code>encryptable</code> 或 <code>forceencrypt</code> 标记。</p>
+
+<p><code>vold</code> 会将 <code>vold.decrypt</code> 设为 <code>trigger_default_encryption</code>,这会启动 <code>defaultcrypto</code> 服务。<code>trigger_default_encryption</code> 会检查加密类型,以了解 <code>/data</code> 加密是否使用了密码。</p>
+
+ </li><li><strong>解密 /data</strong>
+
+<p>基于块设备创建 <code>dm-crypt</code> 设备,接下来设备就可以使用了。</p>
+
+ </li><li><strong>装载 /data</strong>
+
+<p>然后,<code>vold</code> 会装载已解密的实际 <code>/data</code> 分区,并准备新的分区。它会将 <code>vold.post_fs_data_done</code> 属性设为 0,接着将 <code>vold.decrypt</code> 设为 <code>trigger_post_fs_data</code>。这会使 <code>init.rc</code> 运行其 <code>post-fs-data</code> 命令。这些命令会创建所有必要的目录或链接,然后将 <code>vold.post_fs_data_done</code> 设为 1。</p>
+
+<p>当 <code>vold</code> 看到该属性中的 1 时,会将 <code>vold.decrypt</code> 属性设为 <code>trigger_restart_framework.</code> 这会使 <code>init.rc</code> 再次启动 <code>main</code> 类中的服务,并启动 <code>late_start</code> 类中的服务(这是设备启动后首次启动这些服务)。</p>
+
+ </li><li><strong>启动框架</strong>
+
+<p>现在,框架会使用已解密的 <code>/data</code> 启动其所有服务,接下来系统就可以使用了。</p>
+</li></ol>
+
+<h3 id="starting_an_encrypted_device_without_default_encryption">启动未进行默认加密的已加密设备</h3>
+
+<p>当您启动设有密码的已加密设备时,则会发生该流程。设备的密码可以是 PIN 码、解锁图案或密码。</p>
+
+<ol>
+ <li><strong>检测设有密码的已加密设备</strong>
+
+<p>会发现 Android 设备已加密,因为设置了 <code>ro.crypto.state = "encrypted"</code> 标记</p>
+
+<p>由于 <code>/data</code> 是使用密码加密的,因此 <code>vold</code> 会将 <code>vold.decrypt</code> 设为 <code>trigger_restart_min_framework</code>。</p>
+
+ </li><li><strong>装载 tmpfs</strong>
+
+<p><code>init</code> 会设置 5 个属性,以保存为 <code>/data</code>(包含从 <code>init.rc</code> 传入的参数)提供的初始装载选项。
+<code>vold</code> 会使用这些属性来设置加密映射:</p>
+
+<ol>
+ <li><code>ro.crypto.fs_type</code>
+ </li><li><code>ro.crypto.fs_real_blkdev</code>
+ </li><li><code>ro.crypto.fs_mnt_point</code>
+ </li><li><code>ro.crypto.fs_options</code>
+ </li><li><code>ro.crypto.fs_flags </code>(ASCII 码 8 位十六进制数字,以 0x 开头)</li></ol>
+
+ </li><li><strong>启动框架以提示输入密码</strong>
+
+<p>框架会启动并看到 <code>vold.decrypt</code> 已设为 <code>trigger_restart_min_framework</code>。这让框架知道自己是在 tmpfs <code>/data</code> 磁盘中启动的,并且需要获取用户密码。</p>
+
+<p>不过,它首先需要确认磁盘是否已经过适当加密。它会向 <code>vold</code> 发送 <code>cryptfs cryptocomplete</code> 命令。
+如果加密已成功完成,<code>vold</code> 会返回 0;如果发生内部错误,则会返回 -1;如果加密未成功完成,则会返回 -2。<code>vold</code> 通过查看 <code>CRYPTO_ENCRYPTION_IN_PROGRESS</code> 标记的加密元数据来确定应返回的值。如果设置了此标记,则表示加密过程中断了,并且设备上没有可用的数据。如果 <code>vold</code> 返回错误,界面中应显示一条消息,提示用户重新启动设备并将其恢复出厂设置,并且界面中应为用户提供一个用于执行该操作的按钮。</p>
+
+ </li><li><strong>通过密码解密数据</strong>
+
+<p><code>cryptfs cryptocomplete</code> 成功后,框架会显示一个界面,提示用户输入磁盘密码。界面会向 <code>vold</code> 发送 <code>cryptfs checkpw</code> 命令来检查用户输入的密码。如果密码正确(通过以下方式判定:在临时位置成功装载已解密的 <code>/data</code>,然后将其卸载),<code>vold</code> 会将已解密块设备的名称保存在 <code>ro.crypto.fs_crypto_blkdev</code> 属性中,并向界面返回状态 0。如果密码不正确,则向界面返回 -1。</p>
+
+ </li><li><strong>停止框架</strong>
+
+<p>界面会显示加密启动图形,然后使用 <code>cryptfs restart</code> 命令调用 <code>vold</code>。<code>vold</code> 会将 <code>vold.decrypt</code> 属性设为 <code>trigger_reset_main</code>,这会使 <code>init.rc</code> 执行 <code>class_reset main</code> 命令。此命令会停止 main 类中的所有服务,以便卸载 tmpfs <code>/data</code>。</p>
+
+ </li><li><strong>装载 <code>/data</code></strong>
+
+<p>然后,<code>vold</code> 会装载已解密的实际 <code>/data</code> 分区,并准备新的分区(如果加密时采用了首次发布不支持的数据清除选项,则可能永远无法准备就绪)。它会将 <code>vold.post_fs_data_done</code> 属性设为 0,接着将 <code>vold.decrypt</code> 设为 <code>trigger_post_fs_data</code>。这会使 <code>init.rc</code> 运行其 <code>post-fs-data</code> 命令。这些命令会创建所有必要的目录或链接,然后将 <code>vold.post_fs_data_done</code> 设为 1。当 <code>vold</code> 看到该属性中的 1 时,会将 <code>vold.decrypt</code> 属性设为 <code>trigger_restart_framework</code>。这会使 <code>init.rc</code> 再次启动 <code>main</code> 类中的服务,并启动 <code>late_start</code> 类中的服务(这是设备启动后首次启动这些服务)。</p>
+
+ </li><li><strong>启动整个框架</strong>
+
+<p>现在,框架会使用已解密的 <code>/data</code> 文件系统启动其所有服务,接下来系统就可以使用了。</p>
+</li></ol>
+
+<h3 id="failure">失败</h3>
+
+<p>有一些原因可能会导致设备无法解密。设备会先按照一系列常规步骤启动:</p>
+
+<ol>
+ <li>检测设有密码的已加密设备</li><li>装载 tmpfs</li><li>启动框架以提示输入密码</li></ol>
+
+<p>但在框架打开后,设备可能会遇到一些错误:</p>
+
+<ul>
+ <li>密码匹配但无法解密数据</li><li>用户输错密码的次数达到了 30 次</li></ul>
+
+<p>如果这些错误未解决,则会<strong>提示用户清除数据并恢复出厂设置</strong>:</p>
+
+<p>如果 <code>vold</code> 在加密过程中检测到错误,并且任何数据都尚未被销毁,而框架处于打开状态,<code>vold</code> 会将 <code>vold.encrypt_progress </code>属性设为 <code>error_not_encrypted</code>。界面中会提示用户重新启动系统,并提醒他们加密过程并未开始。如果错误发生在框架关闭之后、进度条界面显示之前,<code>vold</code> 会重新启动系统。如果重新启动失败,则会将 <code>vold.encrypt_progress</code> 设为 <code>error_shutting_down</code> 并返回 -1;但却无法捕获相应错误。这种情况不应发生。</p>
+
+<p>如果 <code>vold</code> 在加密过程中检测到错误,则会将 <code>vold.encrypt_progress</code> 设为 <code>error_partially_encrypted</code> 并返回 -1。随后,界面中应显示一条消息,告诉用户加密失败,并且界面中应为用户提供一个用于将设备恢复出厂设置的按钮。</p>
+
+<h2 id="storing_the_encrypted_key">存储已加密的密钥</h2>
+
+<p>已加密的密钥存储在加密元数据中。硬件支持是通过使用可信执行环境 (TEE) 的签名功能实现的。以前在加密主密钥时,需要使用通过对用户的密码和存储的盐应用 scrypt 生成的密钥。为了使该密钥能够抵御盒外攻击,我们通过使用存储的 TEE 密钥为生成的密钥签名,扩展了这种算法。然后,通过再次应用 scrypt,生成的签名会转变成具有适当长度的密钥。该密钥随后会用于加密和解密主密钥。存储该密钥的步骤如下:</p>
+
+<ol>
+ <li>生成 16 个字节的随机磁盘加密密钥 (DEK) 和 16 个字节的盐。
+ </li><li>对用户密码和盐应用 scrypt,以生成 32 个字节的中间密钥 1 (IK1)。
+ </li><li>为 IK1 填充若干个零字节,以便达到绑定到硬件的私钥 (HBK) 的大小。具体来说就是按照以下方式进行填充:00 || IK1 || 00..00;1 个零字节,32 个 IK1 字节,223 个零字节。
+ </li><li>使用 HBK 为已填充的 IK1 签名,以生成 256 个字节的 IK2。
+ </li><li>对 IK2 和盐(与第 2 步中使用的盐相同)应用 scrypt,以生成 32 个字节的 IK3。
+ </li><li>将 IK3 的前 16 个字节用作 KEK,后 16 个字节用作 IV。</li><li>使用 AES_CBC、密钥 KEK 和初始化矢量 IV 加密 DEK。</li></ol>
+
+<h2 id="changing_the_password">更改密码</h2>
+
+<p>当用户选择在设置中更改或移除密码时,界面会向 <code>vold</code> 发送 <code>cryptfs changepw</code> 命令,然后 <code>vold</code> 会使用新密码重新加密磁盘主密钥。</p>
+
+<h2 id="encryption_properties">加密属性</h2>
+
+<p><code>vold</code> 和 <code>init</code> 之间通过设置属性进行通信。下面列出了可用的加密属性。</p>
+
+<h3 id="vold_properties">vold 属性</h3>
+
+<table>
+ <tbody><tr>
+ <th>属性</th>
+ <th>说明</th>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_encryption</code></td>
+ <td>以无密码方式加密存储卷。</td>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_default_encryption</code></td>
+ <td>检查存储卷是否采用了无密码加密。如果是,则解密并装载存储卷;如果不是,则将 <code>vold.decrypt</code> 设为 trigger_restart_min_framework。</td>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_reset_main</code></td>
+ <td>由 vold 设置,用于关闭提示输入磁盘密码的界面。</td>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_post_fs_data</code></td>
+ <td>由 vold 设置,用于准备具有必要目录等内容的 /data。</td>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_restart_framework</code></td>
+ <td>由 vold 设置,用于启动实际框架和所有服务。</td>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_shutdown_framework</code></td>
+ <td>由 vold 设置,用于关闭整个框架以开始加密。</td>
+ </tr>
+ <tr>
+ <td><code>vold.decrypt trigger_restart_min_framework</code></td>
+ <td>由 vold 设置,用于启动加密进度条界面或提示输入密码,具体取决于 <code>ro.crypto.state</code> 的值。</td>
+ </tr>
+ <tr>
+ <td><code>vold.encrypt_progress</code></td>
+ <td>框架启动时,如果设置了此属性,则会进入进度条界面模式。</td>
+ </tr>
+ <tr>
+ <td><code>vold.encrypt_progress 0 to 100</code></td>
+ <td>进度条界面中应按照设置显示百分比值。</td>
+ </tr>
+ <tr>
+ <td><code>vold.encrypt_progress error_partially_encrypted</code></td>
+ <td>进度条界面中应显示一条消息,告诉用户加密失败,并且界面中应为用户提供一个用于将设备恢复出厂设置的按钮。</td>
+ </tr>
+ <tr>
+ <td><code>vold.encrypt_progress error_reboot_failed</code></td>
+ <td>进度条界面中应显示一条消息,告诉用户加密已完成,并且界面中应为用户提供一个用于重新启动设备的按钮。此错误不应发生。</td>
+ </tr>
+ <tr>
+ <td><code>vold.encrypt_progress error_not_encrypted</code></td>
+ <td>进度条界面中应显示一条消息,告诉用户发生错误,没有已加密的数据或数据已丢失,并且界面中应为用户提供一个用于重新启动系统的按钮。</td>
+ </tr>
+ <tr>
+ <td><code>vold.encrypt_progress error_shutting_down</code></td>
+ <td>进度条界面未运行,因此不清楚谁将响应此错误。在任何情况下,都不应发生此错误。</td>
+ </tr>
+ <tr>
+ <td><code>vold.post_fs_data_done 0</code></td>
+ <td>由 <code>vold</code> 在将 <code>vold.decrypt</code> 设为 <code>trigger_post_fs_data</code> 的前一刻设置。</td>
+ </tr>
+ <tr>
+ <td><code>vold.post_fs_data_done 1</code></td>
+ <td>由 <code>init.rc</code> 或 <code>init.rc</code> 在完成 <code>post-fs-data</code> 任务之后立即设置。</td>
+ </tr>
+</tbody></table>
+<h3 id="init_properties">init 属性</h3>
+
+<table>
+ <tbody><tr>
+ <th>属性</th>
+ <th>说明</th>
+ </tr>
+ <tr>
+ <td><code>ro.crypto.fs_crypto_blkdev</code></td>
+ <td>由 <code>vold</code> 命令 <code>checkpw</code> 设置,供 <code>vold</code> 命令 <code>restart</code> 以后使用。</td>
+ </tr>
+ <tr>
+ <td><code>ro.crypto.state unencrypted</code></td>
+ <td>由 <code>init</code> 设置,用于说明相应系统正在未加密的 <code>/data ro.crypto.state encrypted</code> 中运行。由 <code>init</code> 设置,用于说明相应系统正在已加密的 <code>/data</code> 中运行。</td>
+ </tr>
+ <tr>
+ <td><p><code>ro.crypto.fs_type<br />
+ ro.crypto.fs_real_blkdev <br />
+ ro.crypto.fs_mnt_point<br />
+ ro.crypto.fs_options<br />
+ ro.crypto.fs_flags <br />
+ </code></p></td>
+ <td>这 5 个属性由 <code>init</code> 在尝试装载 <code>/data</code>(包含从 <code>init.rc</code> 传入的参数)时设置。<code>vold</code> 会使用这些属性来设置加密映射。</td>
+ </tr>
+ <tr>
+ <td><code>ro.crypto.tmpfs_options</code></td>
+ <td>由 <code>init.rc</code> 设置,包含 init 在装载 tmpfs /data 文件系统时应使用的选项。</td>
+ </tr>
+</tbody></table>
+<h2 id="init_actions">init 操作</h2>
+
+<pre>
+on post-fs-data
+on nonencrypted
+on property:vold.decrypt=trigger_reset_main
+on property:vold.decrypt=trigger_post_fs_data
+on property:vold.decrypt=trigger_restart_min_framework
+on property:vold.decrypt=trigger_restart_framework
+on property:vold.decrypt=trigger_shutdown_framework
+on property:vold.decrypt=trigger_encryption
+on property:vold.decrypt=trigger_default_encryption
+</pre>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/encryption/index.html b/zh-cn/security/encryption/index.html
new file mode 100644
index 00000000..ea9f2447
--- /dev/null
+++ b/zh-cn/security/encryption/index.html
@@ -0,0 +1,38 @@
+<html devsite><head>
+ <title>加密</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>加密是使用对称加密密钥对 Android 设备上的所有用户数据进行编码的过程。设备经过加密后,所有由用户创建的数据在存入磁盘之前都会自动加密,并且所有读取操作都会在将数据返回给调用进程之前自动解密数据。加密可确保未经授权方在尝试访问相应数据时无法读取它们。
+</p>
+<p>Android 有两种设备加密方法:全盘加密和文件级加密。
+</p>
+<h2 id="full-disk">全盘加密</h2>
+<p>Android 5.0 及更高版本支持<a href="full-disk.html">全盘加密</a>。全盘加密是使用单个密钥(由用户的设备密码加以保护)来保护设备的整个用户数据分区。设备启动后,用户必须提供其凭据才能访问磁盘的任何部分。
+</p>
+<p>虽然这非常有利于确保安全性,但如果采用这种加密方式,当用户重新启动设备后,手机的大多数核心功能都将无法立即可用。由于对数据的访问受单个用户凭据的保护,因此闹钟等功能将无法运行,无障碍服务将无法使用,并且手机将无法接听电话。
+</p>
+<h2 id="file-based">文件级加密</h2>
+<p>Android 7.0 及更高版本支持<a href="file-based.html">文件级加密</a>。采用文件级加密时,可以使用不同的密钥对不同的文件进行加密,并且可以对这些文件进行单独解密。支持文件级加密的设备还支持一种称为<a href="https://developer.android.com/preview/features/direct-boot.html">直接启动</a>的新功能。该功能处于启用状态时,已加密设备在启动后将直接进入锁定屏幕,从而可让用户快速访问重要的设备功能,例如无障碍服务和闹钟。
+</p>
+<p>引入文件级加密和新 API 后,便可以将应用设为加密感知型应用,这样一来,它们将能够在受限环境中运行。这些应用将可以在用户提供凭据之前运行,同时系统仍能保护私密用户信息。
+</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements41.html b/zh-cn/security/enhancements/enhancements41.html
new file mode 100644
index 00000000..0516b649
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements41.html
@@ -0,0 +1,57 @@
+<html devsite><head>
+ <title>Android 1.5 至 4.1 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 提供了一个多层安全模型,<a href="/security/index.html">Android 安全性概述</a>中对该模型进行了介绍。每个 Android 更新版本中都包含数十种用于保护用户的安全增强功能。以下是 Android 1.5 至 4.1 版中引入的一些安全增强功能:</p>
+
+<dl>
+<dt><strong>Android 1.5</strong></dt>
+<dd><ul>
+<li>ProPolice:旨在防止堆栈缓冲区溢出 (-fstack-protector)</li>
+<li>safe_iop:旨在减少整数溢出</li>
+<li>OpenBSD dlmalloc 的扩展程序:旨在防范 double free() 漏洞和连续块攻击。连续块攻击是利用堆损坏的常见攻击方式。</li>
+<li>OpenBSD calloc:旨在防止在内存分配期间发生整数溢出</li>
+</ul>
+</dd>
+
+<dt><strong>Android 2.3</strong></dt>
+<dd><ul>
+<li>格式化字符串漏洞防护功能 (-Wformat-security -Werror=format-security)</li>
+<li>基于硬件的 No eXecute (NX):旨在防止在堆栈和堆上执行代码</li>
+<li>Linux mmap_min_addr:旨在降低空指针解引用提权风险(在 Android 4.1 中得到了进一步增强)</li>
+</ul>
+</dd>
+
+<dt><strong>Android 4.0</strong></dt>
+<dd>地址空间布局随机化 (ASLR):旨在随机排列内存中的关键位置</dd>
+
+<dt><strong>Android 4.1</strong></dt>
+<dd><ul>
+<li>PIE(位置无关可执行文件)支持</li>
+<li>只读重定位/立即绑定 (-Wl,-z,relro -Wl,-z,now)</li>
+<li>启用了 dmesg_restrict(避免内核地址泄露)</li>
+<li>启用了 kptr_restrict(避免内核地址泄露)</li>
+</ul>
+</dd>
+
+</dl>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements42.html b/zh-cn/security/enhancements/enhancements42.html
new file mode 100644
index 00000000..cf30dd65
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements42.html
@@ -0,0 +1,49 @@
+<html devsite><head>
+ <title>Android 4.2 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 提供了一个多层安全模型,<a href="/security/index.html">Android 安全性概述</a>中对该模型进行了介绍。每个 Android 更新版本中都包含数十种用于保护用户的安全增强功能。以下是 Android 4.2 中引入的一些安全增强功能:</p>
+
+<ul>
+<li><strong>应用验证</strong> - 用户可以选择启用“验证应用”,并且可以选择在应用安装之前由应用验证程序对其进行筛查。如果用户尝试安装的应用可能有害,应用验证功能可以提醒用户;如果应用的危害性非常大,应用验证功能可以阻止安装。</li>
+<li><strong>加强对付费短信的控制</strong> - 如果有应用尝试向使用付费服务的短代码发送短信(可能会产生额外的费用),Android 将会通知用户。用户可以选择是允许还是阻止该应用发送短信。</li>
+
+<li><strong>始终开启的 VPN</strong> - 可以配置 VPN,以确保在建立 VPN 连接之前应用无法访问网络。这有助于防止应用跨其他网络发送数据。</li>
+
+<li><strong>证书锁定</strong> - Android 的核心库现在支持<a href="https://developer.android.com/reference/android/net/http/X509TrustManagerExtensions.html">证书锁定</a>。如果证书未关联到一组应关联的证书,锁定的域将会收到证书验证失败消息。这有助于防范证书授权中心免遭可能的入侵。</li>
+
+<li><strong>改进后的 Android 权限显示方式</strong> - 权限划分到了多个对用户来说更清晰明了的组中。在审核权限时,用户可以点击权限来查看关于相应权限的更多详细信息。</li>
+
+<li><strong>installd 加固</strong> - <code>installd</code> 守护进程不会以 Root 用户身份运行,从而可减小 Root 提权攻击的潜在攻击面。</li>
+
+<li><strong>init 脚本加固</strong> - init 脚本现在应用 <code>O_NOFOLLOW</code> 语义来防范与符号链接相关的攻击。</li>
+
+<li><strong>FORTIFY_SOURCE</strong> - Android 现在实现了 <code>FORTIFY_SOURCE</code>。系统库和应用可以使用它来防范内存损坏。</li>
+
+<li><strong>ContentProvider 默认配置</strong> - 面向第 17 层 API 的应用会针对每个<a href="https://developer.android.com/reference/android/content/ContentProvider.html">内容提供程序</a>默认将“export”设为“false”,从而减小应用的默认受攻击面。</li>
+
+<li><strong>加密</strong> - 修改了 SecureRandom 和 Cipher.RSA 的默认实现,以便使用 OpenSSL。为使用 OpenSSL 1.0.1 的 TLSv1.1 和 TLSv1.2 添加了安全套接字支持</li>
+
+<li><strong>安全漏洞修复程序</strong> - 升级了开放源代码库,新增了一些安全漏洞修复程序,其中包括 WebKit、libpng、OpenSSL 和 LibXML。Android 4.2 中还包含针对 Android 特有漏洞的修复程序。有关这些漏洞的信息已提供给“开放手机联盟”(Open Handset Alliance) 成员,并且 Android 开放源代码项目中提供了相应的修复程序。为了提高安全性,搭载更低版本 Android 的某些设备可能也会包含这些修复程序。</li>
+
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements43.html b/zh-cn/security/enhancements/enhancements43.html
new file mode 100644
index 00000000..24805ca5
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements43.html
@@ -0,0 +1,63 @@
+<html devsite><head>
+ <title>Android 4.3 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>每个 Android 版本中都包含数十种用于保护用户的安全增强功能。以下是 Android 4.3 中提供的一些安全增强功能:</p>
+
+<ul>
+ <li><strong>通过 SELinux 得到增强的 Android 沙盒。
+</strong>此版本利用 Linux 内核中的 SELinux 强制访问控制系统 (MAC) 增强了 Android 沙盒。SELinux 强化功能(用户和开发者看不到它)可提高现有 Android 安全模型的可靠性,同时与现有应用保持兼容。为了确保持续兼容,此版本允许以宽容模式使用 SELinux。此模式会记录所有政策违规行为,但不会中断应用或影响系统行为。</li>
+
+ <li><strong>没有 SetUID/SetGID 程序:
+</strong>针对 Android 系统文件添加了对文件系统功能的支持,并移除了所有 SetUID/SetGUID 程序。这可以减小 Root 攻击面,并降低出现潜在安全漏洞的可能性。</li>
+
+ <li><strong>ADB 身份验证。
+</strong>从 Android 4.2.2 起,开始使用 RSA 密钥对为 ADB 连接进行身份验证。这可以防止攻击者在实际接触到设备的情况下未经授权使用 ADB。</li>
+
+ <li><strong>限制 Android 应用执行 SetUID 程序。
+</strong>/system 分区现在针对 Zygote 衍生的进程装载了 nosuid,以防止 Android 应用执行 SetUID 程序。这可以减小 Root 攻击面,并降低出现潜在安全漏洞的可能性。</li>
+
+ <li><strong>功能绑定。
+</strong>在执行应用之前,Android Zygote 和 ADB 现在会先使用 prctl(PR_CAPBSET_DROP) 舍弃不必要的功能。这可以防止 Android 应用和从 shell 启动的应用获取特权功能。</li>
+
+ <li><strong>AndroidKeyStore 提供程序。
+</strong>Android 现在有一个允许应用创建专用密钥的密钥库提供程序。该程序可以为应用提供一个用于创建或存储私钥的 API,其他应用将无法使用这些私钥。</li>
+
+ <li><strong>KeyChain isBoundKeyAlgorithm。
+</strong>Keychain API 现在提供了一种方法 (isBoundKeyType),可让应用确认系统级密钥是否已绑定到设备的硬件信任根。该方法提供了一个用于创建或存储私钥的位置,即使发生 Root 权限被窃取的情况,这些私钥也无法从设备中导出。</li>
+
+ <li><strong>NO_NEW_PRIVS。</strong>
+在执行应用代码之前,Android Zygote 现在会先使用 prctl(PR_SET_NO_NEW_PRIVS) 禁止添加新权限。这可以防止 Android 应用执行可通过 execve 提权的操作。(此功能需要使用 3.5 或更高版本的 Linux 内核)。</li>
+
+ <li><strong>FORTIFY_SOURCE 增强功能。
+</strong>Android x86 和 MIPS 上启用了 FORTIFY_SOURCE,并增强了 strchr()、strrchr()、strlen() 和 umask() 调用。这可以检测潜在的内存损坏漏洞或没有结束符的字符串常量。</li>
+
+ <li><strong>迁移保护。
+</strong>针对静态关联的可执行文件启用了只读迁移 (relro) 技术,并移除了 Android 代码中的所有文本迁移技术。这可以深度防范潜在的内存损坏漏洞。</li>
+
+ <li><strong>经过改进的 EntropyMixer。
+</strong>除了定期执行混合操作之外,EntropyMixer 现在还会在关机/重新启动时写入熵。这样一来,便可以保留设备开机时生成的所有熵,而这对于配置之后立即重新启动的设备来说尤其有用。</li>
+
+ <li><strong>安全漏洞修复程序。
+</strong>Android 4.3 中还包含针对 Android 特有漏洞的修复程序。有关这些漏洞的信息已提供给“开放手机联盟”(Open Handset Alliance) 成员,并且 Android 开放源代码项目中提供了相应的修复程序。为了提高安全性,搭载更低版本 Android 的某些设备可能也会包含这些修复程序。</li>
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements44.html b/zh-cn/security/enhancements/enhancements44.html
new file mode 100644
index 00000000..07d7de70
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements44.html
@@ -0,0 +1,49 @@
+<html devsite><head>
+ <title>Android 4.4 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>每个 Android 版本中都包含数十种用于保护用户的安全增强功能。以下是 Android 4.4 中提供的一些安全增强功能:</p>
+
+<ul>
+ <li><strong>通过 SELinux 得到增强的 Android 沙盒。</strong>
+Android 现在以强制模式使用 SELinux。SELinux 是 Linux 内核中的强制访问控制 (MAC) 系统,用于增强基于自主访问控制 (DAC) 的现有安全模型。这为防范潜在的安全漏洞提供了额外的保护屏障。</li>
+
+ <li><strong>按用户应用 VPN。</strong>
+多用户设备上现在按用户应用 VPN。这样一来,用户就可以通过一个 VPN 路由所有网络流量,而不会影响使用同一设备的其他用户。</li>
+
+ <li><strong>AndroidKeyStore 中的 ECDSA 提供程序支持。
+</strong>Android 现在有一个允许使用 ECDSA 和 DSA 算法的密钥库提供程序。</li>
+
+ <li><strong>设备监测警告。</strong>
+如果有任何证书添加到可允许监测已加密网络流量的设备证书库中,Android 都会向用户发出警告。</li>
+
+ <li><strong>FORTIFY_SOURCE。</strong>
+Android 现在支持 FORTIFY_SOURCE 第 2 级,并且所有代码在编译时都会受到这些保护。FORTIFY_SOURCE 已得到增强,能够与 Clang 配合使用。</li>
+
+ <li><strong>证书锁定。</strong>
+Android 4.4 能够检测安全的 SSL/TLS 通信中是否使用了欺诈性 Google 证书,并且能够阻止这种行为。</li>
+
+ <li><strong>安全漏洞修复程序。</strong>
+Android 4.4 中还包含针对 Android 特有漏洞的修复程序。有关这些漏洞的信息已提供给“开放手机联盟”(Open Handset Alliance) 成员,并且 Android 开放源代码项目中提供了相应的修复程序。为了提高安全性,搭载更低版本 Android 的某些设备可能也会包含这些修复程序。</li>
+
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements50.html b/zh-cn/security/enhancements/enhancements50.html
new file mode 100644
index 00000000..a6fc26fc
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements50.html
@@ -0,0 +1,38 @@
+<html devsite><head>
+ <title>Android 5.0 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>每个 Android 版本中都包含数十种用于保护用户的安全增强功能。以下是 Android 5.0 中提供的一些主要安全增强功能:</p>
+
+<ul>
+ <li><strong>默认加密:</strong> 在以开箱即用的方式搭载 L 的设备上,会默认启用全盘加密功能,以便更好地保护丢失设备或被盗设备上的数据。对于更新到 L 的设备,可以在<strong>设置</strong> &gt; <strong>安全性</strong>部分进行加密。
+ </li><li><strong>经过改进的全盘加密功能:</strong> 使用 <code>scrypt</code> 保护用户密码免遭暴力破解攻击;在可能的情况下,该密钥会绑定到硬件密钥库,以防范来自设备外的攻击。和以往一样,Android 屏幕锁定密钥和设备加密密钥不会被发送到设备以外,也不会提供给任何应用。
+ </li><li><strong>通过 SELinux 得到增强的 Android 沙盒</strong>:对于所有域,Android 现在都要求 SELinux 处于强制模式。SELinux 是 Linux 内核中的强制访问控制 (MAC) 系统,用于增强现有的自主访问控制 (DAC) 安全模型。这个新层为防范潜在的安全漏洞提供了额外的保护屏障。
+ </li><li><strong>Smart Lock:</strong>Android 现在包含一些 Trustlet,它们可以提供更灵活的设备解锁方式。例如,Trustlet 可让设备在靠近其他可信设备(通过 NFC、蓝牙)时或用户拥有可信面孔时自动解锁。
+ </li><li><strong>面向手机和平板电脑的多用户功能、受限个人资料和访客模式:</strong> Android 现在为手机提供了多用户功能,并包含一个访客模式。利用访客模式,您可以让访客轻松地临时使用您的设备,而不向他们授予对您的数据和应用的访问权限。
+ </li><li><strong>不使用 OTA 的 WebView 更新方式:</strong> 现在可以独立于框架对 WebView 进行更新,而且无需使用系统 OTA。这有助于更快速地应对 WebView 中的潜在安全问题。
+ </li><li><strong>经过更新的 HTTPS 和 TLS/SSL 加密功能</strong>:现在启用了 TLSv1.2 和 TLSv1.1,首选是正向加密,启用了 AES-GCM,停用了弱加密套件(MD5、3DES 和导出密码套件)。如需更多详细信息,请访问 <a href="https://developer.android.com/reference/javax/net/ssl/SSLSocket.html">https://developer.android.com/reference/javax/net/ssl/SSLSocket.html</a>。
+ </li><li><strong>移除了非 PIE 链接器支持:</strong> Android 现在要求所有动态链接的可执行文件都要支持 PIE(位置无关可执行文件)。这有助于增强 Android 的地址空间布局随机化 (ASLR) 实现。
+ </li><li><strong>FORTIFY_SOURCE 改进:</strong> 以下 libc 函数现在实现了 FORTIFY_SOURCE 保护功能:<code>stpcpy()</code>、<code>stpncpy()</code>、<code>read()</code>、<code>recvfrom()</code>、<code>FD_CLR()</code>、<code>FD_SET()</code> 和 <code>FD_ISSET()</code>。这有助于防范涉及这些函数的内存损坏漏洞。
+ </li><li><strong>安全修复程序:</strong> Android 5.0 中还包含针对 Android 特有漏洞的修复程序。有关这些漏洞的信息已提供给“开放手机联盟”(Open Handset Alliance) 成员,并且 Android 开放源代码项目中提供了相应的修复程序。为了提高安全性,搭载更低版本 Android 的某些设备可能也会包含这些修复程序。
+</li></ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements60.html b/zh-cn/security/enhancements/enhancements60.html
new file mode 100644
index 00000000..91d73747
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements60.html
@@ -0,0 +1,35 @@
+<html devsite><head>
+ <title>Android 6.0 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>每个 Android 版本中都包含数十种用于保护用户的安全增强功能。以下是 Android 6.0 中提供的一些主要安全增强功能:</p>
+<ul>
+ <li><strong>运行时权限</strong>:应用在运行时请求权限,而不是在安装时被授予权限。用户可以为 M 及更低版本的 Android 应用启用和停用权限。</li>
+ <li><strong>验证启动</strong>:在执行系统软件之前,先对其进行一系列加密检查,以确保手机从引导加载程序到操作系统均处于正常状况。</li>
+ <li><strong>硬件隔离安全措施</strong>:新的硬件抽象层 (HAL),Fingerprint API、锁定屏幕、设备加密功能和客户端证书可以利用它来保护密钥免遭内核入侵和/或现场攻击。</li>
+ <li><strong>指纹</strong>:现在,只需触摸一下,即可解锁设备。开发者还可以借助新的 API 来使用指纹锁定和解锁加密密钥。</li>
+ <li><strong>加装 SD 卡</strong>:<em></em>可将移动媒体设备加装到设备上,以便扩展可用存储空间来存放本地应用数据、照片、视频等内容,但仍受块级加密保护。</li>
+ <li><strong>明文流量</strong>:开发者可以使用新的 StrictMode 来确保其应用不会使用明文。</li>
+ <li><strong>系统加固</strong>:通过由 SELinux 强制执行的政策对系统进行加固。这可以实现更好的用户隔离和 IOCTL 过滤、降低可从设备/系统之外访问的服务面临的威胁、进一步强化 SELinux 域,以及高度限制对 /proc 的访问。</li>
+ <li><strong>USB 访问控制</strong>:必须由用户确认是否允许通过 USB 访问手机上的文件、存储空间或其他功能。<em></em>现在,默认设置是“仅充电”,如果要访问存储空间,必须获得用户的明确许可。</li>
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/enhancements70.html b/zh-cn/security/enhancements/enhancements70.html
new file mode 100644
index 00000000..161586e9
--- /dev/null
+++ b/zh-cn/security/enhancements/enhancements70.html
@@ -0,0 +1,37 @@
+<html devsite><head>
+ <title>Android 7.0 中的安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>每个 Android 版本中都包含数十项用于保护用户的安全增强功能。以下是 Android 7.0 中提供的一些主要安全增强功能:</p>
+
+<ul>
+ <li><strong>文件级加密</strong>:在文件级进行加密,而不是将整个存储区域作为单个单元进行加密。这种加密方式可以更好地隔离和保护设备上的不同用户和资料(例如个人资料和工作资料)。</li>
+ <li><strong>直接启动</strong>:通过文件级加密实现,允许特定应用(例如,闹钟和无障碍功能)在设备已开机但未解锁的情况下运行。</li>
+ <li><strong>验证启动</strong>:现在,验证启动会被严格强制执行,从而使遭到入侵的设备无法启动;验证启动支持纠错功能,有助于更可靠地防范非恶意数据损坏。</li>
+ <li><strong>SELinux</strong>:更新后的 SELinux 配置和更高的 Seccomp 覆盖率有助于进一步锁定应用沙盒并减小受攻击面。</li>
+ <li><strong>库加载顺序随机化和经过改进的 ASLR</strong>:更高的随机性可以使一些代码重用攻击得逞的难度增大。</li>
+ <li><strong>内核加固</strong>:通过将内核内存的各个分区标记为只读,限制内核对用户空间地址的访问,并进一步减小现有的受攻击面,为更高版本的内核添加额外的内存保护。</li>
+ <li><strong>APK 签名方案 v2</strong>:引入了一种全文件签名方案,该方案有助于加快验证速度并增强完整性保证。</li>
+ <li><strong>可信 CA 商店</strong>:为了使应用更轻松地控制对其安全网络流量的访问,对于目标 API 级别为 24+ 的应用来说,用户安装的证书授权中心以及通过 Device Admin API 安装的证书授权中心默认情况下不再可信。此外,所有新的 Android 设备必须搭载相同的可信 CA 存储区。</li>
+ <li><strong>网络安全配置</strong>:通过声明式配置文件来配置网络安全设置和传输层安全协议 (TLS)。</li>
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/enhancements/index.html b/zh-cn/security/enhancements/index.html
new file mode 100644
index 00000000..85adadd7
--- /dev/null
+++ b/zh-cn/security/enhancements/index.html
@@ -0,0 +1,25 @@
+<html devsite><head>
+ <title>安全增强功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 一直在不断改进其安全功能和产品/服务。您可以在左侧导航栏中查看各个版本的增强功能列表。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/index.html b/zh-cn/security/index.html
new file mode 100644
index 00000000..e6999afa
--- /dev/null
+++ b/zh-cn/security/index.html
@@ -0,0 +1,108 @@
+<html devsite><head>
+ <title>安全</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 采用了业界领先的安全功能,并与开发者和设备实现人员密切合作,以确保 Android 平台和生态系统的安全。要打造一个由基于 Android 平台以及围绕 Android 平台开发且由云服务提供支持的应用和设备组成的强大生态系统,稳定可靠的安全模型至关重要。为此,在整个开发生命周期内,Android 都遵循了严格的安全计划。
+</p>
+<p>
+<strong>Android 是一款开放的系统</strong>。Android 应用使用通过 Android 平台提供的先进硬件和软件以及本地数据和收到的数据,为消费者带来创新和价值。为了实现这一价值,Android 平台提供了一个应用环境,该环境可以保护用户、数据、应用、设备和网络的机密性、完整性与可用性。
+</p>
+<p>保障开放平台的安全需要强大的安全架构和严格的安全程序。Android 采用了一个多层安全模型,该模型非常灵活,能够在支持开放平台的同时保护平台的所有用户。如需关于报告安全问题以及关于更新流程的信息,请参阅<a href="/security/overview/updates-resources.html">安全更新和资源</a>。
+</p>
+<p>
+<strong>Android 适合开发者使用</strong>。Android 中设计了多种旨在减轻开发者负担的安全控制机制。精通安全技术的开发者可以轻松使用并依赖灵活的安全控制机制。不太熟悉安全技术的开发者则由默认的安全机制提供保护。
+</p>
+<p>除了提供一个稳定的平台来供开发者开发应用之外,Android 还以多种方式为开发者提供其他支持。Android 安全团队会检查应用中是否存在潜在漏洞,并会提出关于如何解决这些问题的建议。对于带有 Google Play 的设备,Play 服务会为关键软件库(例如,用于保障应用通信安全的 OpenSSL)提供安全更新。Android 安全团队发布了一款用于测试 SSL 的工具 (<a href="https://github.com/google/nogotofail">Nogotofail</a>),该工具可以协助开发者发现潜在的安全问题,无论他们是在使用什么平台进行开发。
+</p>
+<p>如需面向 Android 应用开发者的更多信息,请访问 <a href="https://developer.android.com/training/best-security.html">developer.android.com</a>。
+</p>
+<p>
+<strong>Android 适合用户使用</strong>。用户可以查看每个应用请求的权限,并可以对这些权限加以控制。这种设计考虑到了攻击者可能会尝试进行一些常见的攻击,例如,诱使设备用户安装恶意软件的社会工程攻击,以及对 Android 上的第三方应用的攻击。Android 能够降低受到这些攻击的可能性,并能够大大限制攻击成功时造成的影响。在设备到达用户手中后,Android 的安全性将会不断提升:Android 会与<a href="/security/overview/acknowledgements.html">合作伙伴和公众</a>密切合作,为还在继续接收安全更新的所有 Android 设备提供补丁程序。
+</p>
+<p>如需面向最终用户的更多信息,请访问 <a href="https://support.google.com/nexus/answer/6172890">Nexus 帮助中心</a>、<a href="https://support.google.com/pixelphone/answer/6172890">Pixel 帮助中心</a>或设备制造商的帮助中心。
+</p>
+<p>本文档概述了 Android 安全计划的目标,介绍了 Android 安全架构方面的基础知识,并解答了对系统架构师和安全分析人员来说最相关的问题。本文档重点介绍 Android 核心平台的安全功能,而不是讨论具体应用特有的安全问题,例如,与浏览器或短信应用相关的问题。
+</p>
+
+<h2 id="background">背景</h2>
+<p>Android 提供了一个适用于移动设备的开放源代码平台和应用环境。
+</p>
+<p>以下各个部分和页面介绍了 Android 平台的安全功能。<em></em>图 1 总结了 Android 软件堆栈各个层的安全组件和注意事项。每个组件都假定下面的组件均已采取适当的安全措施。除了作为 Root 代码运行的少量 Android 操作系统代码外,Linux 内核上方的所有代码都受应用沙盒的限制。
+</p>
+
+<p><img alt="图 1:Android 软件堆栈" src="images/android_software_stack.png"/></p>
+<p class="img-caption">
+<strong>图 1</strong>. Android 软件堆栈。
+</p>
+<p>Android 平台的主要构造块包括:</p>
+<ul>
+ <li><strong>设备硬件</strong>:Android 能够在多种硬件配置中运行,其中包括智能手机、平板电脑、手表、汽车、智能电视、OTT 游戏盒和机顶盒。Android 独立于处理器,但它确实利用了一些针对硬件的安全功能,例如 ARM eXecute-Never。</li>
+ <li><strong>Android 操作系统</strong>:核心操作系统是在 Linux 内核之上构建的。所有设备资源(例如,摄像头功能、GPS 数据、蓝牙功能、电话功能、网络连接等)都通过该操作系统访问。</li>
+ <li><strong>Android 应用运行时</strong>:Android 应用通常都是使用 Java 编程语言编写的,并在 Android 运行时 (ART) 中运行。不过,仍有许多应用(包括核心 Android 服务和应用)是本机应用或包含本机库。ART 和本机应用在相同的安全环境中运行(包含在应用沙盒内)。应用在文件系统中有一个专用部分,它们可以在其中写入私密数据,包括数据库和原始文件。</li>
+</ul>
+<p>Android 应用扩展了 Android 核心操作系统。应用有两个主要来源:</p>
+<ul>
+ <li><strong>预先安装的应用</strong>:Android 包括一套预先安装的应用,其中包括电话、电子邮件、日历、网络浏览器和通讯录应用。这些应用不仅能够用作用户应用,而且能够提供可供其他应用访问的关键设备功能。预先安装的应用可能是开放源代码 Android 平台的一部分,也可能是由具体设备的制造商开发的。</li>
+ <li><strong>用户安装的应用</strong>:Android 提供了一个支持任何第三方应用的开放式开发环境。Google Play 为用户提供了数十万款应用。</li>
+</ul>
+
+<h2 id="google-security-services">Google 安全服务</h2>
+<p>Google 提供了一套基于云的服务,用户可通过 <a href="https://www.android.com/gms/">Google 移动服务</a>将这些服务安装到兼容的 Android 设备上。虽然这些服务不是 Android 开放源代码项目的一部分,但它们包含在许多 Android 设备中。如需关于其中部分服务的更多信息,请参阅 Android 安全团队发布的 <a href="/security/reports/Google_Android_Security_2015_Report_Final.pdf">2015 年年度回顾报告</a>。
+</p>
+<p>Google 的主要安全服务包括:</p>
+<ul>
+ <li><strong>Google Play</strong>:Google Play 是一系列服务的总称。借助这些服务,用户可以通过自己的 Android 设备或网络发现、安装和购买应用。Google Play 可让开发者轻松覆盖 Android 用户和潜在客户。此外,Google Play 还提供社区审核、应用<a href="https://developer.android.com/guide/publishing/licensing.html">许可验证</a>、应用安全扫描以及其他安全服务。</li>
+ <li><strong>Android 更新</strong>:Android 更新服务可为某些 Android 设备提供新功能和安全更新,其中包括通过网络或无线下载 (OTA) 方式提供的更新。</li>
+ <li><strong>应用服务</strong>:可让 Android 应用使用云功能的框架,例如应用数据和设置<a href="https://developer.android.com/guide/topics/data/backup.html">备份</a>功能,以及用于推送消息的云端至设备消息传递功能 (<a href="https://developers.google.com/cloud-messaging/">C2DM</a>)。</li>
+ <li><strong>验证应用</strong>:在用户安装有害应用时发出警告或自动阻止安装;持续扫描设备上的应用,并在发现<a href="https://support.google.com/accounts/answer/2812853">有害应用</a>时发出警告或将其移除。
+ </li>
+ <li><strong>SafetyNet</strong>:一款旨在保护隐私的入侵检测系统,能够帮助 Google 跟踪和降低已知的安全威胁,并能够发现新的安全威胁。</li>
+ <li><strong>SafetyNet Attestation</strong>:用于确定设备是否与 CTS 兼容的第三方 API。<a href="http://developer.android.com/training/safetynet/index.html">Attestation</a> 还可以协助识别与应用服务器通信的 Android 应用。</li>
+ <li><strong>Android 设备管理器</strong>:既是一款<a href="https://www.google.com/android/devicemanager">网络应用</a>,也是一款 <a href="https://play.google.com/store/apps/details?id=com.google.android.apps.adm">Android 应用</a>,用于寻找丢失的设备或被盗的设备。</li>
+</ul>
+
+<h2 id="security-program-overview">安全计划概述</h2>
+<p>Android 安全计划的关键组成部分包括:</p>
+<ul>
+ <li><strong>设计审核</strong>:Android 安全流程在开发生命周期的早期便开始了,并会在这一阶段创建大量的可配置安全模型和设计。平台的每项主要功能都会由工程和安全资源进行审核,并且适当的安全控制机制会被集成到系统架构中。</li>
+ <li><strong>渗透测试和代码审核</strong>:在平台开发期间,Android 创建的组件和开放源代码组件都要接受严格的安全审核。这些审核由 Android 安全团队、Google 的信息安全工程团队和独立的安全顾问进行。这些审核的目标是在主要版本发布之前找出存在的缺陷和可能的漏洞,并模拟将由外部安全专家在平台发布时进行的各种类型的分析。</li>
+ <li><strong>开放源代码和社区审核</strong>:Android 开放源代码项目允许任何感兴趣者对其进行广泛的安全审核。Android 还使用已经过重要外部安全审核的开放源代码技术,例如 Linux 内核。Google Play 面向用户和公司开设了一个论坛,以便直接向用户提供与具体应用相关的信息。</li>
+ <li><strong>事件响应</strong>:即使采取了所有这些预防措施,平台发布后也仍可能会出现安全问题,为此,Android 项目制定了一个全面的安全响应流程。Android 安全团队有全职成员负责监控用于讨论潜在漏洞的 Android 专用安全社区和一般安全社区,并且他们会查看提交到 Android 错误数据库中的<a href="/security/overview/updates-resources.html#android_security_bug_lifecycle">安全错误</a>。发现确实存在的问题后,Android 团队会启动响应流程,以便快速修复漏洞,确保将所有 Android 用户面临的潜在风险降至最低。这些云支持的响应可能包括更新 Android 平台(无线下载更新)、从 Google Play 中移除应用,以及从现场设备中移除应用。</li>
+ <li><strong>每月安全更新</strong>:Android 安全团队会为 Google Nexus 设备和所有设备制造合作伙伴提供<a href="/security/bulletin/index.html">每月更新</a>。</li>
+</ul>
+
+<h2 id="platform-security-architecture">平台安全架构</h2>
+<p>通过将传统的操作系统安全控制机制扩展到以下用途,Android 致力于成为最安全、最实用的移动平台操作系统:</p>
+<ul>
+ <li>保护应用和用户数据</li>
+ <li>保护系统资源(包括网络)</li>
+ <li>将应用同系统、其他应用和用户隔离开来</li>
+</ul>
+<p>为了实现这些目标,Android 提供了以下关键安全功能:</p>
+<ul>
+ <li>通过 Linux 内核在操作系统级别提供的强大安全功能</li>
+ <li>针对所有应用的强制性应用沙盒</li>
+ <li>安全的进程间通信</li>
+ <li>应用签名</li>
+ <li>应用定义的权限和用户授予的权限</li>
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/keystore/features.html b/zh-cn/security/keystore/features.html
new file mode 100644
index 00000000..1292e1b3
--- /dev/null
+++ b/zh-cn/security/keystore/features.html
@@ -0,0 +1,217 @@
+<html devsite><head>
+ <title>功能</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>本页中包含与 Android 6.0 中 <a href="index.html">Keystore</a> 的功能相关的信息。</p>
+
+<h2 id="cryptographic_primitives">加密基元</h2>
+
+<p>Keystore 能够提供以下类别的操作:</p>
+
+<ul>
+ <li>生成密钥</li><li>导入和导出不对称密钥(无密钥包装)</li><li>导入原始对称密钥(同样无包装)</li><li>使用适当的填充模式进行不对称加密和解密</li><li>使用摘要和适当的填充模式进行不对称签名和验证</li><li>以适当模式(包括 AEAD 模式)进行对称加密和解密</li><li>生成和验证对称消息验证码</li></ul>
+
+<p>生成或导入密钥时,必须指定协议元素(例如,目的、模式和填充,以及<a href="#key_access_control">访问控制限制</a>),这些元素会永久绑定到相应密钥,以确保无法以任何其他方式使用相应密钥。</p>
+
+<p>除了上面列出的操作外,Keymaster 实现还必须再提供一项服务,即随机数生成服务,但该服务并不作为 API 进行提供。该服务仅供在内部使用,用于生成密钥、初始化矢量 (IV)、随机填充,以及其他需要具有随机性的安全协议元素。</p>
+
+<h2 id="required_primitives">必需的基元</h2>
+
+<p>所有实现都必须提供:</p>
+
+<ul>
+ <li><a href="http://en.wikipedia.org/wiki/RSA_(cryptosystem)">RSA</a>
+ <ul>
+ <li>必须支持 2048 位、3072 位和 4096 位密钥</li><li>支持公开指数 F4 (2^16+1)</li><li>对于 RSA 签名,必需的填充模式为:<ul>
+ <li>无填充(已弃用,将于日后移除)</li><li>RSASSA-PSS (<code>KM_PAD_RSA_PSS</code>)</li><li>RSASSA-PKCS1-v1_5 (<code>KM_PAD_RSA_PKCS1_1_5_SIGN</code>)</li></ul>
+ </li><li>对于 RSA 签名,必需的摘要模式为:<ul>
+ <li>无摘要(已弃用,将于日后移除)</li><li>SHA-256</li></ul>
+ </li><li>对于 RSA 加密/解密,必需的填充模式为:<ul>
+ <li>无填充</li><li>RSAES-OAEP (<code>KM_PAD_RSA_OAEP</code>)</li><li>RSAES-PKCS1-v1_5 (<code>KM_PAD_RSA_PKCS1_1_5_ENCRYPT</code>)</li></ul>
+ </li></ul>
+ </li><li><a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA">ECDSA</a>
+ <ul>
+ <li>必须支持 224 位、256 位、384 位和 521 位密钥,分别使用 NIST P-224、P-256、P-384 和 P-521 曲线</li><li>对于 ECDSA,必需的摘要模式为:<ul>
+ <li>无摘要(已弃用,将于日后移除)</li><li>SHA-256</li></ul>
+ </li></ul>
+ </li><li><a href="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard">AES</a>
+ <ul>
+ <li>必须提供 128 位和 256 位密钥</li><li><a href="http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29">CBC</a>、CTR、ECB 和 GCM。GCM 实现不得允许使用少于 96 位的标记,也不得允许使用 96 位以外的随机数长度。
+ </li><li>对于 CBC 和 ECB 模式,必须支持填充模式 <code>KM_PAD_NONE</code> 和 <code>KM_PAD_PKCS7</code>。采用“无填充”时,如果输入的不是分块大小的倍数,CBC 或 ECB 模式的加密必须失败。
+ </li></ul>
+ </li><li><a href="http://en.wikipedia.org/wiki/Hash-based_message_authentication_code">HMAC</a> <a href="http://en.wikipedia.org/wiki/SHA-2">SHA-256</a>,其中任意密钥均不得短于 32 个字节。
+</li></ul>
+
+<p>强烈建议(但并不强制要求)提供 SHA1,以及 SHA2 系列的其他成员(SHA-224、SHA384 和 SHA512)。如果硬件 Keymaster 实现未提供这些内容,Keystore 将在软件中提供它们。</p>
+
+<p>此外,为了实现与其他系统的互用性,还建议提供以下基元:</p>
+
+<ul>
+ <li>适用于 RSA 的较小密钥大小</li><li>适用于 RSA 的任意公开指数</li></ul>
+
+<h2 id="key_access_control">密钥访问控制</h2>
+
+<p>如果攻击者可以随意使用在任何情况下都无法从设备获取的基于硬件的密钥,那么此类密钥将无法提供太多的安全性(尽管它们比可被窃取的密钥更安全)。<em></em>因此,Keystore 强制执行访问控制至关重要。</p>
+
+<p>访问控制指的是由“标记/值”对组成的“授权列表”。授权标记是 32 位整数,其值有多种类型。有些标记可以重复使用,以指定多个值。某个标记是否可重复使用是在关于该标记的文档中指定的。密钥创建好后,调用程序会指定一个授权列表。Keymaster 实现使用的底层 Keystore 将会修改该列表,以指定一些额外的信息(例如,密钥是否有防回滚保护),并且会返回一个“最终”授权列表(编码到返回的密钥 Blob 中)。如果最终授权列表被修改了,那么任何尝试使用相应密钥进行任何加密操作的行为都必须失败。</p>
+
+<p>枚举 <code>keymaster_authorization_tag_t</code> 中定义了一组可能的标记,这组标记必须永远保持不变(不过可进行扩展)。这些标记的名称带有 <code>KM_TAG_</code> 前缀。标记 ID 的前四位用于指明类型。</p>
+
+<p>可能的类型包括:</p>
+
+<p><strong><code>KM_ENUM</code>:</strong>很多标记的值都是在枚举中定义的。例如,<code>KM_TAG_PURPOSE</code> 的可能值是在枚举 <code>keymaster_purpose_t</code> 中定义的。</p>
+
+<p><strong><code>KM_ENUM_REP</code></strong>:与 <code>KM_ENUM</code> 相同,不过此标记可在授权列表中重复使用。重复使用此标记表明有多个已获授权的值。例如,某个加密密钥可能有 <code>KM_PURPOSE_ENCRYPT</code> 和 <code>KM_PURPOSE_DECRYPT</code>。</p>
+
+<p><strong><code>KM_UINT</code>:</strong>32 位未签名整数。例如:<code>KM_TAG_KEY_SIZE</code></p>
+
+<p><strong><code>KM_UINT_REP</code></strong>:与 <code>KM_UINT</code> 相同,不过此标记可在授权列表中重复使用。重复使用此标记表明有多个已获授权的值。</p>
+
+<p><strong><code>KM_ULONG</code></strong>:64 位未签名整数。例如:<code>KM_TAG_RSA_PUBLIC_EXPONENT</code></p>
+
+<p><strong><code>KM_ULONG_REP</code></strong>:与 <code>KM_ULONG</code> 相同,不过此标记可在授权列表中重复使用。重复使用此标记表明有多个已获授权的值。</p>
+
+<p><strong><code>KM_DATE</code></strong>:日期/时间值,以距 1970 年 1 月 1 日的毫秒数表示。例如:<code>KM_TAG_PRIVKEY_EXPIRE_DATETIME</code></p>
+
+<p><strong><code>KM_BOOL</code></strong>:True 或 False。对于 <code>KM_BOOL</code> 类型的标记,如果不存在则被视为“false”,如果存在则被视为“true”。例如:<code>KM_TAG_ROLLBACK_RESISTANT</code></p>
+
+<p><strong><code>KM_BIGNUM</code></strong>:任意长度的整数,以字节数数组表示(采用大端字节存)。例如:<code>KM_TAG_RSA_PUBLIC_EXPONENT</code></p>
+
+<p><strong><code>KM_BYTES</code></strong>:一系列字节数。例如:<code>KM_TAG_ROOT_OF_TRUST</code></p>
+
+<h3 id="hardware_vs_software_enforcement">硬件与软件强制执行</h3>
+
+<p>并非所有安全硬件都将实现相同的功能。为了支持多种方法,Keymaster 1.0 会对安全域和非安全域访问控制强制执行(分别称为硬件强制执行和软件强制执行)加以区分。</p>
+
+<p>实现必须:</p>
+
+<ul>
+
+ <li>强制执行所有授权完全匹配(不是强制执行所有授权)。密钥 Blob 中的授权列表必须与密钥生成期间返回的授权完全匹配(包括顺序)。如有任何不匹配,必须导致进行错误诊断。
+
+ </li><li>声明语义值会被强制执行的授权。
+
+</li></ul>
+
+<p>用于声明由硬件强制执行的授权的 API 机制位于 <code>keymaster_key_characteristics_t</code> 结构中。它将授权列表划分成两个子列表:<code>hw_enforced</code> 和 <code>sw_enforced</code>。安全硬件负责根据它可以强制执行的内容在每个子列表中放入适当的值。</p>
+
+<p>此外,Keystore 会实现基于软件强制执行所有授权,无论它们是否由安全硬件强制执行。<em></em></p>
+
+<p>让我们以一个不支持密钥过期日期且基于 TrustZone 的实现为例。实现仍可能会创建一个具有过期日期的密钥。该密钥的授权列表将包含具有过期日期的 <code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code> 标记。向 Keystore 发出的密钥特性请求将会在 <code>sw_enforced</code> 列表中找到此标记,并且安全硬件不会强制执行过期日期要求。不过,如果尝试在过期日期之后使用该密钥,则会被 Keystore 拒绝。</p>
+
+<p>如果设备随后进行了升级,采用了不支持过期日期的安全硬件,那么密钥特性请求将会在 <code>hw_enforced</code> 列表中找到 <code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code>,并且即使以某种方式破坏或规避 Keystore,尝试在过期日期之后使用相应密钥也会失败。</p>
+
+<h3 id="cryptographic_message_construction_authorizations">加密消息构建授权</h3>
+
+<p>以下标记用于定义使用关联密钥的操作的加密特性:<code>KM_TAG_ALGORITHM</code>、<code>KM_TAG_KEY_SIZE</code>、<code>KM_TAG_BLOCK_MODE</code>、<code>KM_TAG_PADDING</code>、<code>KM_TAG_CALLER_NONCE</code> 和 <code>KM_TAG_DIGEST</code></p>
+
+<p><code>KM_TAG_PADDING</code>、<code>KM_TAG_DIGEST</code> 和 <code>KM_PAD_BLOCK_MODE</code> 可重复使用,这意味着可以将多个值与一个密钥相关联,并且要使用的值将在操作时指定。</p>
+
+<h3 id="purpose">目的</h3>
+
+<p>密钥有一组关联的目的,这些目的以一个或多个带有 <code>KM_TAG_PURPOSE</code> 标记(用于定义可以如何使用相应密钥)的授权条目表示。这些目的是:</p>
+
+<ul>
+ <li><code>KM_PURPOSE_ENCRYPT</code>
+ </li><li><code>KM_PURPOSE_DECRYPT</code>
+ </li><li><code>KM_PURPOSE_SIGN</code>
+ </li><li><code>KM_PURPOSE_VERIFY</code>
+</li></ul>
+
+<p>任意密钥都可以具有这些目的任意组合。请注意,有些组合会带来安全问题。例如,如果某个 RSA 密钥可用于加密和签名,那么能够诱使系统解密任意数据的攻击者就可以利用该密钥来生成签名。</p>
+
+<h3 id="import_and_export">导入和导出</h3>
+
+<p>Keymaster 仅支持以 X.509 格式导出公钥,并支持:</p>
+
+<ul>
+ <li>以未采用密码加密的 DER 编码 PKCS#8 格式导入公钥和私钥对</li><li>以原始字节形式导入对称密钥</li></ul>
+
+<p>为了确保导入的密钥可与安全生成的密钥区分开来,相应密钥授权列表中会包含 <code>KM_TAG_ORIGIN</code>。例如,如果密钥是在安全硬件中生成的,<code>hw_enforced</code> 密钥特性列表中将有值为 <code>KM_ORIGIN_GENERATED</code> 的 <code>KM_TAG_ORIGIN</code>,如果密钥是导入到安全硬件中的,值将为 <code>KM_ORIGIN_IMPORTED</code>。</p>
+
+<h3 id="user_authentication">用户身份验证</h3>
+
+<p>安全的 Keymaster 实现不会实现用户身份验证,但会依赖于其他实现用户身份验证的可信应用。对于必须由这些应用实现的接口,请参阅 Gatekeeper 页面。</p>
+
+<p>用户身份验证要求是通过两组标记指定的。第一组用于指明哪些用户可以使用相应密钥:</p>
+
+<ul>
+ <li><code>KM_TAG_ALL_USERS</code> 表示所有用户都可以使用相应密钥。如果有此标记,则不得有 <code>KM_TAG_USER_ID</code> 和 <code>KM_TAG_SECURE_USER_ID</code>。
+ </li><li><code>KM_TAG_USER_ID</code> 有一个数字值,用于指定已获授权用户的 ID。请注意,此值是 Android 用户 ID(适用于多用户环境)而非应用 UID,且仅由非安全软件强制执行。如果有此标记,则不得有 <code>KM_TAG_ALL_USERS</code>。
+ </li><li><code>KM_TAG_SECURE_USER_ID</code> 有一个 64 位数字值,用于指定安全用户 ID。必须在安全身份验证令牌中提供该 ID,才能获得使用相应密钥的授权。在重复使用此标记的情况下,只要在安全身份验证令牌中提供了此标记的任何一个值,即可使用相应密钥。
+</li></ul>
+
+<p>第二组用于指明是否必须对用户进行身份验证以及何时进行验证。如果不存在以下任一标记,但有 <code>KM_TAG_SECURE_USER_ID</code>,则表示每次使用相应密钥时均需要经过身份验证。</p>
+
+<ul>
+ <li><code>KM_NO_AUTHENTICATION_REQUIRED</code> 表示无需进行任何用户身份验证,不过仍只有以通过 <code>KM_TAG_USER_ID</code> 指定的用户身份运行的应用可以使用相应密钥。</li><li><code>KM_TAG_AUTH_TIMEOUT</code> 是一个数字值,用于指定用户身份验证必须多新(以秒数计)才能授权使用相应密钥。此标记仅适用于私钥/密钥操作。公钥操作不需要进行身份验证。设备重新启动后超时将会失效;设备重新启动后,所有密钥的状态均为“从未经过身份验证”。可以将超时设为一个较大的值,以指明每次设备启动后只需进行一次身份验证(2^32 秒约为 136 年;Android 设备的重新启动时间间隔一般不会超过该值)。
+</li></ul>
+
+<h3 id="client_binding">客户端绑定</h3>
+
+<p>客户端绑定(即将密钥与特定客户端应用相关联)是通过一个可选客户端 ID 和一些可选客户端数据(分别是 <code>KM_TAG_APPLICATION_ID</code> 和 <code>KM_TAG_APPLICATION_DATA</code>)实现的。Keystore 会将这些值视为不透明 Blob,仅用于确保密钥生成/导入期间存在的 Blob 在每次使用相应密钥时都存在,并且每个字节都完全相同。客户端绑定数据不是由 Keymaster 返回的。调用程序必须知道这些数据,才能使用相应密钥。</p>
+
+<p>此功能未提供给应用。
+
+</p><h3 id="expiration">过期日期</h3>
+
+<p>Keystore 支持按日期限制密钥的使用。可以将密钥有效期开始日期和过期日期同密钥相关联,这样一来,如果当前日期/时间不在有效期范围内,Keymaster 将拒绝执行密钥操作。密钥有效期范围是使用 <code>KM_TAG_ACTIVE_DATETIME</code>、<code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code> 和 <code>KM_TAG_USAGE_EXPIRE_DATETIME</code> 标记指定的。“ORIGINATION”和“USAGE”之间的区别在于使用相应密钥是为了“生成”新的密文/签名/等,还是“使用”现有密文/签名/等。请注意,此区别未提供给应用。</p>
+
+<p><code>KM_TAG_ACTIVE_DATETIME</code>、<code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code> 和 <code>KM_TAG_USAGE_EXPIRE_DATETIME</code> 是可选标记。如果缺少这些标记,相应密钥会被视为可随时用于解密/验证消息。</p>
+
+<p>由于挂钟时间是由非安全域提供的,因此与过期日期相关的标记不可能位于由硬件强制执行的列表中。如果由硬件强制执行过期日期,将需要安全域以某种方式获取可信时间和数据,例如通过具有可信远程时间服务器的质询响应协议。</p>
+
+<h3 id="root_of_trust_binding">信任根绑定</h3>
+
+<p>Keystore 要求将密钥绑定到一个信任根。信任根是在启动期间提供给 Keymaster 安全硬件的一个位串(最好由引导加载程序提供)。该位串必须以加密形式绑定到由 Keymaster 管理的每个密钥。</p>
+
+<p>信任根包含一个公钥,该公钥用于验证启动映像上的签名和设备的锁定状态。如果该公钥被更改了(以允许使用不同的系统映像),或锁定状态发生了变化,之前的系统创建的受 Keymaster 保护的所有密钥都将无法再使用,除非之前的信任根已恢复并且通过相应密钥签名的系统已启动。这是为了确保由攻击者安装的操作系统无法使用 Keymaster 密钥,从而提高由软件强制执行的密钥访问控制所发挥的作用。</p>
+
+<h3 id="standalone_keys">独立密钥</h3>
+
+<p>有些 Keymaster 安全硬件可以将密钥材料存储在内部并返回句柄(而非经过加密的密钥材料)。也可能会存在相应密钥在一些其他非安全域或安全域系统组件可用之前无法使用的其他情况。Keymaster 1.0 HAL 允许调用程序通过 <code>KM_TAG_STANDALONE</code> 标记请求将密钥设为“独立”密钥,这意味着,除了 Blob 和运行中的 Keymaster 系统之外,不需要任何其他资源。要想知道某个密钥是否为独立密钥,可以查看与该密钥关联的标记。目前只为此标记定义了两个值:</p>
+
+<ul>
+ <li><code>KM_BLOB_STANDALONE</code>
+ </li><li><code>KM_BLOB_REQUIRES_FILE_SYSTEM</code>
+</li></ul>
+
+<p>此功能未提供给应用。
+
+</p><h3 id="velocity">使用时间间隔</h3>
+
+<p>密钥创建好后,可以通过 <code>KM_TAG_MIN_SECONDS_BETWEEN_OPS</code> 指定使用时间间隔上限。如果距离上次使用相应密钥执行操作的时间还没有超过 <code>KM_TAG_MIN_SECONDS_BETWEEN_OPS</code> 秒,TrustZone 实现将拒绝再次使用相应密钥执行加密操作。</p>
+
+<p>要实现使用时间间隔上限,一种非常简单的方法是创建一个用于存放密钥 ID 和上次使用时间戳的表格。该表格可能有大小限制,但必须能够容纳至少 16 个条目。如果该表格已被占满,并且没有任何可以更新或舍弃的条目,那么安全硬件实现必须“安全失败”,最好是拒绝所有受密钥使用时间间隔限制的密钥操作,直到其中一个条目过期为止。可设为所有条目在设备重新启动时过期。</p>
+
+<p>也可以通过 <code>KM_TAG_MAX_USES_PER_BOOT</code> 将密钥限制为每次设备启动后最多使用 n 次。<em></em>这也需要一个跟踪表格(必须能够容纳至少 4 个密钥),并且也必须能够安全失败。请注意,应用无法创建按设备启动限制使用次数的密钥。该功能不会在 Keystore 之外提供,而且仅用于系统操作。</p>
+
+<p>此功能未提供给应用。</p>
+
+<h3 id="random_number_generator_re-seeding">随机数生成器补种</h3>
+
+<p>由于安全硬件必须生成随机数(在密钥材料中使用)和初始化矢量 (IV),而且硬件随机数生成器可能并非始终可信,因此 Keymaster HAL 会提供一个接口,以便客户端提供额外的熵(将与生成的随机数混合在一起)。</p>
+
+<p>必须使用硬件随机数生成器作为主要种子来源,并且通过外部 API 提供的种子数据不能是生成数字时所用随机数据的唯一来源。此外,如果有任何一个种子来源不可预测,所使用的混合操作必须要确保随机输出不可预测。</p>
+
+<p>此功能未提供给应用,但可供框架使用。框架会定期为安全硬件提供从 Java SecureRandom 实例获取的其他熵。
+
+</p></body></html> \ No newline at end of file
diff --git a/zh-cn/security/keystore/index.html b/zh-cn/security/keystore/index.html
new file mode 100644
index 00000000..a586cbe9
--- /dev/null
+++ b/zh-cn/security/keystore/index.html
@@ -0,0 +1,55 @@
+<html devsite><head>
+ <title>由硬件支持的 Keystore</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>借助系统芯片 (SoC) 中提供的可信执行环境,Android 设备可以为 Android 操作系统、平台服务甚至是第三方应用提供由硬件支持的强大安全服务。寻求 Android 专用扩展程序的开发者应访问 <a href="https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.html">android.security.keystore</a>。</p>
+
+<p>Keystore 在 Android 6.0 中得到了<a href="features.html">显著增强</a>,不仅增加了对称加密基元(AES 和 HMAC),还增加了针对由硬件支持的密钥的访问控制系统。访问控制在密钥生成期间指定,并会在密钥的整个生命周期内被强制执行。可以将密钥限定为仅在用户通过身份验证后才可使用,并且只能用于指定的目的或只有在具有指定的加密参数时才可使用。如需更多信息,请参阅<a href="implementer-ref.html">面向实现人员的参考资料</a>。</p>
+
+<p>在 Android 6.0 之前的版本中,Android 已有一个非常简单的由硬件支持的加密服务 API(由 0.2 和 0.3 版的 Keymaster 硬件抽象层 (HAL) 提供)。该 Keystore 能够提供数字签名和验证操作,以及不对称签名密钥对的生成和导入操作。该 API 在许多设备上都已实现,但有许多安全目标无法只通过一个签名 API 来轻松达成。Android 6.0 中的 Keystore 在该 Keystore API 的基础上进行了扩展,能够提供更广泛的功能。</p>
+
+<h2 id="goals">目标</h2>
+
+<p>Android 6.0 Keystore API 和底层 Keymaster 1.0 HAL 的目标是提供一套基本的但足以满足需求的加密基元,以便使用访问受控且由硬件支持的密钥实现相关协议。</p>
+
+<p>除了扩大加密基元的范围外,Android 6.0 中的 Keystore 还增加了以下内容:</p>
+
+<ul>
+ <li>一种使用控制方案:用于限制密钥的使用,并降低因滥用密钥而导致安全性受损的风险</li><li>一种访问控制方案:用于限定只有指定的用户和客户端能够使用相应密钥,并且只能在定义的时间范围内使用</li></ul>
+
+<h2 id="architecture">架构</h2>
+
+<p>Keymaster HAL 是由原始设备制造商 (OEM) 提供的动态加载库,Keystore 服务使用它来提供由硬件支持的加密服务。HAL 实现不得在用户空间(甚至是内核空间)中执行任何敏感操作。敏感操作会被委派给通过某个内核接口连接的安全处理器。最终的架构如下所示:</p>
+
+<div align="center">
+ <img src="../images/access-to-keymaster.png" alt="访问 Keymaster" id="figure1"/>
+</div>
+<p class="img-caption"><strong>图 1. </strong> 访问 Keymaster</p>
+
+<p>在 Android 设备中,Keymaster HAL 的“客户端”包含多个层(例如,应用、框架、Keystore 守护进程),但在本文档中可以将其忽略。这意味着,所介绍的 Keymaster HAL API 为底层 API,供平台内部组件使用,不面向应用开发者提供。<a href="https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.html">Android 开发者网站</a>对更高层 API(第 23 层 API)进行了介绍。</p>
+
+<p>Keymaster HAL 的目的不是实现安全敏感型算法,而只是对发送到安全域的请求进行编排和解排。传输格式是由实现定义的。</p>
+
+<h2 id="compatibility_with_previous_versions">与之前版本的兼容性</h2>
+
+<p>Keymaster v1.0 HAL 与之前发布的 HAL(例如,Keymaster v0.2 和 v0.3)完全不兼容。为了在采用旧版 Keymaster HAL 且搭载的 Android 版本低于 Marshmallow 的设备上实现互用性,Keystore 提供了一个可通过调用现有硬件库来实现 1.0 HAL 的适配器。但结果是,它并不能提供 1.0 HAL 中的全部功能。尤其是,它仅支持 RSA 和 ECDSA 算法,而且所有密钥授权强制执行都将由该适配器在非安全域中进行。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/overview/app-security.html b/zh-cn/security/overview/app-security.html
new file mode 100644
index 00000000..0f69ae74
--- /dev/null
+++ b/zh-cn/security/overview/app-security.html
@@ -0,0 +1,154 @@
+<html devsite><head>
+ <title>应用安全</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="elements-of-applications">应用元素</h2>
+<p>Android 提供了一个适用于移动设备的开放源代码平台和应用环境。核心操作系统基于 Linux 内核。Android 应用通常都是使用 Java 编程语言编写的,并在 Dalvik 虚拟机中运行。不过,也可以使用本机代码编写应用。应用是通过文件扩展名为 .apk 的单个文件安装的。</p>
+<p>Android 应用的主要构造块包括:</p>
+<ul>
+ <li>
+ <p><strong>AndroidManifest.xml</strong>:<a href="https://developer.android.com/guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a> 是控制文件,用于告诉系统如何处理应用中的所有顶级组件(具体来说就是下面介绍的活动、服务、广播接收器和内容提供程序)。该文件还用于指定需要哪些权限。</p>
+ </li>
+ <li>
+ <p><strong>活动</strong>:一般情况下,<a href="https://developer.android.com/guide/topics/fundamentals/activities.html">活动</a>是指聚焦于用户的单个任务的代码。活动通常包括向用户显示界面,但并不一定会这样,有些活动就从不显示界面。通常情况下,应用的入口点是应用的其中一项活动。</p>
+ </li>
+ <li>
+ <p><strong>服务</strong>:<a href="https://developer.android.com/guide/topics/fundamentals/services.html">服务</a>是指在后台运行的代码的主体。服务可以在自己的进程中运行,也可以在其他应用的进程中运行。其他组件会“绑定”到某项服务,并通过远程过程调用来调用该服务的方法。比如媒体播放器就是一项服务:即使用户退出媒体选择界面,也可能仍然希望音乐继续播放。即使界面已关闭,服务也可使音乐继续播放。</p>
+ </li>
+ <li>
+ <p><strong>广播接收器</strong>:<a href="https://developer.android.com/reference/android/content/BroadcastReceiver.html">BroadcastReceiver</a> 是在操作系统或其他应用发出称为 <a href="https://developer.android.com/reference/android/content/Intent.html">Intent</a> 的 IPC 机制时实例化的对象。例如,应用可以注册一个接收器来接收电量不足消息,并可以根据该信息改变自己的行为。</p>
+ </li>
+</ul>
+<h2 id="the-android-permission-model-accessing-protected-apis">Android 权限模式:访问受保护的 API</h2>
+<p>Android 上的所有应用均在应用沙盒(本文档的前面对其进行了介绍)内运行。默认情况下,Android 应用只能访问有限的系统资源。系统负责管理 Android 应用对资源的访问权限。如果资源使用不当或被恶意使用,可能会给用户体验、网络或设备上的数据带来不利影响。</p>
+<p>这些限制是通过多种不同的形式实现的。有些功能会因 Android 有意未提供针对敏感功能的 API(例如,Android 中没有用于直接操控 SIM 卡的 Android API)而受到限制。在某些情况下,角色分离能够提供一种安全措施,就像按应用隔离存储空间一样。在其他情况下,敏感 API 旨在供可信应用使用,并由一种称为“权限”的安全机制进行保护。</p>
+<p>这些受保护的 API 包括:</p>
+<ul>
+ <li>摄像头功能</li>
+ <li>位置数据 (GPS)</li>
+ <li>蓝牙功能</li>
+ <li>电话功能</li>
+ <li>短信/彩信功能</li>
+ <li>网络/数据连接</li>
+</ul>
+<p>这些资源只能通过操作系统进行访问。要使用设备上受保护的 API,应用必须在其清单中定义所需的功能。在准备安装应用时,系统会向用户显示一个对话框,其中会注明应用请求的权限并询问是否继续安装。如果用户选择继续安装,系统会认定用户已授予应用请求的所有权限。用户不能单独授予或拒绝个别权限,而是必须要一起授予或拒绝应用请求的所有权限。</p>
+<p>获得授权后,应用只要安装在设备上,便会一直拥有这些权限。为了避免用户混淆,系统不会再次通知用户向应用授予的权限,而核心操作系统中包含的应用或由原始设备制造商 (OEM) 绑定的应用不会向用户请求权限。应用卸载后,权限也会被移除,因此如果用户之后重新安装卸载的应用,系统会再次显示应用请求的权限。</p>
+<p>在设备设置中,用户可以查看之前安装的应用的权限。此外,用户还可以根据需要在全局范围内停用某些功能,例如停用 GPS、无线功能或 WLAN。</p>
+<p>如果应用尝试使用未在其清单中声明的受保护功能,权限失败通常会导致系统向应用抛回一个安全异常。受保护 API 权限检查会在最底层被强制执行,以防止出现规避行为。<em></em>图 2 中显示了如果应用在安装时请求获得受保护 API 的访问权限,会导致系统向用户显示的消息示例。</p>
+<p>如需关于系统默认权限的说明,请访问:<a href="https://developer.android.com/reference/android/Manifest.permission.html">https://developer.android.com/reference/android/Manifest.permission.html</a>。
+应用可以声明自己的权限以供其他应用使用。上述位置中未列出此类权限。</p>
+<p>在定义权限时,protectionLevel 属性用于告诉系统如何让用户知道哪些应用需要或可以获得相应权限。如需关于如何创建和使用应用特有权限的详细信息,请访问:<a href="https://develo
+per.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>。</p>
+<p>有些设备功能(例如,发送短信广播 Intent 的功能)不会供第三方应用使用,但可供原始设备制造商 (OEM) 预先安装的应用使用。这些应用使用 signatureOrSystem 权限。</p>
+<h2 id="how-users-understand-third-party-applications">用户如何了解第三方应用</h2>
+<p>当用户与第三方应用互动时,Android 会尽力让用户清楚这一情况,并让用户知道这些应用具备的功能。在安装任何应用之前,系统都会向用户显示一条明晰的消息,让用户知道要安装的应用请求获得的各项权限。安装完毕后,系统不会再次提示用户确认任何权限。</p>
+<p>在安装前一刻显示权限的原因有很多。这时用户正在主动查看应用、开发者和功能方面的信息,以确定其是否符合自己的需求和期望。同样非常重要的一点是,他们尚未对要安装的应用做出心理或财务方面的承诺,并且可以轻松地将要安装的应用与其他替代应用进行比较。</p>
+<p>有些其他平台会使用不同的方式通知用户,即在每个会话开始时或用户正在使用应用时请求权限。Android 的愿景是让用户能够随意在应用之间无缝切换。每次都让用户确认会拖慢用户的操作速度,而且会导致 Android 无法提供良好的用户体验。如果让用户在安装应用时查看权限,用户便可以在不愿意授予相应权限时选择不进行安装。</p>
+<p>此外,许多界面研究表明,过度提示用户会导致用户开始在看到任何对话框时都选择“确定”。Android 的安全目标之一是向用户有效地传达重要的安全信息,而使用让用户习惯性忽略的对话框则无法做到这一点。如果只向用户提供一次重要信息并且仅在重要时刻提供,用户更有可能慎重思考他们要同意的是什么。</p>
+<p>有些平台会选择完全不显示与应用功能有关的任何信息。这种方式会导致用户无法轻松了解和讨论应用功能。尽管无法使所有用户都是在充分了解相关信息的情况下做出决定,但 Android 权限模式可让众多用户轻松获取与应用相关的信息。例如,如果遇到意外的权限请求,经验更丰富的用户可能会询问有关应用功能的关键问题,并在 <a href="htts://play.google.com">Google Play</a> 等所有用户都可以看到的位置分享他们的疑问。</p>
+<table>
+ <tbody><tr>
+ <td><strong>应用安装时显示权限 - Google 地图</strong></td>
+ <td><strong>应用安装后显示权限 - Gmail</strong></td>
+ </tr>
+ <tr>
+ <td><img alt="应用安装时显示权限 - Google 地图" width="250" src="../images/image_install.png"/></td>
+ <td><img alt="应用安装后显示权限 - Gmail" width="250" src="../images/image_gmail_installed.png" id="figure1"/></td>
+ </tr>
+</tbody></table>
+<p class="img-caption">
+ <strong>图 1.</strong> 应用所需权限的显示方式</p>
+<h2 id="interprocess-communication">进程间通信</h2>
+<p>进程可以使用 UNIX 类型的任何传统机制进行通信。例如,文件系统、本地套接字或信号。不过,Linux 权限仍然适用。</p>
+<p>Android 还提供了一些新的 IPC 机制:</p>
+<ul>
+ <li>
+ <p><strong>Binder</strong>:一种基于功能的轻量型远程过程调用机制,在执行进程内调用和跨进程调用时能够实现出色的性能。Binder 是使用自定义 Linux 驱动程序实现的。请访问 <a href="https://developer
+.android.com/reference/android/os/Binder.html">https://developer.android.com/reference/android/os/Binder.html</a>。</p>
+ </li>
+ <li>
+ <p><strong>服务</strong>:服务(如上文所述)可提供能够使用 Binder 直接访问的接口。</p>
+ </li>
+ <li>
+ <p><strong>Intent</strong>:Intent 是简单的消息对象,表示想要执行某项操作的“意图”。例如,如果您的应用想要显示某个网页,则会创建一个 Intent 实例并将其传递给系统,以此来表示想要访问相应网址的“意图”。然后,系统会找到一些知道如何处理该 Intent 的其他代码(在本例中为浏览器),然后运行该代码。Intent 也可用于在系统范围内广播有趣的事件(例如通知)。请访问 <a href="https://developer.android.com/reference/android/content/Intent.html">https://developer.android.com/reference/android/content/Intent.html</a>。</p>
+ </li>
+ <li>
+ <p><strong>ContentProvider</strong>:ContentProvider 是一个数据存储库,用于访问设备上的数据;典型的示例就是用于访问用户通讯录的 ContentProvider。应用可以访问其他应用通过 ContentProvider 提供的数据,还可以定义自己的 ContentProviders 来提供自己的数据。请访问 <a href="https://developer.android.com/reference/android/content/ContentProvider.html">https://developer.android.com/reference/android/content/ContentProvider.html</a>。</p>
+ </li>
+</ul>
+<p>虽然可以使用其他机制(例如,网络套接字或全局可写文件)来实现 IPC,但上面这些都是建议使用的 Android IPC 框架。建议 Android 开发者遵循保护用户数据及避免引入安全漏洞方面的最佳做法。</p>
+<h2 id="cost-sensitive-apis">费用敏感 API</h2>
+<p>费用敏感 API 指可能会给用户或网络带来费用的任何功能。Android 平台已将费用敏感 API 放入由操作系统控制的受保护 API 列表中。如果有第三方应用请求使用费用敏感 API,必须要由用户授予明确的权限,它们才能使用这些 API。这些 API 包括:</p>
+<ul>
+ <li>电话</li>
+ <li>短信/彩信</li>
+ <li>网络/数据</li>
+ <li>应用内结算</li>
+ <li>NFC 访问</li>
+</ul>
+<p>Android 4.2 进一步增强了对使用短信的控制。如果有应用尝试向使用付费服务的短代码发送短信(可能会产生额外的费用),Android 将会通知用户。用户可以选择是允许还是阻止该应用发送短信。</p>
+<h2 id="sim-card-access">SIM 卡访问</h2>
+<p>第三方应用无法对 SIM 卡进行底层访问。操作系统负责处理与 SIM 卡之间的所有通信,包括访问 SIM 卡内存中的个人信息(通讯录)。应用也无法访问 AT 命令,因为这些命令完全由无线接口层 (RIL) 进行管理。RIL 不会为这些命令提供任何高层 API。</p>
+<h2 id="personal-information">个人信息</h2>
+<p>Android 已将能够用于访问用户数据的 API 放入受保护 API 组中。在正常使用期间,Android 设备还会收集用户安装的第三方应用内的用户数据。选择分享这些信息的应用可以使用 Android 操作系统权限检查功能保护来自第三方应用的数据。</p>
+<img alt="只能通过受保护的 API 访问敏感用户数据" src="../images/permissions_check.png" id="figure2"/>
+<p class="img-caption">
+ <strong>图 2.</strong> 只能通过受保护的 API 访问敏感的用户数据</p>
+<p>可能包含个人信息或个人身份信息(例如,通讯录和日历)的系统内容提供程序在创建时便已拥有明确确定的权限。这种精细的设计可让用户清楚地知道哪些类型的信息可能会提供给相应应用。在安装过程中,第三方应用可能会请求获得访问这些资源的权限。获得授权后,应用便可以进行安装,并且只要安装在设备上,便会一直有权访问请求的数据。</p>
+<p>默认情况下,收集个人信息的所有应用都会仅限特定应用访问这些数据。如果某个应用选择通过 IPC 将数据提供给其他应用,那么这个授予访问权限的应用便可以限制由操作系统强制执行的 IPC 机制的权限。</p>
+<h2 id="sensitive-data-input-devices">敏感数据输入设备</h2>
+<p>Android 设备经常会提供可让应用与周围环境进行互动的敏感数据输入设备(例如,摄像头、麦克风或 GPS)。对于要使用这些设备的第三方应用,必须先由用户通过使用 Android 操作系统权限向其明确提供使用权限。安装应用时,安装程序会以提供名称的方式请求用户授予使用相应传感器的权限。</p>
+<p>如果某个应用想要知道用户所在的位置,则需要获得获取用户位置信息的权限。安装应用时,安装程序会询问用户是否允许相应应用获取用户的位置信息。如果用户不希望任何应用获取其位置信息,可以随时运行“设置”应用,转到“位置和安全”,然后取消选中“使用无线网络”和“启用 GPS 卫星”。这将针对用户设备上的所有应用停用需要使用位置信息的服务。</p>
+<h2 id="device-metadata">设备元数据</h2>
+<p>Android 还会尽力限制访问本身并不属于敏感数据,但可能会间接透露用户特征、用户偏好以及用户使用设备的方式的数据。</p>
+<p>默认情况下,应用无权访问操作系统日志、浏览器历史记录、电话号码以及硬件/网络标识信息。如果应用在安装时请求获得访问此类信息的权限,安装程序会询问用户是否允许相应应用访问此类信息。如果用户没有授予该权限,系统将不会安装相应应用。</p>
+<h2 id="certificate-authorities">证书授权中心</h2>
+<p>Android 中收录了一组已安装的系统证书授权中心,这些授权中心在整个系统范围内均可信。在 Android 7.0 之前的版本中,设备制造商可以修改其设备上搭载的 CA 组。不过,运行 7.0 及更高版本的设备将具有一组统一的系统 CA,并且不再允许设备制造商对其进行修改。
+</p>
+<p>要作为新的公共 CA 添加到 Android 收录的 CA 组中,相应 CA 必须要完成 <a href="https://wiki.mozilla.org/CA:How_to_apply">Mozilla CA 收录流程</a>,然后提交一项针对 Android 的功能请求 (<a href="https://code.google.com/p/android/issues/entry">https://code.google.com/p/android/issues/entry</a>),以便请求添加到 <a href="https://android.googlesource.com/">Android 开放源代码项目</a> (AOSP) 收录的 Android CA 组中。
+</p>
+<p>此外还有一些设备专用 CA,这些 CA 不应被收录到 AOSP CA 核心组中,例如,安全访问运营商基础架构组件(例如,短信/彩信网关)时可能需要的运营商私有 CA。建议设备制造商将私有 CA 仅收录在需要信任这些 CA 的组件/应用中。如需更多详细信息,请参阅<a href="https://developer.android.com/preview/features/security-config.html">网络安全配置</a>。
+</p>
+<h2 id="application-signing">应用签名</h2>
+<p>通过<a href="/security/apksigning/index.html">代码签名</a>,开发者可以标识应用创作者并更新其应用,而无需创建复杂的接口和权限。在 Android 平台上运行的每个应用都必须要有开发者的签名。Google Play 或 Android 设备上的软件包安装程序会拒绝没有获得签名就尝试安装的应用。</p>
+<p>在 Google Play 上,应用签名可以将 Google 对开发者的信任和开发者对自己的应用的信任联系在一起。开发者知道自己的应用是以未经修改的形式提供给 Android 设备的,并且开发者可以对自己的应用的行为负责。</p>
+<p>在 Android 上,应用签名是将应用放入其应用沙盒的第一步。已签名的应用证书定义了哪个用户 ID 与哪个应用相关联;不同的应用要以不同的用户 ID 运行。应用签名可确保一个应用无法访问任何其他应用,通过明确定义的 IPC 进行访问时除外。</p>
+<p>当应用(APK 文件)安装到 Android 设备上时,软件包管理器会验证 APK 是否已经过适当签名(已使用 APK 中包含的证书签名)。如果该证书(或更准确地说,证书中的公钥)与为设备上的任何其他 APK 签名时使用的密钥一致,那么这个新 APK 可以选择在清单中指定它将与其他以类似方式签名的 APK 共用一个 UID。</p>
+<p>应用可以由第三方(原始设备制造商(OEM)、运营商、其他相关方)签名,也可以自行签名。Android 提供了使用自签名证书进行代码签名的功能,而开发者无需外部协助或许可即可生成自签名证书。应用并非必须由核心机构签名。Android 目前不对应用证书进行 CA 认证。</p>
+<p>应用还可以在“签名”保护级别声明安全权限,以便仅限使用同一个密钥签名的应用访问它们,同时维持单独的 UID 和应用沙盒。通过<a href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">共用 UID 功能</a>,可以与共用的应用沙盒建立更紧密的联系,这是因为借助该功能,使用同一个开发者密钥签名的两个或更多应用可以在其清单中声明共用的 UID。</p>
+<h2 id="app-verification">应用验证</h2>
+<p>Android 4.2 及更高版本均支持应用验证。用户可以选择启用“验证应用”,并在安装应用之前由应用验证程序对其进行评估。如果用户尝试安装的应用可能有害,应用验证功能可以提醒用户;如果应用的危害性非常大,应用验证功能可以阻止安装。</p>
+<h2 id="digital-rights-management">数字版权管理</h2>
+<p>Android 平台提供了一个可扩展的 DRM 框架,以便应用根据与受版权保护的内容相关的许可限制条件来管理这些内容。DRM 框架支持多种 DRM 方案;设备具体支持哪些 DRM 方案由设备制造商决定。</p>
+<p><a href="https://developer.android.com/reference/android/drm/package-summary.html">Android DRM 框架</a>是在以下两个架构层中实现的(请参见下图):</p>
+<ul>
+ <li>
+ <p>DRM 框架 API:通过 Android 应用框架提供给应用,并通过适用于标准应用的 Dalvik VM 运行。</p>
+ </li>
+ <li>
+ <p>本机代码 DRM 管理器:用于实现 DRM 框架,并为 DRM 插件(代理)提供接口,以便处理各种 DRM 方案的版权管理和解密操作。</p>
+ </li>
+</ul>
+<p><img alt="Android 平台上的数字版权管理架构" src="/devices/images/ape_fwk_drm_2.png" id="figure3"/></p>
+<p class="img-caption">
+ <strong>图 3.</strong> Android 平台上的数字版权管理架构</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/overview/implement.html b/zh-cn/security/overview/implement.html
new file mode 100644
index 00000000..affefe3d
--- /dev/null
+++ b/zh-cn/security/overview/implement.html
@@ -0,0 +1,218 @@
+<html devsite><head>
+ <title>实现安全保护措施</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 安全团队经常会收到用户发来的请求,希望我们提供关于如何防止 Android 设备上出现潜在安全问题的信息。我们偶尔也会对设备进行抽查,并让设备制造商和受影响的合作伙伴知晓潜在问题。</p>
+
+<p>在本页中,我们提供了根据自己的经验总结的安全方面的最佳做法(扩展了我们为开发者提供的<a href="http://developer.android.com/guide/practices/security.html">安全设计</a>文档),以及关于如何在设备上编译或安装系统级软件的详细信息。</p>
+
+<p>为了方便相关人员采用这些最佳做法,Android 安全团队会尽可能将相关测试整合到 <a href="/compatibility/cts">Android 兼容性测试套件</a> (CTS) 和 <a href="http://tools.android.com/tips/lint">Android Lint</a> 中。我们竭诚欢迎设备实现人员贡献可以帮助其他 Android 用户的相关测试(要查看与安全相关的测试,请访问 <code>root/cts/tests/tests/security/src/android/security/cts</code>)。</p>
+
+<h2 id="dev-process">开发流程</h2>
+<p>请在开发流程和环境中遵循以下最佳做法。</p>
+
+<h3 id="sec-review">审核源代码</h3>
+<p>进行源代码审核可以发现大量安全问题,包括本文档中指出的问题。Android 强烈建议采用手动和自动两种方式审核源代码。最佳做法:</p>
+
+<ul>
+<li>对所有使用 Android SDK 的应用代码运行 <a href="http://tools.android.com/tips/lint">Android Lint</a>,并更正发现的所有问题。</li>
+<li>应使用可以发现内存管理问题(例如,缓冲区溢出和差一错误)的自动工具分析本机代码。</li>
+<li>Android 编译系统支持很多 LLVM 清理程序,例如可用于进行自动源代码审核的 AddressSanitizer 和 UndefinedBehaviorSanitizer。</li>
+</ul>
+
+<h3 id="auto-test">使用自动测试功能</h3>
+<p>自动测试功能可以发现大量安全问题,包括下文中讨论的一些问题。最佳做法:</p>
+
+<ul>
+<li>定期更新 CTS 并运行安全性测试;运行最新版本的 CTS 来验证兼容性。</li>
+<li>在整个开发流程中定期运行 CTS,以便提早发现问题并缩短解决问题所需的时间。在自动编译流程(每天会编译多次)的连续集成期间,Android 会使用 CTS。
+</li>
+<li>设备制造商应使接口的安全性测试实现自动化,包括使用格式有误的输入内容进行测试(模糊测试)。</li>
+</ul>
+
+<h3 id="sign-sysimg">为系统映像签名</h3>
+<p>系统映像的签名对于判断设备的完整性至关重要。最佳做法:</p>
+
+<ul>
+<li>不得使用众所周知的密钥为设备签名。</li>
+<li>应按照与处理敏感密钥方面的业界标准做法一致的方式管理用于为设备签名的密钥,包括使用能够提供有限、可审核访问权限的硬件安全模块 (HSM)。</li>
+</ul>
+
+<h3 id="sign-apk">为应用 (APK) 签名</h3>
+<p>应用签名在保障设备安全方面发挥着重要作用,可用于进行权限检查以及软件更新。在选择为应用签名使用的密钥时,务必要考虑应用是仅在一台设备上使用,还是供多台设备共用。最佳做法:</p>
+
+<ul>
+<li>不得使用众所周知的密钥为应用签名。</li>
+<li>应按照与处理敏感密钥方面的业界标准做法一致的方式管理用于为应用签名的密钥,包括使用能够提供有限、可审核访问权限的 HSM。</li>
+<li>不应使用平台密钥为应用签名。</li>
+<li>不应使用不同的密钥为软件包名称相同的应用签名。在针对不同的设备开发应用时,经常会出现这种情况,尤其是在使用平台密钥时。如果应用独立于设备,则在多台设备之间使用相同的密钥。如果应用是特定设备专用的,则按设备和密钥创建独一无二的软件包名称。</li>
+</ul>
+
+<h3 id="apps-pub">发布应用</h3>
+<p>在 Google Play 中,设备制造商能够直接更新应用,而无需进行完整的系统更新。这不仅有助于加快应对安全问题和推出新功能的速度,还有助于确保您的应用具有独一无二的软件包名称。最佳做法:</p>
+
+<ul>
+<li>将您的应用上传到 Google Play,以便能够进行自动更新,而无需进行完整的无线下载 (OTA) 更新。已上传但并未发布的应用无法供用户直接下载,但仍可进行更新。之前安装过相应应用的用户可以重新安装它和/或在其他设备上安装它。</li>
+<li>创建与您的公司明确相关的应用包名称,例如在名称中使用公司商标。</li>
+<li>设备制造商发布的应用应上传到 Google Play 商店,以免第三方用户冒用软件包名称。如果某个设备制造商在设备上安装了某个应用,但没有在 Play 商店中发布该应用,其他开发者便可以上传同样的应用,使用同样的软件包名称,并更改该应用的元数据。当用户获得该应用后,这些不相关的元数据可能会带来困扰。</li>
+</ul>
+
+<h3 id="incident-response">应对安全事件</h3>
+<p>外部各方必须能够就设备特有的安全问题与设备制造商联系。我们建议创建一个公开的电子邮件地址来管理安全事件。最佳做法:</p>
+
+<ul>
+<li>创建 security@your-company.com 或类似地址,并将其公开。<em></em></li>
+<li>如果您发现了影响 Android 操作系统或多个设备制造商提供的 Android 设备的安全问题,则应填写<a href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">安全错误报告</a>与 Android 安全团队联系。</li>
+</ul>
+
+<h2 id="prod-implement">产品实现</h2>
+<p>在实现产品时,请遵循以下最佳做法。</p>
+
+<h3 id="root-processes">隔离 Root 进程</h3>
+<p>Root 进程是最常受到提权攻击的目标,因此减少 Root 进程数量有助于降低提权风险。CTS 中包含一个能够列出 Root 进程的信息测试。最佳做法:</p>
+
+<ul>
+<li>应尽可能减少设备上作为 Root 代码运行的必要代码的数量。尽可能使用常规 Android 进程而非 Root 进程。ICS Galaxy Nexus 只有 6 个 Root 进程:vold、inetd、zygote、tf_daemon、ueventd 和 init。如果某个进程必须要在设备上作为 Root 进程运行,请将该进程记录在 AOSP 功能请求中,以便对其进行公开审核。</li>
+<li>应尽可能将 Root 代码与不可信数据隔离开来,并尽可能通过 IPC 访问 Root 代码。例如,将 Root 功能缩减成可通过 Binder 访问的小型服务,并将这个具有签名权限的服务提供给网络流量处理权限很小或没有此类权限的应用。</li>
+<li>Root 进程不得通过网络套接字进行监听。</li>
+<li>Root 进程不得为应用提供通用运行时(例如 Java VM)。</li>
+</ul>
+
+<h3 id="sys-apps">隔离系统应用</h3>
+<p>一般而言,预先安装的应用不应使用共用系统 UID 运行。不过,如果某个应用必须使用共用系统 UID 或其他特权服务(例如,电话服务),那么该应用不应导出由用户安装的第三方应用可访问的任何服务、广播接收器或内容提供程序。最佳做法:</p>
+
+<ul>
+<li>应尽可能减少设备上作为系统代码运行的必要代码的数量。尽可能通过 Android 进程自身的 UID 使用此类进程,而非重复使用系统 UID。</li>
+<li>应尽可能将系统代码与不可信数据隔离开来,并且系统代码应尽可能仅向其他可信进程提供 IPC。</li>
+<li>系统进程不得通过网络套接字进行监听。</li>
+</ul>
+
+<h3 id="process-isolate">隔离进程</h3>
+<p>Android 应用沙盒要求应用与系统中的其他进程(包括 Root 进程和调试程序)隔离开来。除非应用或用户特意启用了调试功能,否则任何应用都不应违反这一要求。最佳做法:</p>
+
+<ul>
+<li>Root 进程不得访问各个应用数据文件夹内的数据,使用已记录的 Android 调试方法时除外。</li>
+<li>Root 进程不得访问应用内存,使用已记录的 Android 调试方法时除外。</li>
+<li>设备上不得有任何会访问其他应用/进程的数据或内存的应用。</li>
+</ul>
+
+<h3 id="suid-files">保护 SUID 文件</h3>
+<p>新的 SetUID 程序应该不能被不可信程序访问。SetUID 程序过去经常是可被用来获取 Root 权限的漏洞位置,因此务必要最大限度地降低 SetUID 程序对不可信应用的可用性。最佳做法:</p>
+
+<ul>
+<li>SUID 进程不得提供可被用来规避 Android 安全模型的 shell 或后门程序。</li>
+<li>必须确保任何用户都无法对 SUID 程序执行写入操作。</li>
+<li>SUID 程序不应为全局可读或全局可执行程序。创建一个组,限定只有该组的成员能够访问相应的 SUID 二进制文件,并将应该能够执行相应 SUID 程序的所有应用放入该组中。
+</li>
+<li>SUID 程序经常会被用户用作获取设备 Root 权限的来源。为了降低这种风险,应确保 shell 用户无法执行 SUID 程序。</li>
+</ul>
+
+<p>CTS 验证程序包括一个可列出 SUID 文件的信息测试;根据 CTS 测试,有些 SetUID 文件是不允许使用的。</p>
+
+<h3 id="listening-sockets">保护监听套接字</h3>
+<p>当设备通过任何端口或任何接口进行监听时,CTS 测试都会失败。如果测试失败,Android 会验证是否遵循了以下最佳做法:</p>
+
+<ul>
+<li>设备上不应存在监听端口。</li>
+<li>必须能够在不使用 OTA 的情况下停用监听端口。停用这些端口的方法可以是更改服务器或用户设备配置。</li>
+<li>Root 进程不得通过任何端口进行监听。</li>
+<li>归系统 UID 所有的进程不得通过任何端口进行监听。</li>
+<li>对于使用套接字的本地 IPC,应用必须使用只有某个组可以访问的 UNIX 域套接字。为 IPC 创建文件描述符,并允许特定 UNIX 组对其执行 +RW 操作。所有客户端应用都必须在该 UNIX 组内。</li>
+<li>有些拥有多个处理器的设备(例如,无线装置/调制解调器从应用处理器中分离出来)会借助网络套接字在处理器之间进行通信。在这种情况下,处理器间通信所用的网络套接字必须使用单独的网络接口,以防止设备上未经授权的应用访问(例如,使用 iptables 防止设备上的其他应用访问)。</li>
+<li>负责处理监听端口的守护进程必须能够防范格式有误的数据。Google 可能会使用未经授权的客户端针对端口进行模糊测试,也可能会在可能的情况下使用已获授权的客户端针对端口进行模糊测试。所有崩溃事件都将记录为具有适当严重程度的错误。</li>
+</ul>
+
+<h3 id="logging">记录数据</h3>
+<p>记录数据的做法会增加数据遭泄露的风险并降低系统性能。之前曾发生过多起因 Android 设备上默认安装的应用记录敏感用户数据而导致的公共安全事件。最佳做法:</p>
+
+<ul>
+<li>应用或系统服务不应记录第三方应用提供的可能包含敏感信息的数据。</li>
+<li>应用不得在正常操作过程中记录任何个人身份信息 (PII)。</li>
+</ul>
+
+<p>CTS 中包含一些能够检查系统日志中是否存在可能敏感的信息的测试。</p>
+
+<h3 id="directories">限制对目录的访问</h3>
+<p>全局可写目录可能会引入安全漏洞,并且可能会使应用能够重命名可信文件、替换文件或进行基于符号链接的攻击(攻击者可能会利用指向某个文件的符号链接诱使可信程序执行不应执行的操作)。可写目录还可能会导致卸载应用后无法适当清除与相应应用关联的所有文件。</p>
+
+<p>作为最佳做法,系统用户或 Root 用户创建的目录不应为全局可写目录。CTS 测试能够测试已知目录,从而有助于强制执行这种最佳做法。</p>
+
+<h3 id="config-files">保护配置文件</h3>
+<p>许多驱动程序和服务都依赖于存储在 <code>/system/etc</code>、<code>/data</code> 等目录中的配置文件和数据文件。如果这些文件由某个特权进程处理且为全局可写文件,应用可能能够通过在全局可写文件中创建恶意内容来利用该特权进程中的漏洞。最佳做法:</p>
+
+<ul>
+<li>特权进程使用的配置文件不应为全局可读文件。</li>
+<li>特权进程使用的配置文件不得为全局可写文件。</li>
+</ul>
+
+<h3 id="native-code">存储本机代码库</h3>
+<p>特权设备制造商进程使用的所有代码都必须位于 <code>/vendor</code> 或 <code>/system</code> 中;这些文件系统会在设备启动时以只读模式装载。作为最佳做法,系统使用的库或手机上安装的其他权限非常高的应用使用的库也应位于这些文件系统中。这有助于防止出现可让攻击者用来控制特权进程执行的代码的安全漏洞。</p>
+
+<h3 id="device-drivers">限制对设备驱动程序的访问</h3>
+<p>应该只有可信代码能够直接访问驱动程序。首选架构要尽可能提供一个单一用途守护进程来代理向驱动程序发出的调用,并仅限该守护进程访问驱动程序。作为最佳做法,驱动程序设备节点不应为全局可读或全局可写节点。CTS 测试能够检查是否存在全局可读或全局可写驱动程序的已知实例,从而有助于强制执行这种最佳做法。
+</p>
+
+<h3 id="adb">停用 ADB</h3>
+<p>Android 调试桥 (ADB) 是一款非常实用的开发和调试工具,但它只适合在受控的安全环境中使用,不应针对一般使用情况启用该工具。最佳做法:</p>
+
+<ul>
+<li>ADB 必须默认处于停用状态。</li>
+<li>ADB 必须要求用户先将其开启,然后再接受连接。</li>
+</ul>
+
+<h3 id="unlockable-bootloaders">解锁引导加载程序</h3>
+<p>许多 Android 设备都支持解锁引导加载程序。解锁引导加载程序后,设备所有者将能够修改系统分区和/或安装自定义操作系统。常见用例包括在设备上安装第三方 ROM 以及进行系统级开发。例如,Google Nexus 设备所有者可以运行 <code>fastboot oem unlock</code> 来启动解锁过程,该进程会向用户显示以下消息:</p>
+
+<div style="background-color: #B2EBF2; padding: 10px;margin-right:25px">
+
+<p><strong>Unlock bootloader?</strong></p>
+
+<p>If you unlock the bootloader, you will be able to install custom operating system software on this phone.</p>
+
+<p>A custom OS is not subject to the same testing as the original OS, and can cause your phone and installed applications to stop working properly.</p>
+
+<p>To prevent unauthorized access to your personal data, unlocking the bootloader will also delete all personal data from your phone (a "factory data reset").</p>
+
+<p>Press the Volume Up/Down buttons to select Yes or No. Then press the Power button to continue.</p>
+
+<p><strong>Yes</strong>: Unlock bootloader (may void warranty)</p>
+
+<p><strong>No</strong>: Do not unlock bootloader and restart phone.</p>
+</div>
+
+<br />
+<p>作为最佳做法,在解锁之前,可解锁的 Android 设备必须先安全地清除所有用户数据。如果未能适当删除所有数据便进行解锁,能够接触到这些设备的攻击者便可以在未经授权的情况下获取机密的 Android 用户数据。为了防止用户数据泄露,支持解锁的设备必须正确实现解锁(我们已见到过设备制造商以不当方式实现解锁的无数实例)。正确实现的解锁过程具有以下特性:</p>
+
+<ul>
+<li>在用户确认解锁命令后,设备必须立即开始清除数据。在安全删完数据之前,不得设置 <code>unlocked</code> 标记。</li>
+<li>如果无法安全删完数据,设备必须保持锁定状态。</li>
+<li>如果底层块设备支持 <code>ioctl(BLKSECDISCARD)</code> 或等同命令,则应使用此类命令。对于 eMMC 设备,这意味着使用 Secure Erase 或 Secure Trim 命令。对于 eMMC 4.5 及更高版本,这意味着先使用常规的 Erase 或 Trim 命令,然后再执行 Sanitize 操作。</li>
+<li>如果底层块设备不支持 <code>BLKSECDISCARD</code>,则必须改用 <code>ioctl(BLKDISCARD)</code>。在 eMMC 设备上,这是一个常规的 Trim 操作。</li>
+<li>如果 <code>BLKDISCARD</code> 不受支持,可以将块设备中的数据重写为全零。</li>
+<li>最终用户必须能够要求在刷写分区之前先清除用户数据。例如,在 Nexus 设备上,这可以通过 <code>fastboot oem lock</code> 命令来实现。</li>
+<li>无论设备处于解锁和/或重新锁定状态,都可以通过 eFuses 或类似机制进行记录。</li>
+</ul>
+
+<p>这些要求旨在确保在完成解锁操作时所有数据都已被销毁。未能实现这些保护措施会被视为存在中级安全漏洞。</p>
+
+<p>将设备解锁后,可以使用 <code>fastboot oem lock</code> 命令重新将其锁定。使用新的自定义操作系统时,锁定引导加载程序能够为用户数据提供的保护与原始设备制造商操作系统提供的保护相同(例如,如果设备被再次解锁,用户数据将会被清除)。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/overview/kernel-security.html b/zh-cn/security/overview/kernel-security.html
new file mode 100644
index 00000000..7ad6ddf9
--- /dev/null
+++ b/zh-cn/security/overview/kernel-security.html
@@ -0,0 +1,86 @@
+<html devsite><head>
+ <title>系统和内核安全</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>在操作系统级别,Android 平台不仅提供 Linux 内核的安全功能,而且还提供安全的进程间通信 (IPC) 机制,以便在不同进程中运行的应用之间安全通信。操作系统级别的这些安全功能旨在确保即使是本机代码也要受应用沙盒的限制。无论相应代码是自带应用行为导致的结果,还是利用应用漏洞导致的结果,系统都能防止恶意应用危害其他应用、Android 系统或设备本身。要了解您可以采取哪些措施来增强设备上的内核,请参阅<a href="/devices/tech/config/kernel.html">内核配置</a>。要了解必需的设置,请参阅 <a href="/compatibility/cdd.html">Android 兼容性定义文档 (CDD)</a>。</p>
+<h2 id="linux-security">Linux 安全</h2>
+<p>Android 平台的基础是 Linux 内核。Linux 内核多年来一直应用得非常广泛,并且用在了数百万种安全敏感型环境中。在历经数以千计的开发者不断研究、攻击和修复之后,Linux 已成为许多公司和安全专业人士信任的一款既稳定又安全的内核。</p>
+<p>作为移动计算环境的基础,Linux 内核为 Android 提供了一些关键的安全功能,其中包括:</p>
+<ul>
+ <li>基于用户的权限模式</li>
+ <li>进程隔离</li>
+ <li>用于实现安全 IPC 的可扩展机制</li>
+ <li>能够移除内核中不必要的和可能不安全的部分</li>
+</ul>
+<p>作为多用户操作系统,Linux 内核的一个基本安全目标是将用户资源彼此隔离开来。Linux 的安全理念是防范用户资源之间相互侵扰。因此,Linux 可以:</p>
+<ul>
+ <li>防止用户 A 读取用户 B 的文件</li>
+ <li>确保用户 A 不会占用用户 B 的内存</li>
+ <li>确保用户 A 不会占用用户 B 的 CPU 资源</li>
+ <li>确保用户 A 不会占用用户 B 的设备(例如,电话、GPS、蓝牙)</li>
+</ul>
+<h2 id="the-application-sandbox">应用沙盒</h2>
+<p>Android 平台利用基于用户的 Linux 保护机制来识别和隔离应用资源。Android 系统会为每个 Android 应用分配一个独一无二的用户 ID (UID),并使它们以这个用户身份在单独的进程中运行。这种方法与其他操作系统(包括传统的 Linux 配置)采用的方法不同。在其他操作系统中,多个应用会以相同的用户权限运行。</p>
+<p>这样就设置了一个内核级应用沙盒。内核会在进程级别通过标准的 Linux 内容(例如,分配给应用的用户 ID 和组 ID)强制执行应用和系统之间的安全功能。默认情况下,应用不能彼此交互,而且应用对操作系统的访问权限会受到限制。如果应用 A(一个单独的应用)尝试执行恶意操作,例如在没有权限的情况下读取应用 B 的数据或拨打电话,操作系统会阻止此类操作,因为应用 A 没有适当的用户权限。沙盒非常简单,可审核,并且基于已有数十年历史的 UNIX 风格的进程用户隔离和文件权限机制。</p>
+<p>由于应用沙盒位于内核中,因此该安全模型的保护范围扩展到了本机代码和操作系统应用。位于内核上方的所有软件(例如,操作系统库、应用框架、应用运行时和所有应用)都会在应用沙盒中运行。在某些平台上,为了强制执行安全功能,会限制开发者只能使用特定的开发框架、API 组或语言。在 Android 上,并没有限制必须如何编写应用才能强制执行安全功能;在这一方面,本机代码与直译码一样安全。</p>
+<p>在某些操作系统中,一个应用中的内存损坏错误可能会导致位于同一内存空间中的其他应用出现损坏,进而导致设备的安全性完全遭到破坏。由于所有应用及其资源都在操作系统级别的沙盒内,因此,如果出现内存损坏错误,将只有在相应应用的环境中才能发生任意执行代码的行为,而且只能是以操作系统确立的权限执行代码。</p>
+<p>与所有安全功能一样,应用沙盒并不是坚不可摧的。不过,要在经过适当配置的设备上攻破应用沙盒这道防线,必须要先攻破 Linux 内核的安全功能。</p>
+<h2 id="system-partition-and-safe-mode">系统分区和安全模式</h2>
+<p>系统分区包含 Android 的内核,以及操作系统库、应用运行时、应用框架和应用。该分区设为了只读分区。当用户将设备启动到安全模式时,第三方应用可由设备所有者手动启动,但不会默认启动。</p>
+<h2 id="filesystem-permissions">文件系统权限</h2>
+<p>在 UNIX 风格的环境中,文件系统权限可确保一个用户不能更改或读取另一个用户的文件。在 Android 中,每个应用都以自己的用户身份运行。除非开发者明确地与其他应用共享文件,否则一个应用不能读取或更改另一个应用创建的文件。</p>
+<h2 id="se-linux">安全增强型 Linux</h2>
+<p>Android 使用安全增强型 Linux (SELinux) 来应用访问控制策略并对进程建立强制访问控制 (mac)。如需详细信息,请参阅 <a href="/security/selinux/index.html">Android 中的安全增强型 Linux</a>。</p>
+<h2 id="verified-boot">验证启动</h2>
+<p>Android 6.0 及更高版本支持验证启动功能和 device-mapper-verity。验证启动功能旨在保证设备软件(从硬件信任根直到系统分区)的完整性。在启动过程中,无论是在每个阶段,都会在进入下一个阶段之前先验证下一个阶段的完整性和真实性。
+</p>
+<p>Android 7.0 及更高版本支持严格强制执行的验证启动,这意味着遭到入侵的设备将无法启动。
+</p>
+<p>如需更多详细信息,请参阅<a href="/security/verifiedboot/index.html">验证启动</a>。
+</p>
+
+<h2 id="crypto">加密</h2>
+<p>Android 提供了一套加密 API 供应用使用,其中包括标准和常用加密基元(例如,AES、RSA、DSA 和 SHA)的实现 API。此外,Android 还提供了适用于更高级别协议(例如,SSL 和 HTTPS)的 API。</p>
+<p>Android 4.0 中引入了 <a href="http://developer.android.com/reference/android/security/KeyChain.html">KeyChain</a> 类,以便应用使用系统凭据存储空间来存储私钥和证书链。</p>
+<h2 id="rooting-devices">获取设备的 Root 权限</h2>
+<p>默认情况下,在 Android 上,只有内核和一小部分核心应用能够以 Root 权限运行。Android 不会阻止具有 Root 权限的用户或应用修改操作系统、内核或任何其他应用。一般来说,Root 对所有应用和所有应用数据拥有完整访问权限。如果用户在 Android 设备上更改权限来向应用授予 Root 访问权限,则会使遭受恶意应用攻击以及遭受潜在应用缺陷侵扰的安全风险增加。</p>
+<p>能够修改自己的 Android 设备对于使用 Android 平台的开发者来说非常重要。在许多 Android 设备上,用户都可以解锁引导加载程序,以便安装替代操作系统。这些替代操作系统可能会允许所有者获得 Root 访问权限,以便他们调试应用和系统组件,或者访问 Android API 未提供给应用的功能。</p>
+<p>在有些设备上,能够亲手控制设备并拥有 USB 数据线的用户可以安装能够向其提供 Root 权限的新操作系统。为了保护所有现有用户数据免遭入侵,引导加载程序解锁机制要求引导加载程序在解锁期间清空所有现有用户数据。利用内核错误或安全漏洞获得 Root 访问权限后,可以绕过这种保护机制。</p>
+<p>使用存储在设备上的密钥对数据进行加密的做法并不能防止 Root 用户访问应用数据。应用可以使用存储在设备之外的密钥(例如,存储在服务器上的密钥,或用户密码)进行加密,从而添加一道数据保护屏障。如果不提供密钥的话,这种方法可以提供临时保护,但在某些时候,必须要先将密钥提供给应用,然后 Root 用户才能访问相应应用。</p>
+<p>一种更强大的防止 Root 用户获取数据的方式是使用硬件解决方案。原始设备制造商 (OEM) 可以选择实现仅允许访问特定类型的内容的硬件解决方案,例如,适用于视频播放的 DRM 或适用于 Google 电子钱包的 NFC 相关可信存储空间。</p>
+<p>如果设备丢失或被盗,Android 设备上的全文件系统加密功能可以使用设备密码来保护加密密钥,这样一来,修改启动加载程序或操作系统的做法将不足以在没有用户设备密码的情况下访问用户数据。</p>
+<h2 id="user-security">用户安全功能</h2>
+<h3 id="filesystem-encryption">文件系统加密</h3>
+<p>Android 3.0 及更高版本提供全文件系统加密功能,因此所有用户数据都可以在内核中进行加密。</p>
+<p>Android 5.0 及更高版本支持<a href="/security/encryption/full-disk.html">全盘加密</a>。全盘加密功能旨在使用单个密钥(由用户的设备密码加以保护)来保护设备的整个用户数据分区。在启动时,用户必须先提供其凭据,然后才能访问磁盘的任何部分。
+</p>
+<p>Android 7.0 及更高版本支持<a href="/security/encryption/file-based.html">文件级加密</a>。采用文件级加密时,可以使用不同的密钥对不同的文件进行加密,并且可以对这些文件进行单独解密。
+</p>
+
+<p>如需关于实现文件系统加密的更多详细信息,请参阅<a href="/security/encryption/index.html">加密</a>部分。</p>
+<h3 id="password-protection">密码保护</h3>
+<p>Android 可以配置为在提供对设备的访问权限之前先验证用户提供的密码。除了防止未经授权使用设备外,该密码还可以保护用于进行全文件系统加密的加密密钥。</p>
+<p>设备管理员可以要求使用密码和/或密码复杂度规则。</p>
+<h2 id="device-administration">设备管理</h2>
+<p>Android 2.2 及更高版本提供 Android Device Administration API,该 API 在系统级别提供设备管理功能。例如,内置的 Android 电子邮件应用可以使用该 API 来改善 Exchange 支持。通过电子邮件应用,Exchange 管理员可以跨设备强制执行密码政策(其中密码包括字母数字密码或数字 PIN 码)。管理员还可以远程清除(即恢复出厂默认设置)丢失或被盗手机上的数据。</p>
+<p>除了在 Android 系统自带的应用中使用外,该 API 还可供提供设备管理解决方案的第三方使用。如需关于该 API 的详细信息,请参阅<a href="https://developer.android.com/guide/topics/admin/device-admin.html">设备管理</a>。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/overview/updates-resources.html b/zh-cn/security/overview/updates-resources.html
new file mode 100644
index 00000000..818cba81
--- /dev/null
+++ b/zh-cn/security/overview/updates-resources.html
@@ -0,0 +1,183 @@
+<html devsite><head>
+ <title>安全更新和资源</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="android_security_bug_lifecycle">Android 安全错误生命周期</h2>
+
+<p>Android 安全团队负责管理在 Android 平台中发现的以及在 Android 设备绑定的众多核心 Android 应用中发现的安全漏洞。</p>
+
+<p>Android 安全团队会通过内部研究找出安全漏洞,并会对第三方报告的错误采取应对措施。外部错误的来源包括:通过 <a href="https://issuetracker.google.com/issues/new?component=190951">Android 安全问题模板</a>报告的问题、已发布和预发布的学术研究、上游开放源代码项目维护人员、来自设备制造商合作伙伴的通知,以及博客或社交媒体中发布的已公开披露的问题。</p>
+
+<h2 id="report-issues">报告安全问题</h2>
+
+<p>任何开发者、Android 用户或安全研究人员都可以通过 <a href="https://issuetracker.google.com/issues/new?component=190951">Android 安全问题模板</a>将潜在安全问题通知给 Android 安全团队。</p>
+
+<p>外部人员无法查看标记为安全问题的错误,不过在问题经过评估或得到解决后,这些错误最终可能会对外公开。如果您打算提交旨在解决安全问题的补丁程序或兼容性测试套件 (CTS) 测试,请将其附加到错误报告中,然后等待我们的回复,得到我们的回复后再将相应代码上传到 AOSP。</p>
+
+<h2 id="triaging_bugs">为错误分类</h2>
+
+<p>在处理安全漏洞时,第一项任务是确定错误的严重程度以及受影响的 Android 组件。严重程度决定问题的优先级,受影响的组件决定由谁来修复错误、谁将会收到通知以及如何将修复程序提供给用户。</p>
+
+<h3 id="process_types">进程类型</h3>
+<p>下表涵盖了各类进程的定义。进程类型可以按应用或进程的类型来定义,也可以按进程的运行区域来定义。下表按照权限从小到大的顺序排列。</p>
+<table>
+ <tbody><tr>
+ <th>进程类型</th>
+ <th>类型定义</th>
+ </tr>
+ <tr>
+ <td>受限进程</td>
+ <td>在高度受限的 SELinux 域中运行的进程。<br />或<br />受限程度远远超过普通应用的进程。</td>
+ </tr>
+ <tr>
+ <td>非特权进程</td>
+ <td>第三方应用或进程。<br />或<br />在 SELinux <code>untrusted_app</code> 域中运行的应用或进程。</td>
+ </tr>
+ <tr>
+ <td>特权进程</td>
+ <td>功能受 SELinux <code>untrusted_app</code> 域限制的应用或进程。<br />或<br />拥有第三方应用无法获得的重要权限的应用或进程。</td>
+ </tr>
+ <tr>
+ <td>内核</td>
+ <td>属于内核一部分的功能,或在与内核相同的 CPU 环境中运行的功能(例如,设备驱动程序)。</td>
+ </tr>
+ <tr>
+ <td>可信执行环境 (TEE)</td>
+ <td>一种受保护的组件,甚至可以抵御恶意内核的攻击。</td>
+ </tr>
+</tbody></table>
+
+<h3 id="severity">严重程度</h3>
+
+<p>错误的严重程度通常能够反映错误被成功利用后可能造成的潜在危害。可以按照以下条件判断严重程度:</p>
+<table>
+ <tbody><tr>
+ <th>分级</th>
+ <th>被成功利用的后果</th>
+ </tr>
+ <tr>
+ <td><strong>严重</strong></td>
+ <td>
+ <ul>
+ <li>攻击者可以在特权进程中远程执行任意代码</li><li>设备永久损坏(只有重新刷写整个操作系统才能修复设备)</li><li>攻击者可以在未经授权的情况下访问受 TEE 保护的数据</li><li>设备遭到远程发起的永久性拒绝服务攻击(设备无法再使用:完全永久性损坏,或需要重新刷写整个操作系统)</li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td><strong>高</strong></td>
+ <td>
+ <ul>
+ <li>攻击者可以在非特权进程中远程执行任意代码</li><li>攻击者可以远程访问受保护的数据(通常仅限本地安装的应用在请求并获得权限后才可以访问的数据,或仅限特权进程访问的数据)</li><li>攻击者可以远程绕过用户互动要求(攻击者能够访问通常需要由用户发起的功能或需要获得用户许可后方可使用的功能)</li><li>攻击者可以从本地在特权进程中执行任意代码</li><li>设备遭到从本地发起的永久性拒绝服务攻击(设备无法再使用:完全永久性损坏,或需要重新刷写整个操作系统)</li><li>攻击者可以全面深入地绕过内核级防护功能,或利用缓解技术存在的漏洞</li><li>设备遭到远程发起的设备暂时性拒绝服务攻击(远程挂起或重新启动设备)</li><li>攻击者可以从本地绕过针对任何开发者或针对任何安全设置修改的用户互动要求</li><li>攻击者可以全面绕过将应用数据与其他应用隔离开来的操作系统保护功能</li><li>攻击者可以绕过锁定屏幕</li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td><strong>中</strong></td>
+ <td>
+ <ul>
+ <li>攻击者可以在受限进程中远程执行任意代码</li><li>攻击者可以从本地绕过用户互动要求(攻击者能够访问通常需要由用户发起的功能或需要获得用户许可后方可使用的功能)</li><li>设备遭到从本地发起的暂时性拒绝服务攻击(设备需要恢复出厂设置)</li><li>攻击者可以全面深入地绕过用户级防护功能,或在特权进程中利用缓解技术存在的漏洞</li><li>攻击者可以远程访问不受保护的数据(通常可供本地安装的所有应用访问的数据)</li><li>攻击者可以绕过设备保护功能/恢复出厂设置保护功能</li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td><strong>低</strong></td>
+ <td>
+ <ul>
+ <li>攻击者可以全面深入地绕过用户级防护功能,或在非特权进程中利用缓解技术存在的漏洞</li><li>设备遭到从本地发起的暂时性拒绝服务攻击(可通过以下方法解决:使设备启动到安全模式并移除存在问题的应用;或者如果设备不支持安全模式,则将设备恢复出厂设置)</li></ul>
+ </td>
+ </tr>
+</tbody></table>
+
+<h4 id="local_vs_remote">本地和远程</h4>
+
+<p>远程攻击向量指攻击者可以在不安装应用或不实际接触设备的情况下利用的错误。这包括因浏览网页、阅读电子邮件、接收短信或连接到恶意网络而触发的错误。为了进行严重程度分级,Android 安全团队还会将“邻近”攻击向量视为远程攻击向量。这包括只能被实际接近目标设备的攻击者利用的错误,例如需要发送格式错误的 WLAN 数据包或蓝牙数据包的错误。</p>
+
+<p>本地攻击需要受害者安装应用才能得逞。为了进行严重程度分级,Android 安全团队还会将现实攻击向量视为本地攻击。这包括只能被实际接触到设备的攻击者利用的错误,例如锁定屏幕中的错误,或需要插入 USB 数据线的错误。Android 安全团队还会将基于 NFC 的攻击视为本地攻击。</p>
+
+<h3 id="rating_modifiers">分级调节方式</h3>
+<p>虽然通常可以轻松确定安全漏洞的严重程度,但分级可能会因具体情况而异。</p>
+<table>
+ <tbody><tr>
+ <th>原因</th>
+ <th>影响</th>
+ </tr>
+ <tr>
+ <td>需要作为特权进程运行才能执行攻击</td>
+ <td>严重程度降低 1 级</td>
+ </tr>
+ <tr>
+ <td>漏洞特有的详细信息会限制相应问题造成的影响</td>
+ <td>严重程度降低 1 级</td>
+ </tr>
+</tbody></table>
+
+<h3 id="affected_component">受影响的组件</h3>
+
+<p>开发团队负责根据错误所在的组件来修复错误。该组件可能是 Android 平台的核心组件、原始设备制造商 (OEM) 提供的内核驱动程序,或 Nexus 设备上某个预先加载的应用。</p>
+
+<p>AOSP 代码中的错误由 Android 工程团队负责修复。严重程度为“低”的错误、特定组件内的错误或者已经是众所周知的错误可以直接在已公开发布的 AOSP master 分支中进行修复;除此之外的其他错误都会先在我们的内部代码库中进行修复。</p>
+
+<p>组件也是会影响用户如何获取更新的一种因素。如果是框架或内核存在的错误,用户将需要使用无线下载 (OTA) 的固件更新,每个原始设备制造商 (OEM) 都需要推送此类更新。如果是 Google Play 中发布的应用或库(例如,Lollipop 及更高版本中的 Gmail、Google Play 服务、WebView)存在的错误,可以通过 Google Play 向 Android 用户发送更新。</p>
+
+<h2 id="notifying_partners">通知合作伙伴</h2>
+
+<p>当 AOSP 内严重程度为“中”或更高的安全漏洞得到修复后,我们会将问题详细信息通知 Android 合作伙伴,并至少提供针对 3 种最新 Android 版本的补丁程序。Android 安全团队目前提供针对 Android 4.4 版 (KitKat)、5.0 版 (Lollipop)、5.1 版 (Lollipop MR1) 以及 6.0 版 (Marshmallow) 的补丁程序。具体会针对哪些最新版本提供补丁程序会随着每个新 Android 版本的发布而发生变化。</p>
+
+<h2 id="releasing_code_to_aosp">向 AOSP 发布代码</h2>
+
+<p>如果安全错误发生在 AOSP 组件内,我们会先向用户发布 OTA 更新,然后再将修复程序推送到 AOSP。如果问题的严重程度为“低”,我们可能会先直接将修复程序提交到 AOSP master 分支,然后再发布修复程序。</p>
+
+<h2 id="android_updates">接收 Android 更新</h2>
+
+<p>对 Android 系统的更新一般会通过 OTA 更新文件包提供给设备。这些更新可能来自生产相应设备的原始设备制造商 (OEM),也可能来自向相应设备提供服务的运营商。Google Nexus 设备更新由 Google Nexus 团队在相应更新通过运营商技术验收 (TA) 测试程序之后予以提供。Google 还会发布可以旁加载到设备的 <a href="https://developers.google.com/android/nexus/images">Nexus 出厂映像</a>。</p>
+
+<h2 id="updating_google_services">更新 Google 服务</h2>
+
+<p>除了针对安全错误提供补丁程序之外,Android 安全团队还会审核安全错误,以确定是否有其他方式来保护用户。例如,Google Play 会扫描所有应用并移除任何试图利用安全错误的应用。对于通过 Google Play 之外的途径安装的应用,带有 Google Play 服务的设备可能还会使用<a href="https://support.google.com/accounts/answer/2812853">验证应用</a>功能来警告用户注意可能有害的应用。</p>
+
+<h2 id="other_resources">其他资源</h2>
+
+<p>面向 Android 应用开发者的信息:<a href="https://developer.android.com">https://developer.android.com</a></p>
+
+<p>您可以从各个 Android 开放源代码和开发者网站上找到安全信息。建议您先查看以下网址中提供的安全信息:<br />
+<a href="/security/index.html">https://source.android.com/security/index.html</a><br />
+<a href="https://developer.android.com/training/articles/security-tips.html">https://developer.android.com/training/articles/security-tips.html</a></p>
+
+<h3 id="reports">报告</h3>
+<p>Android 安全团队有时会发布报告或白皮书。以下是一些最新发布的内容。</p>
+<ul>
+ <li><a href="/security/reports/Google_Android_Security_2016_Report_Final.pdf">Android 安全性 2016 年年度回顾报告</a></li>
+ <li><a href="/security/reports/Google_Android_Security_2015_Report_Final.pdf">Android 安全性 2015 年年度回顾报告</a></li>
+ <li><a href="/security/reports/Google_Android_Security_2014_Report_Final.pdf">Android 安全性 2014 年年度回顾报告</a></li>
+ <li><a href="/security/reports/Android_WhitePaper_Final_02092016.pdf">Android 安全性白皮书</a></li>
+ <li><a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">潜在有害应用分类</a></li>
+</ul>
+
+<h3 id="slides">演示文稿</h3>
+<p>Android 安全团队会开展各种会议和对话活动。以下是他们使用的一些幻灯片:</p>
+<ul>
+ <li><a href="/security/reports/Android-Bootcamp-2016-Verified-Boot-and-Encryption.pdf">验证启动和加密</a></li>
+ <li><a href="/security/reports/Android-Bootcamp-2016-SafetyNet.pdf">SafetyNet</a></li>
+ <li><a href="/security/reports/Android-Bootcamp-2016-New-App-Lifecycle-for-Encryption.pdf">新应用加密生命周期</a></li>
+ <li><a href="/security/reports/Android-Bootcamp-2016-Keeping-Google-Play-safe.pdf">维护 Google Play 的安全</a></li>
+ <li><a href="/security/reports/Android-Bootcamp-2016-Defense-in-depth-efforts.pdf">深度防御措施</a></li>
+ <li><a href="/security/reports/Android-Bootcamp-2016-Android-Keystore-Attestation.pdf">Keystore 认证</a></li>
+ <li><a href="/security/reports/Android-Bootcamp-2016-Android-Attack-Team.pdf">Android 防攻击团队</a></li>
+</ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/selinux/concepts.html b/zh-cn/security/selinux/concepts.html
new file mode 100644
index 00000000..3eaf5644
--- /dev/null
+++ b/zh-cn/security/selinux/concepts.html
@@ -0,0 +1,106 @@
+<html devsite><head>
+ <title>SELinux 概念</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>请查看此页中的内容,熟悉 SELinux 中使用的概念。</p>
+
+<h2 id="mandatory_access_control">强制访问控制</h2>
+
+<p>安全增强型 Linux (SELinux) 是适用于 Linux 操作系统的强制访问控制 (MAC) 系统。作为 MAC 系统,它与 Linux 中用户非常熟悉的自主访问控制 (DAC) 系统不同。在 DAC 系统中,存在所有权的概念,即特定资源的所有者可以控制与相应资源关联的访问权限。这种系统通常比较粗放,并且容易出现无意中提权的问题。MAC 系统则会在决定是否允许每次访问尝试时都咨询核心机构。</p>
+
+<p>SELinux 已作为 Linux 安全模块 (LSM) 框架的一部分实现,该框架可识别各种内核对象以及对这些对象执行的敏感操作。其中每项操作要执行时,系统都会调用 LSM 钩子函数,以便根据不透明安全对象中存储的关于相应操作的信息来确定是否应允许执行相应操作。SELinux 针对这些钩子以及这些安全对象的管理提供了相应的实现,该实现可结合自己的政策来决定是否允许相应访问。</p>
+
+<p>通过结合使用其他 Android 安全措施,Android 的访问控制政策能够大大降低遭到入侵的计算机和帐号可能蒙受的损失。Android 的自主访问控制和强制访问控制等工具可为您提供一种结构,确保您的软件仅以最低权限级别运行。这样可降低攻击造成的影响,并降低错误进程重写数据甚至是传输数据的可能性。</p>
+
+<p>从 Android 4.3 起,SELinux 开始为传统的自主访问控制 (DAC) 环境提供强制访问控制 (MAC) 保护功能。例如,软件通常情况下必须以 Root 用户帐号的身份运行,才能向原始块设备写入数据。在基于 DAC 的传统 Linux 环境中,如果 Root 用户遭到入侵,攻击者便可以利用该用户身份向每个原始块设备写入数据。不过,可以使用 SELinux 为这些设备添加标签,以便被分配了 Root 权限的进程只能向相关政策中指定的设备写入数据。这样一来,该进程便无法重写特定原始块设备之外的数据和系统设置。</p>
+
+<p>如需更多威胁示例以及使用 SELinux 解决威胁的方法,请参阅<a href="implement.html#use_cases">用例</a>。</p>
+
+<h2 id="enforcement_levels">强制执行级别</h2>
+
+<p>请熟悉以下术语,了解如何按不同的强制执行级别实现 SELinux。</p>
+
+<ul>
+ <li><em></em>宽容模式 - 仅记录但不强制执行 SELinux 安全政策。
+ </li><li><em></em>强制模式 - 强制执行并记录安全政策。如果失败,则显示为 EPERM 错误。
+</li></ul>
+
+<p>在选择强制执行级别时只能二择其一,您的选择将决定您的政策是采取操作,还是仅允许您收集潜在的失败事件。宽容模式在实现过程中尤其有用。</p>
+
+<ul>
+ <li><em></em>不受限 - 一种非常宽松的政策,会在开发过程中禁止执行某些任务并提供暂时的权宜之计。不应对 Android 开放源代码项目 (AOSP) 之外的任何内容使用这种政策。
+ </li><li><em></em>受限 - 针对相应服务编写的自定义政策。这种政策应精确定义允许的事项。
+</li></ul>
+
+<p>不受限政策可用于协助在 Android 中快速实现 SELinux。这种政策适用于大多数 Root 级应用。但应尽可能逐渐将这种政策转换为受限政策,以精确限制每个应用只能使用所需的资源。</p>
+
+<p>您的政策最好是处于强制模式的受限政策。处于强制模式的不受限政策可以掩盖采用受限政策时在宽容模式下会记录的可能违规行为。因此,我们强烈建议设备实现人员实现真正的受限政策。</p>
+
+<h2 id="labels_rules_and_domains">标签、规则和域</h2>
+
+<p><em></em>SELinux 依靠标签来匹配操作和政策。标签用于决定允许的事项。套接字、文件和进程在 SELinux 中都有标签。SELinux 决定基本上是根据为这些对象分配的标签以及定义这些对象可以如何交互的政策做出的。在 SELinux 中,标签采用以下形式:user:role:type:mls_level,其中 type 是访问决定的主要组成部分,可通过构成标签的其他组成部分进行修改。对象会映射到类,对每个类的不同访问类型由权限表示。</p>
+
+<p>政策规则采用以下形式:allow domains types:classes permissions;,其中:<em></em><em></em><em></em><em></em></p>
+
+<ul>
+ <li>Domain<em></em> - 一个进程或一组进程的标签。也称为域类型,因为它只是指进程的类型。
+ </li><li><em></em>Type - 一个对象(例如,文件、套接字)或一组对象的标签。
+ </li><li><em></em>Class - 要访问的对象(例如,文件、套接字)的类型。
+ </li><li><em></em>Permission - 要执行的操作(例如,读取、写入)。
+</li></ul>
+
+<p>使用政策规则时将遵循的结构示例:</p>
+<code>allow appdomain app_data_file:file rw_file_perms;</code>
+
+<p>这表示所有应用域都可以读取和写入带有 app_data_file 标签的文件。请注意,该规则依赖于在 global_macros 文件中定义的宏,您还可以在 te_macros 文件中找到一些其他非常实用的宏。这两个文件均位于 AOSP 源代码树的 <a href="https://android.googlesource.com/platform/system/sepolicy/">system/sepolicy</a> 目录中,其中提供了一些适用于常见的类、权限和规则分组的宏。应尽可能使用这些宏,以便降低因相关权限被拒而导致失败的可能性。</p>
+
+<p><em></em>除了在规则中逐个列出域或类型之外,还可以通过属性引用一组域或类型。简单来说,属性是一组域或类型的名称。每个域或类型都可以与任意数量的属性相关联。当编写的规则指定了某个属性名称时,该名称会自动扩展为列出与该属性关联的所有域或类型。<em></em><em></em>例如,domain 属性与所有进程域相关联,file_type 属性与所有文件类型相关联。</p>
+
+<p>使用上述语法可以创建构成 SELinux 政策基本内容的 avc 规则。规则采用以下形式:</p><pre>
+&lt;rule variant&gt; &lt;source_types&gt; &lt;target_types&gt; : &lt;classes&gt; &lt;permissions&gt;
+</pre>
+
+<p><em></em><em></em><em></em><em></em>该规则指明了,当带有任何 source_types 标签的主体尝试对某个对象执行与任何 permissions 对应的操作时,如果该对象包含带有任何 target_types 标签的任何 classes 类,会发生什么情况。这些规则的一个最常见示例是 allow 规则,例如:</p>
+
+<pre>
+allow domain null_device:chr_file { open };
+</pre>
+
+<p><em></em><em></em><em></em><em></em>该规则允许具有与“domain”属性关联的任何域的进程对 target_type 标签为“null_device”的“chr_file”类(字符设备文件)的对象执行“open”权限所描述的操作。在实际中,该规则可能会扩展为包含其他权限:</p>
+
+<pre>
+allow domain null_device:chr_file { getattr open read ioctl lock append write};
+</pre>
+
+<p>当了解到“domain”是分配给所有进程域的属性,并且 null_device 是字符设备 /dev/null 的标签时,该规则基本上会允许对 <code>/dev/null</code> 进行读写操作。</p>
+
+<p><em></em>一个 domain 通常对应一个进程,而且具有与其关联的标签。</p>
+
+<p>例如,典型的 Android 应用会在自己的进程中运行,并且具有授予其特定受限权限的 untrusted_app 标签。</p>
+
+<p>系统中内置的平台应用会以单独的标签运行,并会被授予一组不同的权限。作为核心 Android 系统的一部分,系统 UID 应用以表示另一组权限的 system_app 标签运行。</p>
+
+<p>在任何情况下,都不应直接允许域访问以下通用标签;而应为一个或多个对象创建一个更具体的类型:</p>
+
+<ul>
+ <li>socket_device</li><li>device</li><li>block_device</li><li>default_service</li><li>system_data_file</li><li>tmpfs</li></ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/selinux/customize.html b/zh-cn/security/selinux/customize.html
new file mode 100644
index 00000000..2b96e186
--- /dev/null
+++ b/zh-cn/security/selinux/customize.html
@@ -0,0 +1,247 @@
+<html devsite><head>
+ <title>自定义 SELinux</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>集成这一基本级别的功能并全面分析结果后,您可以添加自己的政策设置,以便涵盖自己对 Android 操作系统进行的自定义。当然,这些政策仍必须要满足 <a href="/compatibility/index.html">Android 兼容性计划</a>的要求,并且不会移除默认的 SELinux 设置。</p>
+
+<p>制造商不得移除现有的安全设置,否则可能会破坏 Android SELinux 实现及其管控的应用。这包括可能需要进行改进以符合政策并正常运行的第三方应用。应用必须无需进行任何修改即可继续在启用了 SELinux 的设备上正常运行。</p>
+
+<p>当开始着手自定义 SELinux 时,制造商应记得做以下事情:</p>
+
+<ul>
+ <li>为所有新的守护进程编写 SELinux 政策</li><li>尽可能使用预定义的域</li><li>为作为 <code>init</code> 服务衍生的所有进程分配域</li><li>在编写政策之前先熟悉相关的宏</li><li>向 AOSP 提交对核心政策进行的更改</li></ul>
+
+<p>不要做以下事情:</p>
+
+<ul>
+ <li>创建不兼容的政策</li><li>允许对最终用户政策进行自定义</li><li>允许对 MDM 政策进行自定义</li><li>恐吓违反政策的用户</li><li>添加后门程序</li></ul>
+
+<p><em></em>如需查看具体要求,请参阅 <a href="/compatibility/android-cdd.pdf">Android 兼容性定义文档</a>中的“内核安全功能”部分。</p>
+
+<p>SELinux 采用白名单方法,这意味着只能授予政策中明确允许的访问权限。由于 Android 的默认 SELinux 政策已经支持 Android 开放源代码项目,因此原始设备制造商 (OEM) 无需以任何方式修改 SELinux 设置。如果他们要自定义 SELinux 设置,则应格外谨慎,以免破坏现有应用。以下是我们建议的做法:</p>
+
+<ol>
+ <li>使用<a href="https://android.googlesource.com/kernel/common/">最新的 Android 内核</a>。
+ </li><li>采用<a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">最小权限原则</a>。
+ </li><li>仅针对您向 Android 添加的内容调整 SELinux 政策。默认政策能够自动适用于 <a href="https://android.googlesource.com/">Android 开放源代码项目</a>代码库。
+ </li><li>将各个软件组件拆分成多个负责执行单项任务的模块。
+ </li><li>创建用于将这些任务与无关功能隔离开来的 SELinux 政策。
+ </li><li>将这些政策放在 <code>/device/manufacturer/device-name/sepolicy</code> 目录中的 *.te 文件(te 是 SELinux 政策源代码文件使用的扩展名)内,然后使用 <code>BOARD_SEPOLICY</code> 变量将它们纳入到您的版本中。
+ </li><li>先将新域设为宽容域。通过在相应域的 .te 文件中使用宽容声明,可以做到这一点。
+ </li><li>分析结果并优化域定义。
+ </li><li>当 userdebug 版本中不再出现拒绝事件时,移除宽容声明。
+</li></ol>
+
+<p>集成工作完成后,原始设备制造商 (OEM) 的 Android 开发过程还应包含一个确保向前兼容 SELinux 的步骤。在理想的软件开发过程中,仅当软件模型发生变化时,SELinux 政策才需要进行更改,而当实际实现发生变化时,SELinux 政策将不需要进行更改。</p>
+
+<p>当设备制造商开始自定义 SELinux 时,他们应首先审核自己向 Android 添加的内容。如果他们添加了执行新功能的组件,在开启强制模式之前,他们需要先确认该组件是否符合 Android 采用的安全政策,以及原始设备制造商 (OEM) 制定的所有相关政策。</p>
+
+<p>为了防止出现不必要的问题,过度宽泛和过度兼容要好于过度限制和不兼容,后者会导致设备功能损坏。不过,如果制造商进行的更改能够惠及其他人,则应将这些更改作为<a href="/source/submit-patches.html">补丁程序</a>提供给默认 SELinux 政策。如果相应补丁程序已应用于默认安全政策,制造商将不再需要针对每个新的 Android 版本进行此项更改。</p>
+
+<h2 id="example_policy_statements">政策声明示例</h2>
+
+<p>首先请注意,SELinux 基于 <a href="https://www.gnu.org/software/m4/manual/index.html">M4</a> 计算机语言,因此支持多种有助于节省时间的宏。</p>
+
+<p>在以下示例中,所有域都被授予从 <code>/dev/null</code> 读取数据或向其写入数据的权限以及从 <code>/dev/zero</code> 读取数据的权限。</p>
+
+<pre>
+# Allow read / write access to /dev/null
+allow domain null_device:chr_file { getattr open read ioctl lock append write};
+
+# Allow read-only access to /dev/zero
+allow domain zero_device:chr_file { getattr open read ioctl lock };
+</pre>
+
+<p>可以使用 SELinux <code>*_file_perms</code> 宏编写相同的声明(代码非常简短):</p>
+
+<pre>
+# Allow read / write access to /dev/null
+allow domain null_device:chr_file rw_file_perms;
+
+# Allow read-only access to /dev/zero
+allow domain zero_device:chr_file r_file_perms;
+</pre>
+
+<h2 id="example_policy">政策示例</h2>
+
+<p>以下是一个完整的 DHCP 政策示例,我们将在下文中对其进行分析:</p>
+
+<pre>
+type dhcp, domain;
+permissive dhcp;
+type dhcp_exec, exec_type, file_type;
+type dhcp_data_file, file_type, data_file_type;
+
+init_daemon_domain(dhcp)
+net_domain(dhcp)
+
+allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
+};
+allow dhcp self:packet_socket create_socket_perms;
+allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
+allow dhcp shell_exec:file rx_file_perms;
+allow dhcp system_file:file rx_file_perms;
+# For /proc/sys/net/ipv4/conf/*/promote_secondaries
+allow dhcp proc_net:file write;
+allow dhcp system_prop:property_service set ;
+unix_socket_connect(dhcp, property, init)
+
+type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
+allow dhcp dhcp_data_file:dir create_dir_perms;
+allow dhcp dhcp_data_file:file create_file_perms;
+
+allow dhcp netd:fd use;
+allow dhcp netd:fifo_file rw_file_perms;
+allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
+allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
+netlink_nflog_socket } { read write };
+</pre>
+
+<p>下面我们来分析一下该示例:</p>
+
+<p>在第一行(即类型声明)中,该政策声明 DHCP 守护进程将沿用基本的安全政策 (<code>domain</code>)。从前面的声明示例中,我们知道 DHCP 可以从 <code>/dev/null.</code> 读取数据以及向其写入数据。</p>
+
+<p>在第二行中,DHCP 被声明为宽容域。</p>
+
+<p>在 <code>init_daemon_domain(dhcp)</code> 这一行中,该政策声明 DHCP 是从 <code>init</code> 衍生而来的,并且可以与其进行通信。</p>
+
+<p>在 <code>net_domain(dhcp)</code> 这一行中,该政策允许 DHCP 使用 <code>net</code> 域中的常用网络功能,例如读取和写入 TCP 数据包、通过套接字进行通信,以及执行 DNS 请求。</p>
+
+<p>在 <code>allow dhcp proc_net:file write;</code> 这一行中,该政策声明 DHCP 可以向 <code>/proc</code> 中的特定文件写入数据。这一行显示了 SELinux 的详细文件标签。它使用 <code>proc_net</code> 标签来限定 DHCP 仅对 <code>/proc/sys/net</code> 中的文件具有写入权限。</p>
+
+<p>该示例的最后一部分以 <code>allow dhcp netd:fd use;</code> 开头,描述了允许应用之间如何进行交互。该政策声明 DHCP 和 netd 之间可通过文件描述符、FIFO 文件、数据报套接字以及 UNIX 信息流套接字进行通信。DHCP 只能从数据报套接字和 UNIX 信息流套接字中读取数据以及向它们写入数据,但不能创建或打开此类套接字。</p>
+
+<h2 id="available_controls">可用控件</h2>
+
+<table>
+ <tbody><tr>
+ <td>
+<p><strong>类</strong></p>
+</td>
+ <td>
+<p><strong>权限</strong></p>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p>文件</p>
+</td>
+ <td>
+<pre>
+
+ioctl read write create getattr setattr lock relabelfrom relabelto append
+unlink link rename execute swapon quotaon mounton</pre>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p>目录</p>
+</td>
+ <td>
+<pre>
+
+add_name remove_name reparent search rmdir open audit_access execmod</pre>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p>套接字</p>
+</td>
+ <td>
+<pre>
+
+ioctl read write create getattr setattr lock relabelfrom relabelto append bind
+connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
+name_bind</pre>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p>文件系统</p>
+</td>
+ <td>
+<pre>
+
+mount remount unmount getattr relabelfrom relabelto transition associate
+quotamod quotaget</pre>
+ </td>
+ </tr>
+ <tr>
+ <td>
+<p>进程</p>
+ </td>
+ <td>
+<pre>
+
+fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
+getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
+noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
+execstack execheap setkeycreate setsockcreate</pre>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p>安全</p>
+</td>
+ <td>
+<pre>
+
+compute_av compute_create compute_member check_context load_policy
+compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
+read_policy</pre>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p>功能</p>
+</td>
+ <td>
+<pre>
+
+chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
+linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
+ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
+sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
+audit_control setfcap</pre>
+</td>
+ </tr>
+ <tr>
+ <td>
+<p><strong>更多</strong></p>
+</td>
+ <td>
+<p><strong>还有更多</strong></p>
+</td>
+ </tr>
+</tbody></table>
+
+<h2 id="neverallow">neverallow 规则</h2>
+
+<p>SELinux <code>neverallow</code> 规则用于禁止在任何情况下都不应该发生的行为。通过<a href="/compatibility/index.html">兼容性</a>测试,现在各种合作伙伴设备上都会强制执行 SELinux <code>neverallow</code> 规则。</p>
+
+<p>以下准则旨在协助制造商在自定义过程中避免与 <code>neverallow</code> 规则相关的错误。此处使用的规则编号与 Android 5.1 中使用的编号一致,并且会因版本而异。</p>
+
+<p>规则 48:<code>neverallow { domain -debuggerd -vold -dumpstate
+-system_server } self:capability sys_ptrace;</code><br />请参阅 <code>ptrace</code> 的帮助页面。<code>sys_ptrace</code> 功能用于授予对任何进程执行 <code>ptrace</code> 命令的权限。拥有该权限后,可以对其他进程进行广泛的控制。应该只有该规则中列出的指定系统组件享有该权限。如果需要该功能,则通常表明存在的某些内容不适用于面向用户的版本或存在不需要的功能。请移除不必要的组件。</p>
+
+<p>规则 76:<code>neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;</code><br />该规则旨在防止执行系统中的任意代码。具体来说就是,该规则声明仅执行 <code>/system</code> 中的代码,以便通过验证启动等机制实现安全保证。通常情况下,当遇到与这个 <code>neverallow</code> 规则相关的问题时,最好的解决办法是将违规代码移到 <code>/system</code> 分区。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/selinux/device-policy.html b/zh-cn/security/selinux/device-policy.html
new file mode 100644
index 00000000..9f2708d0
--- /dev/null
+++ b/zh-cn/security/selinux/device-policy.html
@@ -0,0 +1,193 @@
+<html devsite><head>
+ <title>编写 SELinux 政策</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 开放源代码项目 (AOSP) 针对所有 Android 设备中常用的应用和服务提供了一个可靠实用的基本政策。AOSP 的贡献者会定期完善该政策。该核心政策应占设备上最终政策的 90-95%,而剩下的 5-10% 则为设备专用自定义政策。本文重点介绍了这些设备专用自定义政策、如何编写设备专用政策,以及在编写此类政策时要避免的一些陷阱。</p>
+
+<h2 id="device_bringup">设备启动</h2>
+
+<p>在编写设备专用政策时,请按顺序执行以下步骤。</p>
+
+<h3 id="run_in_permissive_mode">在宽容模式下运行</h3>
+
+<p>当设备处于<a href="index.html#background">宽容模式</a>时,拒绝事件会被记录下来,但不会被强制执行。宽容模式非常重要,原因有以下两个:</p>
+
+<ol>
+ <li>宽容模式可确保政策启用不会延误其他早期设备启动任务。
+ </li><li>被强制执行的拒绝事件可能会掩盖其他拒绝事件。例如,文件访问通常会涉及目录搜索、文件打开和文件读取操作。在强制模式下,只会发生目录搜索拒绝事件。宽容模式可确保所有拒绝事件都会显示出来。
+</li></ol>
+
+<p>要使设备进入宽容模式,最简单的方法是通过<a href="validate.html#switching_to_permissive">内核命令行</a>来实现。相应命令可以添加到设备的 BoardConfig.mk 文件中:<code>platform/device/&lt;vendor&gt;/&lt;target&gt;/BoardConfig.mk</code>。修改命令行之后,执行 <code>make clean</code>,接着执行 <code>make bootimage</code>,然后刷写新的启动映像。</p>
+
+<p>在此之后,通过以下命令确认宽容模式:</p>
+
+<p><code>adb getenforce</code></p>
+
+<p>将处于全局宽容模式的时间设为两周比较合理。在解决大多数拒绝事件之后,返回到强制模式,并在出现错误时加以解决。对于仍然不断出现拒绝事件的域或仍处于密集开发阶段的服务,可以暂时使其进入宽容模式,但要尽快使其返回到强制模式。</p>
+
+<h3 id="enforce_early">提早采用强制模式</h3>
+
+<p>在强制模式下,拒绝事件会被记录下来,并且会被强制执行。最佳做法是尽早使您的设备进入强制模式。如果花时间等待创建和强制执行设备专用政策,通常会导致有问题的产品和糟糕的用户体验。在实际使用过程中,要提前足够长的时间开始参与 <a href="https://en.wikipedia.org/wiki/Eating_your_own_dog_food">dogfooding</a>,确保对功能进行全面测试。提早开始有助于确保安全问题能够在相关人员做出设计决策时被考虑在内。相反,仅根据观察到的拒绝事件来授予权限是一种不安全的做法。可以利用这段时间对设备进行安全审核,并针对不应被允许的行为提出错误。</p>
+
+<h3 id="remove_or_delete_existing_policy">移除或删除现有政策</h3>
+
+<p>之所以要在新设备上从头开始创建设备专用政策,有很多合理的理由,其中包括:</p>
+
+<ul>
+ <li>安全审核</li><li> <a href="#overuse_of_negation">过度宽容的政策</a>
+ </li><li> <a href="#policy_size_explosion">政策规模缩小</a>
+ </li><li>Dead 政策</li></ul>
+
+<h3 id="address_denials_of_core_services">解决核心服务生成的拒绝事件</h3>
+
+<p>核心服务生成的拒绝事件通常是通过为文件添加标签来解决的。例如:</p>
+
+<pre class="no-pretty-print">
+avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
+dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
+tclass=chr_file permissive=1
+avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
+scontext=u:r:mediaserver:s0
+tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
+</pre>
+
+<p>是完全通过为 <code>/dev/kgsl-3d0</code> 添加适当的标签来解决的。在此示例中,<code>tcontext</code> 是 <code>device</code>。这表示默认环境,在该环境中,<code>/dev</code> 内的所有文件都会获得“<a href="https://android.googlesource.com/platform/external/sepolicy/+/marshmallow-dev/file_contexts#31">device</a>”标签,除非被分配了更具体的标签。直接在此处接受来自 <a href="validate.html#using_audit2allow">audit2allow</a> 的输出会导致不正确且过度宽容的规则。</p>
+
+<p>要解决这种问题,可以为文件添加更具体的标签,在此示例中为 <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#1">gpu_device</a>。由于 <a href="https://android.googlesource.com/platform/external/sepolicy/+/marshmallow-dev/mediaserver.te#24">mediaserver 在核心政策中已有访问 gpu_device 所需的必要权限</a>,因此不再需要更多权限。</p>
+
+<p>其他需要以核心政策中预定义的类型作为标签的设备专用文件:</p>
+
+<ol>
+ <li> <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#31">块设备</a>
+ </li><li> <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#80">音频设备</a>
+ </li><li> <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#21">视频设备</a>
+ </li><li> <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#89">传感器</a>
+ </li><li> <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#8">nfc</a>
+ </li><li>gps_device</li><li> <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/file_contexts#139">/sys 中的文件</a>
+ </li><li>/proc 中的文件</li></ol>
+
+<p>一般情况下,向默认标签授予权限的做法是错误的。其中许多权限都是 <a href="customize.html#neverallow">neverallow</a> 规则所不允许的,但即使该规则并未明确禁止这些权限,也最好是提供具体标签。</p>
+
+<h3 id="label_new_services_and_address_denials">为新服务添加标签并解决拒绝事件</h3>
+
+<p>通过 init 启动的服务需要在各自的 SELinux 域中运行。以下示例会将服务“foo”放入它自己的 SELinux 域中并为其授予权限。</p>
+
+<p>该服务是在设备的 <code>init.&lt;target&gt;.rc</code> 文件中启动的,如下所示:</p>
+
+<pre class="no-pretty-print">
+service foo /system/bin/foo
+ class core
+</pre>
+
+<ol>
+ <li>创建一个新域“foo”<br />
+
+ <p>创建包含以下内容的文件 <code>device/&lt;oem&gt;/&lt;target&gt;/sepolicy/foo.te</code>:</p>
+
+<pre class="no-pretty-print">
+# foo service
+type foo, domain;
+type foo_exec, exec_type, file_type;
+
+init_daemon_domain(foo)
+</pre>
+
+ <p>这是 foo SELinux 域的初始模板,您可以根据该可执行文件执行的具体操作为该模板添加规则。</p>
+ </li>
+
+ <li>为 <code>/system/bin/foo</code> 添加标签<br />
+
+ <p>将以下内容添加到 <code>device/&lt;oem&gt;/&lt;target&gt;/sepolicy/
+ file_contexts</code>:</p>
+
+<pre class="no-pretty-print">
+/system/bin/foo u:object_r:foo_exec:s0
+</pre>
+
+ <p>这可确保为该可执行文件添加适当的标签,以便 SELinux 在适当的域中运行相应服务。</p>
+ </li>
+
+ <li>编译并刷写启动映像和系统映像。</li>
+
+ <li>优化相应域的 SELinux 规则。<br />
+
+ <p>根据拒绝事件确定所需的权限。<a href="validate.html#using_audit2allow">audit2allow</a> 工具提供了一些实用的指南,但该工具仅适用于提供编写政策时所需的信息。切勿只是复制输出内容。</p>
+ </li>
+</ol>
+
+<h3 id="enforcing_mode">切换回强制模式</h3>
+
+<p>可以在宽容模式下进行问题排查,但要尽早切换回强制模式,并尽量保持该模式。</p>
+
+<h2 id="common_mistakes">常见错误</h2>
+
+<p>下面介绍了在编写设备专用政策时发生的常见错误的一些解决方法。</p>
+
+<h3 id="overuse_of_negation">过度使用否定</h3>
+
+<p>以下示例规则类似于锁着前门,但开着窗户:</p>
+
+<p><code>allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms</code>。</p>
+
+<p>该规则的意图很明确:除了第三方应用之外,其他所有应用都可以访问调试设备。</p>
+
+<p>该规则存在几个方面的缺陷。排除 <code>untrusted_app</code> 能起到的效果微不足道,因为所有应用都可以选择在 <code>isolated_app</code> 域中运行服务。同样,如果第三方应用的新域被添加到了 AOSP,它们也可以访问 <code>scary_debug_device</code>。该规则过于宽容。对于大多数域来说,能够访问该调试工具并不能使它们获益。该规则应编写为仅允许需要访问该调试工具的域。</p>
+
+<h3 id="debugging_features_in_production">正式版中的调试功能</h3>
+
+<p>调试功能及其政策不应存在于正式版中。</p>
+
+<p>最简单的替代方案是,仅当 eng/userdebug 版本中停用了 SELinux 时,才允许使用调试功能,例如 <code>adb root</code> 和 <code>adb setenforce 0</code>。</p>
+
+<p>另一种安全的替代方案是在 <a href="https://android.googlesource.com/device/lge/hammerhead/+/marshmallow-dev/sepolicy/platform_app.te#3">userdebug_or_eng</a> 声明中包含调试权限。</p>
+
+<h3 id="policy_size_explosion">政策规模扩张</h3>
+
+<p><a href="http://arxiv.org/abs/1510.05497">在 Wild 中描述 SEAndroid 政策</a>中介绍了一个令人关注的设备政策自定义发展趋势。设备专用政策应占设备上运行的总体政策的 5-10%。如果自定义政策所占的比例超过 20%,则几乎肯定会包含超特权域和 Dead 政策。</p>
+
+<p>过大的政策:</p>
+
+<ul>
+ <li>由于此类政策位于 ramdisk 中,并且还会加载到内核内存中,因此会占据两倍的内存。
+ </li><li>需要较大的启动映像,浪费磁盘空间。
+ </li><li>影响运行时政策查询次数。
+</li></ul>
+
+<p>以下示例显示了制造商专用政策分别占设备上政策 50% 和 40% 的两种设备。重写政策大幅提高了安全性,而且功能方面没有任何损失,如下所示。(AOSP 设备 Shamu 和 Flounder 也包含在了该示例中,以便进行比较。)</p>
+
+<p><img alt="图 1:安全审核后的设备专用政策规模对比。" src="images/selinux_device_policy_reduction.png"/></p>
+<p class="img-caption"><strong>图 1</strong>. 安全审核后的设备专用政策规模对比。</p>
+
+<p>在两种设备中,政策的规模和权限数量都大大减小了。政策规模的减小几乎完全是因为移除了不必要的权限,其中许多权限可能是由 audit2allow 生成且被随意添加到政策中的规则。对于这两种设备来说,Dead 域也是一个问题。</p>
+
+<h3 id="granting_the_dac_override_capability">授予 dac_override 权限</h3>
+
+<p><code> dac_override</code> 拒绝事件意味着违规进程正在尝试使用错误的 unix user/group/world 权限访问某个文件。正确的解决方案几乎从不授予 <code>dac_override</code> 权限,而是<a href="https://android-review.googlesource.com/#/c/174530/5/update_engine.te@11">更改相应文件或进程的 unix 权限</a>。有些域(例如 init、vold 和 installd)确实需要能够替换 unix 文件权限才能访问其他进程的文件。要查看更深入的讲解,请访问 <a href="http://danwalsh.livejournal.com/69478.html">Dan Walsh 的博客</a>。</p>
+
+<h2 id="additional_resources">其他资源</h2>
+
+<p>如果要提问或提出代码审核请求,<a href="http://seandroid.bitbucket.org/ForMoreInformation.html">SEAndroid 论坛</a>是一个的绝佳场所。</p>
+
+<p>AOSP 提供了关于 <a href="index.html">Android 上的 SELinux</a> 的简要介绍。</p>
+
+<p>如需更深入的说明,请点击<a href="http://seandroid.bitbucket.org/">此处</a>。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/selinux/implement.html b/zh-cn/security/selinux/implement.html
new file mode 100644
index 00000000..69abd1cd
--- /dev/null
+++ b/zh-cn/security/selinux/implement.html
@@ -0,0 +1,129 @@
+<html devsite><head>
+ <title>实现 SELinux</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>SELinux 设为了“默认拒绝”模式,也就是说,对于在内核中存在钩子的每一次访问,都必须获得政策的明确许可。这意味着政策文件中包含规则、类型、类、权限等方面的大量信息。关于 SELinux 的完整注意事项不在本文档的讨论范围之内,现在您必须要了解的是在启动新的 Android 设备时如何编写政策规则。目前有大量关于 SELinux 的信息可供您参考。关于建议的资源,请参阅<a href="/security/selinux#supporting_documentation">支持文档</a>。</p>
+
+<h2 id="summary_of_steps">步骤总结</h2>
+
+<p>下面简要总结了在 Android 设备上实现 SELinux 时需要执行的步骤:</p>
+
+<ol>
+ <li>在内核和配置中添加 SELinux 支持。
+ </li><li>为通过 <code>init</code> 启动的每项服务(进程或守护进程)分配专用的域。
+ </li><li>通过以下方式标识这些服务:<ul>
+ <li>查看 init.&lt;device&gt;.rc 文件并找到所有服务。
+ </li><li>检查 <code>dmesg</code> 输出中以下形式的警告:“init: Warning! Service name needs a SELinux domain defined; please fix!”(init:警告!服务名称需要一个已定义的 SELinux 域;请更正!)。<em></em>
+ </li><li>检查 <code>ps -Z | grep init</code> 输出,看看哪些服务正在 init 域中运行。
+ </li></ul>
+ </li><li>为所有新进程、驱动程序、套接字等添加标签。需要为所有对象添加适当的标签,以确保它们能够与您应用的政策正确交互。请参阅 AOSP 中使用的标签,以便在创建标签名称时参考。
+ </li><li>制定全面涵盖所有标签的安全政策,并将权限限定到其绝对最低级别。
+</li></ol>
+
+<p>原始设备制造商 (OEM) 最好从 AOSP 中的政策入手,然后在这些政策的基础上创建自己的自定义政策。</p>
+
+<h2 id="key_files">关键文件</h2>
+
+<p>SELinux for Android 随附了立即启用 SELinux 所需的一切。您只需集成<a href="https://android.googlesource.com/kernel/common/">最新的 Android 内核</a>,然后整合 <a href="https://android.googlesource.com/platform/system/sepolicy/">system/sepolicy</a> 目录中的文件即可:</p>
+
+<p><a href="https://android.googlesource.com/kernel/common/">https://android.googlesource.com/kernel/common/ </a></p>
+
+<p><a href="https://android.googlesource.com/platform/system/sepolicy/">https://android.googlesource.com/platform/system/sepolicy/</a></p>
+
+<p>这些文件在编译后会包含 SELinux 内核安全政策,并涵盖上游 Android 操作系统。您应该不需要直接修改 system/sepolicy 中的文件,而只需添加您自己的设备专用政策文件(位于 /device/manufacturer/device-name/sepolicy 目录中)即可。</p>
+
+<p>要实现 SELinux,您必须创建或修改以下文件:</p>
+
+<ul>
+ <li><em></em>新的 SELinux 政策源代码 (*.te) 文件 - 位于 <root>/device/manufacturer/device-name/sepolicy 目录中。这些文件用于定义域及其标签。在编译到单个 SELinux 内核政策文件时,新的政策文件会与现有的政策文件组合在一起。
+<p class="caution"><strong>重要提示</strong>:请勿更改 Android 开放源代码项目提供的 app.te 文件,否则可能会破坏所有第三方应用。</p>
+ </root></li><li><em></em>更新后的 BoardConfig.mk Makefile - 位于<device-name>包含 sepolicy 子目录的目录中。如果初始实现中没有 sepolicy 子目录,那么在该子目录创建之后,必须更新 BoardConfig.mk makefile,以引用该子目录。
+ </device-name></li><li><em></em>file_contexts - 位于 sepolicy 子目录中。该文件用于为文件分配标签,并且可供多种用户空间组件使用。在创建新政策时,请创建或更新该文件,以便为文件分配新标签。要应用新的 file_contexts,您必须重新构建文件系统映像,或对要重新添加标签的文件运行 <code>restorecon</code>。在升级时,对 file_contexts 所做的更改会在升级过程中自动应用于系统和用户数据分区。此外,还可以通过以下方式使这些更改在升级过程中自动应用于其他分区:在以允许读写的方式装载相应分区后,将 restorecon_recursive 调用添加到 init.<em>board</em>.rc 文件中。
+ </li><li><em></em>genfs_contexts - 位于 sepolicy 子目录中。该文件用于为不支持扩展属性的文件系统(例如,proc 或 vfat)分配标签。此配置会作为内核政策的一部分进行加载,但更改可能对核心内 inode 无效。要全面应用更改,需要重新启动设备,或卸载后重新装载文件系统。此外,通过使用 context=mount 选项,还可以为装载的特定系统文件(例如 vfat)分配特定标签。
+ </li><li><em></em>property_contexts - 位于 sepolicy 子目录中。该文件用于为 Android 系统属性分配标签,以便控制哪些进程可以设置这些属性。在启动期间以及 selinux.reload_policy 属性每次被设为 1 时,init 进程都会读取此配置。
+ </li><li><em></em>service_contexts - 位于 sepolicy 子目录中。该文件用于为 Android Binder 服务分配标签,以便控制哪些进行可以为相应服务添加(注册)和查找(查询)Binder 引用。在启动期间以及 selinux.reload_policy 属性每次被设为 1 时,servicemanager 进程都会读取此配置。
+ </li><li><em></em>seapp_contexts - 位于 sepolicy 子目录中。该文件用于为应用进程和 /data/data 目录分配标签。在每次应用启动时,Zygote 进程都会读取此配置;在启动期间以及 selinux.reload_policy 属性每次被设为 1 时,installd 都会读取此配置。
+ </li><li><em></em>mac_permissions.xml - 位于 sepolicy 子目录中。该文件用于根据应用签名和应用软件包名称(后者可选)为应用分配 seinfo 标记。然后,分配的 seinfo 标记可在 seapp_contexts 文件中用作密钥,以便为带有该 seinfo 标记的所有应用分配特定标签。在启动期间,system_server 会读取此配置。
+</li></ul>
+
+<p>接下来,只需在 sepolicy 子目录和各个政策文件创建之后,更新 BoardConfig.mk Makefile(位于包含 sepolicy 子目录的目录中)以引用该子目录和这些政策文件即可,如下所示。BOARD_SEPOLICY 变量及其含义记录在 system/sepolicy/README 文件中。</p>
+
+<pre>
+BOARD_SEPOLICY_DIRS += \
+ &lt;root&gt;/device/manufacturer/device-name/sepolicy
+
+BOARD_SEPOLICY_UNION += \
+ genfs_contexts \
+ file_contexts \
+ sepolicy.te
+</pre>
+
+<p class="note"><strong>注意</strong>:从 M 版开始已不再需要 BOARD_SEPOLICY_UNION,因为 BOARD_SEPOLICY_DIRS 变量中包含的任何目录内的所有政策文件都会与基本政策自动合并。</p>
+
+<p>设备在重新编译后会启用 SELinux。现在,您可以根据自己向 Android 操作系统添加的内容自定义自己的 SELinux 政策(如<a href="customize.html">自定义</a>中所述),也可以验证您的现有设置(如<a href="validate.html">验证</a>中所述)。</p>
+
+<p>在新政策文件和 BoardConfig.mk 更新部署到位后,新政策设置会立即自动内置到最终的内核政策文件中。</p>
+
+<h2 id="use_cases">用例</h2>
+
+<p>下面列举了一些在开发软件以及制定关联的 SELinux 政策时需要注意的具体漏洞:</p>
+
+<p><strong>符号链接</strong> - 由于符号链接以文件形式显示,因此通常也是作为文件被读取。这可能会导致漏洞。例如,某些特权组件(例如 init)会更改某些文件的权限,有时会使之极度开放。</p>
+
+<p>这样一来,攻击者便可以将这些文件替换成指向其控制的代码的符号链接,从而重写任意文件。但如果您知道自己的应用绝不会遍历符号链接,则可以通过 SELinux 来禁止您的应用遍历符号链接。</p>
+
+<p><strong>系统文件</strong> - 以应该只有系统服务器可以修改的一系列系统文件为例。由于 netd、init 和 vold 是以 Root 身份运行的,因此它们也可以访问这些系统文件。这样一来,如果 netd 遭到入侵,它将可以入侵这些文件,并可能会入侵系统服务器本身。</p>
+
+<p>借助 SELinux,您可以将这些文件标识为系统服务器数据文件。这样一来,系统服务器就是唯一对这些文件具有读写权限的域。即使 netd 遭到入侵,它也无法将域切换到系统服务器域并访问这些系统文件,就算它是以 Root 身份运行的也是如此。</p>
+
+<p><strong>应用数据</strong> - 另一个示例是必须以 Root 身份运行但不应获得应用数据访问权限的一系列函数。这非常有用,因为可以做出广泛的声明,例如禁止与应用数据无关的特定域访问互联网。</p>
+
+<p><strong>setattr</strong> - 对于 chmod、chown 等命令,您可以标识关联域可以在哪些文件中进行 setattr 操作。这样一来,便可以禁止对这些文件之外的任何文件进行此类更改,即使以 Root 身份进行也不例外。因此,应用可以对带 app_data_files 标签的文件运行 chmod 和 chown 命令,但不能对带 shell_data_files 或 system_data_files 标签的文件运行这些命令。</p>
+
+<h2 id="steps_in_detail">详细步骤</h2>
+
+<p>下面详细介绍了 Android 建议您如何采用并自定义 SELinux 来保护设备:</p>
+
+<ol>
+ <li>在内核中启用 SELinux:
+<code>CONFIG_SECURITY_SELINUX=y</code>
+ </li><li>更改 kernel_cmdline 参数,以便:<br />
+<code>BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive</code>。
+<br />
+这仅适用于初始制定设备政策的情况。在拥有初始引导程序政策后,请移除此参数,以便将设备恢复强制模式,否则设备将无法通过 CTS 验证。</li><li>以宽容模式启动系统,看看在启动时会遇到哪些拒绝事件:<br />
+在 Ubuntu 14.04 或更高版本中:<br />
+<code>adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/<em>board</em>/root/sepolicy</code>
+<br />
+在 Ubuntu 12.04 中:
+<code>adb shell su -c dmesg | grep denied | audit2allow</code>
+ </li><li>评估输出。如需查看相关说明和工具,请参阅<a href="validate.html">验证</a>。
+ </li><li>标识设备以及需要添加标签的其他新文件。
+ </li><li>为您的对象使用现有标签或新标签。查看 *_contexts 文件,了解之前是如何为内容添加标签的,然后根据对标签含义的了解分配一个新标签。这最好是一个能够融入到政策中的现有标签,但有时需要使用新标签,并且还需要关于访问该标签的规则。
+ </li><li>标识应该拥有自己的安全域的域/进程。可能需要为其中每个域/进程从头开始编写政策。例如,从 <code>init</code> 衍生的所有服务都应该有自己的安全域。可以通过以下命令查看保持运行的服务(不过所有服务都需要如此处理):<br />
+<code>$ adb shell su -c ps -Z | grep init</code><br />
+<code>$ adb shell su -c dmesg | grep 'avc: '</code>
+ </li><li>查看 init.&lt;device&gt;.rc,以找出所有没有类型的服务。应提早为此类服务提供域,以避免向 init 添加规则或将 <code>init</code> 访问权限与其自身政策中的访问权限混淆。
+ </li><li>将 <code>BOARD_CONFIG.mk</code> 设为使用 <code>BOARD_SEPOLICY_*</code> 变量。如需关于如何进行此项设置的详细信息,请参阅 system/sepolicy 中的 README。
+ </li><li>检查 init.&lt;device&gt;.rc 和 fstab.&lt;device&gt; 文件,确保每一次使用“mount”都对应一个添加了适当标签的文件系统,或者指定了 context= mount 选项。
+ </li><li>查看每个拒绝事件,并创建 SELinux 政策来妥善处理每个拒绝事件。请参阅<a href="customize.html">自定义</a>中的示例。
+</li></ol>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/selinux/index.html b/zh-cn/security/selinux/index.html
new file mode 100644
index 00000000..b163e3d7
--- /dev/null
+++ b/zh-cn/security/selinux/index.html
@@ -0,0 +1,67 @@
+<html devsite><head>
+ <title>Android 中的安全增强型 Linux</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="introduction">简介</h2>
+
+<p>Android 安全模型部分基于应用沙盒的概念。每个应用都在自己的沙盒内运行。在 Android 4.3 之前的版本中,这些沙盒是通过为每个应用创建独一无二的 Linux UID(在应用安装时创建)来定义的。从 Android 4.3 版起,安全增强型 Linux (SELinux) 开始用于进一步定义 Android 应用沙盒的边界。</p>
+
+<p>作为 Android <a href="/security/index.html">安全模型</a>的一部分,Android 使用 SELinux 对所有进程强制执行强制访问控制 (MAC),其中包括以 Root/超级用户权限运行的进程(也称为 Linux 功能)。SELinux 能够限制特权进程并能够自动创建安全政策,从而可提升 Android 的安全性。</p>
+
+<p>很多公司和组织都为此做出了卓越的贡献;<a href="https://android.googlesource.com/">android.googlesource.com</a> 上公开了所有 Android 代码和贡献者,以供所有人查看。借助 SELinux,Android 可以更好地保护和限制系统服务、控制对应用数据和系统日志的访问、降低恶意软件的影响,并保护用户免遭移动设备上的代码可能存在的缺陷的影响。</p>
+
+<p>Android 中包含 SELinux(处于强制模式)和默认适用于整个 <a href="https://android.googlesource.com/">Android 开放源代码项目</a>的相应安全政策。在强制模式下,非法操作会被阻止,并且所有尝试进行的违规行为都会被内核记录到 <code>dmesg</code> 和 <code>logcat</code> 中。Android 设备制造商应收集与错误相关的信息,以便在实施其软件和 SELinux 政策之前先对其进行优化。</p>
+
+<h2 id="background">背景</h2>
+
+<p>SELinux 采用默认拒绝的方式运行。任何未经明确允许的行为都会被拒绝。SELinux 可以采用以下任一种全局模式运行:宽容模式和强制模式。在宽容模式下,权限拒绝事件会被记录下来,但不会被强制执行;在强制模式下,拒绝事件会被记录下来,并且会被强制执行。此外,SELinux 还支持特定域宽容模式。在这种模式下,可将特定域(进程)设为宽容域,同时使系统的其余部分处于全局强制模式。域简单来说就是安全政策中用于标识一个进程或一组进程的标签,安全政策会以相同的方式对待使用相同域作为标签的所有进程。借助特定域宽容模式,可逐渐将 SELinux 应用于系统中越来越多的部分。此外,借助特定域宽容模式,还可以为新服务制定政策,同时确保系统的其余部分处于强制模式。</p>
+
+<p>在 Android 5.0 (L) 版本中,Android 开始全面强制执行 SELinux。这基于 4.3 版中的宽容模式和 4.4 中的部分强制模式。简而言之,Android 正在从对有限的一组关键域(<code>installd</code>、<code>netd</code>、<code>vold</code> 和 <code>zygote</code>)强制执行 SELinux 转为对所有域(超过 60 个域)强制执行 SELinux。这意味着,制造商必须要更好地了解并扩展其 SELinux 实现,以便提供兼容的设备。请注意:</p>
+
+<ul>
+<li>在 5.0 版中,所有域均处于强制模式</li>
+<li><code>init</code> 以外的任何进程都不应在 <code>init</code> 域中运行</li>
+<li>如果出现任何常规拒绝事件(对于 block_device、socket_device、default_service 等),都表示设备需要一个特殊域</li>
+</ul>
+
+<h2 id="supporting_documentation">支持文档</h2>
+
+<p>如需关于如何构建实用政策的详细信息,请参阅以下文档:</p>
+
+<p><a href="http://seandroid.bitbucket.org/PapersandPresentations.html">http://seandroid.bitbucket.org/PapersandPresentations.html</a></p>
+
+<p><a href="https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid">https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid</a></p>
+
+<p><a href="https://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf">https://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf</a></p>
+
+<p><a href="https://www.internetsociety.org/sites/default/files/02_4.pdf">https://www.internetsociety.org/sites/default/files/02_4.pdf</a></p>
+
+<p><a href="http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf">http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf</a></p>
+
+<p><a href="http://selinuxproject.org/page/ObjectClassesPerms">http://selinuxproject.org/page/ObjectClassesPerms</a></p>
+
+<p><a href="https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/implementing-selinux-as-linux-security-module-report.pdf">https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/implementing-selinux-as-linux-security-module-report.pdf</a></p>
+
+<p><a href="https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/configuring-selinux-policy-report.pdf">https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/configuring-selinux-policy-report.pdf</a></p>
+
+<p><a href="https://www.gnu.org/software/m4/manual/index.html">https://www.gnu.org/software/m4/manual/index.html</a></p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/selinux/validate.html b/zh-cn/security/selinux/validate.html
new file mode 100644
index 00000000..e8de1c7c
--- /dev/null
+++ b/zh-cn/security/selinux/validate.html
@@ -0,0 +1,107 @@
+<html devsite><head>
+ <title>验证 SELinux</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 强烈建议原始设备制造商 (OEM) 全面测试其 SELinux 实现。制造商在实现 SELinux 时,应先为设备上需要测试的所有内容应用新政策。</p>
+
+<p>应用新政策后,可以通过执行 getenforce 命令来确认 SELinux 在设备上的运行模式是否正确</p>
+
+<p>该命令将会显示全局 SELinux 模式:强制或宽容。请注意,该命令只会显示全局 SELinux 模式。要确定每个域的 SELinux 模式,您必须查看相应的文件,或运行带有适当 (-p) 标记的最新版 <code>sepolicy-analyze</code>(位于 /platform/system/sepolicy/tools/ 中)。</p>
+
+<h2 id="reading_denials">读取拒绝事件</h2>
+
+<p>接下来是检查是否存在错误。错误会以事件日志的形式路由到 dmesg 和 <code>logcat</code>,并可在设备上从本地查看。制造商应先检查这些设备上路由到 dmesg 的 SELinux 输出并优化设置,然后再在宽容模式下公开发布,最后切换到强制模式。SELinux 日志消息中包含“avc:”,因此可以通过 <code>grep</code> 轻松找到。可以通过运行 <code>cat /proc/kmsg</code> 来获取当前的拒绝事件日志,也可以通过运行 cat <code>/proc/last_kmsg</code> 来获取上次启动时的拒绝事件日志。</p>
+
+<p>借助这种输出,制造商可以轻松发现系统用户或组件违反 SELinux 政策的行为。然后,制造商便可以通过对相应软件和/或 SELinux 政策进行更改来防范这种恶意行为。</p>
+
+<p>具体来说就是,这些日志消息会指明在强制模式下哪些进行会失败以及失败原因。示例如下:</p>
+
+<pre>
+avc: denied { connectto } for pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
+scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket
+</pre>
+
+<p>该输出的解读如下:</p>
+
+<ul>
+ <li>上方的 <code>{ connectto }</code> 表示正在执行的操作。通过它和末尾的 <code>tclass</code> (<code>unix_stream_socket</code>),您可以大致了解正在对什么对象执行什么操作,在该示例中是某个操作方正在试图连接到 UNIX 信息流套接字。
+ </li><li><code>scontext (u:r:shell:s0)</code> 旨在告诉您发起相应操作的环境,在该示例中是某个作为 shell 运行的操作方。
+ </li><li><code>tcontext (u:r:netd:s0)</code> 旨在告诉您操作目标的环境,在该示例中是某个归 <code>netd</code> 所有的 unix_stream_socket。
+ </li><li>顶部的 <code>comm="ping"</code> 旨在为您提供更多提示,让您了解拒绝事件发生时正在运行的操作。在该示例中,这是一个非常实用的提示。
+</li></ul>
+
+<p>下面是另一个示例:</p>
+
+<pre>
+$ adb shell su root dmesg | grep 'avc: '
+&lt;5&gt; type=1400 audit: avc: denied { read write } for pid=177
+comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
+tcontext=u:object_r:kmem_device:s0 tclass=chr_file
+</pre>
+
+<p>以下是此拒绝事件的关键元素:</p>
+
+<ul>
+ <li>操作 - 试图进行的操作使用括号突出显示:<code>read write</code> 或 <code>setenforce</code>。<em></em>
+ </li><li>操作方 - <code>scontext</code>(来源环境)条目表示操作方,在该示例中是<code> rmt_storage</code> 守护进程。<em></em>
+ </li><li>对象 - <code>tcontext</code>(目标环境)条目表示正在对哪个对象执行操作,在该示例中是 kmem。<em></em>
+ </li><li>结果 - <code>tclass</code>(目标类别)条目表示操作对象的类型,在该示例中是 <code>chr_file</code>(字符设备)。<em></em>
+</li></ul>
+
+<h2 id="switching_to_permissive">切换到宽容模式</h2>
+
+<p class="caution"><strong>重要提示</strong>:生产设备不支持宽容模式。CTS 测试可确认是否已启用强制模式。</p>
+
+<p>要通过 ADB 将设备的 SELinux 执行模式切换到全局宽容模式,请以根用户的身份执行以下命令:</p>
+
+<pre>
+$ adb shell su root setenforce 0
+</pre>
+
+<p>或在内核命令行中输入以下命令(在设备启动初期):</p>
+
+<pre>
+androidboot.selinux=permissive
+androidboot.selinux=enforcing
+</pre>
+
+<h2 id="using_audit2allow">使用 audit2allow</h2>
+
+<p><code>selinux/policycoreutils/audit2allow</code> 工具可以获取 <code>dmesg</code> 拒绝事件并将其转换成相应的 SELinux 政策声明。因此,该工具有助于大幅加快 SELinux 开发速度。<code>audit2allow</code> 会作为 Android 源代码树的一部分被移植到设备上,并会在您基于源代码编译 Android 时自动进行编译。</p>
+
+<p>要使用该工具,请运行以下命令:</p>
+
+<pre>
+$ adb shell su root dmesg | audit2allow -p $OUT/root/sepolicy
+</pre>
+
+<p>不过,在检查各种潜在增加项是否存在越界权限时务必要谨慎。例如,为 audit2allow 馈送之前显示的 <code>rmt_storage</code> 拒绝事件会导致以下建议的 SELinux 政策声明:</p>
+
+<pre>
+#============= shell ==============
+allow shell kernel:security setenforce;
+#============= rmt ==============
+allow rmt kmem_device:chr_file { read write };
+</pre>
+
+<p>这会授予 <code>rmt</code> 向内核内存写入内容的权限,从而形成明显的安全漏洞。通常情况下,<code>audit2allow</code> 声明只是一个起点,在这之后,可能还需要更改来源域以及目标的标签,并纳入适当的宏,才能获得好的政策。有时,要解决正在检查的拒绝事件,不应对政策进行任何更改,而是应更改违规的应用。</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/trusty/index.html b/zh-cn/security/trusty/index.html
new file mode 100644
index 00000000..71a24361
--- /dev/null
+++ b/zh-cn/security/trusty/index.html
@@ -0,0 +1,95 @@
+<html devsite><head>
+ <title>Trusty TEE</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Trusty 是一组在移动设备上支持可信执行环境 (TEE) 的软件组件。</p>
+
+<p>Trusty 包含以下组件:</p>
+
+<ul>
+ <li>一个在用于提供 TEE 的处理器上运行的操作系统(Trusty 操作系统)</li><li>适用于 Android 内核 (Linux) 的驱动程序,旨在促进与在 Trusty 操作系统下运行的应用之间的通信</li><li>一组适用于 Android 系统软件的库,旨在使用内核驱动程序促进与在 Trusty 操作系统中执行的可信应用之间的通信</li></ul>
+
+<p><strong>重要提示</strong>:Trusty 和 Trusty API 随时可能发生变化。</p>
+
+<p>如需关于 Trusty API 的信息,请参阅 <a href="trusty-ref.html">API 参考</a>。</p>
+
+<h2 id="uses_examples">使用和示例</h2>
+
+<p>所有 TEE 操作系统(不仅仅是 Trusty)均可用于 TEE 实现。</p>
+
+<p>TEE 处理器通常是系统内的单独微处理器,或是主处理器的虚拟化实例。TEE 处理器与系统的其余部分之间使用由硬件支持的内存和 I/O 保护机制隔离开来。</p>
+
+<p>TEE 处理器如今已成为移动设备的基本组成部分。这些设备上的主处理器会被视为“不可信”,它们无法访问制造商用于存储机密数据(例如,设备专用加密密钥)的特定 RAM、硬件寄存器和 Fuse 区域。在主处理器上运行的软件会将所有需要使用机密数据的操作委派给 TEE 处理器。</p>
+
+<p>在 Android 生态系统中,最广为人知的不可信主处理器示例是用于受保护内容的 <a href="/devices/drm.html">DRM 框架</a>。在 TEE 处理器上运行的软件可以访问解密受保护内容所需的设备专用密钥。主处理器只能看到已加密的内容,这样一来,就可以针对基于软件的攻击提供高级别的安全保障和保护。</p>
+
+<p>TEE 还有许多其他用法,例如移动支付、安全银行、全盘加密、多因素身份验证、设备重置保护、抗重放攻击的持久存储、无线显示(“投射”)受保护的内容、安全的 PIN 码和指纹处理,甚至还有恶意软件检测。</p>
+
+<p>Trusty 提供用于开发以下两类应用的 API:</p>
+
+<ul>
+ <li>在 TEE 处理器上运行的可信应用或服务</li><li>在主处理器上运行并使用可信应用提供的服务的普通/不可信应用</li></ul>
+
+<p>在主处理器上运行的软件可以使用 Trusty API 连接到可信应用并与它们交换任意消息,就像通过 IP 提供的网络服务一样。应用负责使用应用级协议确定这些消息的数据格式和语义。消息传递的可靠性由底层 Trusty 基础架构(采用在主处理器上运行的驱动程序的形式)来保证,并且通信完全是异步进行的。</p>
+
+<h2 id="trusted_applications_and_services">可信应用和服务</h2>
+
+<p>可信应用会以单独进程的形式在 Trusty 操作系统内核下运行。每个进程都会利用 TEE 处理器的 MMU 功能在各自的虚拟内存沙盒中运行。内核会使用由安全计时器驱动且按优先级进行调度的轮询调度程序安排这些进程。在最新版本的 Trusty 中,所有 Trusty 应用均具有相同的优先级。</p>
+
+<p>可以使用 C/C++(对 C++ 的支持有限)编写适用于 Trusty 操作系统的应用,此类应用可以访问小型的 C 库。<code>main()</code> 函数目前不接受任何参数。系统调用存根是作为该库的一部分在本机汇编代码中提供的,因此可按名称访问系统调用。</p>
+
+<h3 id="language_threading">语言和线程支持</h3>
+
+<p>所有 Trusty 应用均为单线程应用;目前不支持在 Trusty 用户空间中使用多线程。</p>
+
+<h3 id="application_structure">应用结构</h3>
+
+<p>Trusty 应用会在加载期间初始化一次,并且在 TEE 处理器重置之前,会一直保留在内存中。Trusty 目前不支持动态加载和取消加载应用。</p>
+
+<p>可信应用是作为<strong>事件驱动型服务器</strong>编写的,会等待其他应用或主处理器上运行的应用发出的命令。此外,可信应用也可以作为其他可信服务器应用的客户端。以下 API 部分中介绍的事件将由 Trusty 内核传送到可信应用。</p>
+
+<h2 id="third-party_trusty_applications">第三方 Trusty 应用</h2>
+
+<p>目前,所有 Trusty 应用都是由一个开发方开发的,并封装了 Trusty 内核映像。整个映像会由引导加载程序在启动过程中进行签名并验证。该版本的 Trusty 中不支持第三方应用开发。</p>
+
+<p>尽管 Trusty 操作系统支持开发新应用,但在开发新应用时务必要万分谨慎;每个新应用都会使系统可信计算基 (TCB) 的范围增大。可信应用可以访问设备机密数据,并且可以利用这些数据进行计算或数据转换。</p>
+
+<p>能够开发在 TEE 中运行的新应用为进行创新提供了多种可能性。不过,根据 TEE 的定义,如果这些应用没有附带某种形式的证明其<strong>可信</strong>的凭据,则无法分发。这种凭据通常采用数字签名的形式,即由应用运行时所在产品的用户信任的实体提供的数字签名。</p>
+
+<h2 id="downloading_building">下载和编译 Trusty</h2>
+
+<p>您可以通过以下网址找到 Android 开放源代码项目 (AOSP) 中的 Trusty 实现:<br />
+<a href="https://android-review.googlesource.com/#/admin/projects/?filter=trusty">https://android-review.googlesource.com/#/admin/projects/?filter=trusty</a></p>
+
+<p>要查看 AOSP 上的 Trusty 内核分支,请访问:<br />
+<a href="https://android.googlesource.com/kernel/common/+/android-trusty-3.10">https://android.googlesource.com/kernel/common/+/android-trusty-3.10</a><br />
+<a href="https://android.googlesource.com/kernel/common/+/android-trusty-3.18">https://android.googlesource.com/kernel/common/+/android-trusty-3.18</a></p>
+
+<p>要实现 Trusty,请运行以下命令(假设 Android 工具链已位于路径中):</p>
+<pre>
+$ repo init -u https://android.googlesource.com/trusty/manifest
+$ repo sync
+$ make -j24 generic-arm64
+</pre>
+
+<p>您可以从 <code>device/*/*/project/*</code> 中选择其他受支持的编译目标</p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/verifiedboot/dm-verity.html b/zh-cn/security/verifiedboot/dm-verity.html
new file mode 100644
index 00000000..d28f9aeb
--- /dev/null
+++ b/zh-cn/security/verifiedboot/dm-verity.html
@@ -0,0 +1,186 @@
+<html devsite><head>
+ <title>实现 dm-verity</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<h2 id="operation">操作</h2>
+
+<p>dm-verity 保护机制位于内核中。因此,如果获取 Root 权限的软件在内核启动之前入侵系统,它将会一直拥有该权限。为了降低这种风险,大多数制造商都会使用烧录到设备的密钥来验证内核。该密钥在设备出厂后将无法被更改。</p>
+
+<p>制造商会使用该密钥来验证第一级引导加载程序中的签名,而该引导加载程序会依次验证后续级别引导加载程序、应用引导加载程序和内核中的签名。希望利用<a href="verified-boot.html">验证启动</a>功能的每个制造商都应该有验证内核完整性的方法。内核经过验证后,可以在块设备装载时对其进行检查和验证。</p>
+
+<p>验证块设备的一种方法是直接对其内容进行哈希处理,然后将其与存储的值进行比较。不过,尝试验证整个块设备可能会需要较长的时间,并且会消耗设备的大量电量。设备将需要很长时间来启动,从而在可供使用之前便消耗了大量电量。</p>
+
+<p>而 dm-verity 只有在各个块被访问时才会对其进行单独验证。将块读入内存时,会以并行方式对其进行哈希处理。然后,会从第一级开始逐级验证整个哈希树的哈希。由于读取块是一项耗时又耗电的操作,因此这种块级验证带来的延时相对而言就有些微不足道了。</p>
+
+<p>如果验证失败,设备会生成 I/O 错误,指明无法读取相应块。设备看起来与文件系统损坏时一样,也与预期相同。</p>
+
+<p>应用可以选择在没有结果数据的情况下继续运行,例如,当这些结果并不是应用执行主要功能所必需的数据时。不过,如果应用在没有这些数据的情况下无法继续运行,则会失败。</p>
+
+<h2 id="implementation">实现</h2>
+
+<h3 id="summary">摘要</h3>
+
+<ol>
+<li>生成 EXT4 系统映像。</li>
+<li>为该映像<a href="#hash-tree">生成哈希树</a>。</li>
+<li>为该哈希树<a href="#mapping-table">构建 dm-verity 表</a>。</li>
+<li><a href="#signing">为该 dm-verity 表签名</a>以生成表签名。</li>
+<li>将表签名和 dm-verity 表<a href="#metadata">绑定</a>到 Verity 元数据。</li>
+<li>将系统映像、Verity 元数据和哈希树组合起来。</li>
+</ol>
+
+<p>如需关于哈希树和 dm-verity 表的详细说明,请参阅 <a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot">Chromium 项目 - 验证启动</a>。</p>
+
+<h3 id="hash-tree">生成哈希树</h3>
+
+<p>如<a href="#introduction">简介</a>中所述,哈希树是 dm-verity 不可或缺的一部分。<a href="https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity">cryptsetup</a> 工具将为您生成哈希树。或者,也可以使用下面定义的兼容方式:</p>
+
+<pre>
+&lt;your block device name&gt; &lt;your block device name&gt; &lt;block size&gt; &lt;block size&gt; &lt;image size in blocks&gt; &lt;image size in blocks + 8&gt; &lt;root hash&gt; &lt;salt&gt;
+</pre>
+
+<p>为了形成哈希,该工具会将系统映像在第 0 层拆分成 4k 大小的块,并为每个块分配一个 SHA256 哈希。然后,通过仅将这些 SHA256 哈希组合成 4k 大小的块来形成第 1 层,从而产生一个小得多的映像。接下来再使用第 1 层的 SHA256 哈希以相同的方式形成第 2 层。</p>
+
+<p>直到前一层的 SHA256 哈希可以放到一个块中,该过程就完成了。获得该块的 SHA256 哈希后,就相当于获得了树的根哈希。</p>
+
+<p>哈希树的大小(以及相应的磁盘空间使用量)会因已验证分区的大小而异。在实际中,哈希树一般都比较小,通常不到 30 MB。</p>
+
+<p>如果某个层中的某个块无法由前一层的哈希正好填满,您应在其中填充 0 来获得所需的 4k 大小。这样一来,您就知道哈希树没有被移除,而是填入了空白数据。</p>
+
+<p>为了生成哈希树,需要将第 2 层哈希组合到第 1 层哈希的上方,将第 3 层哈希组合到第 2 层哈希的上方,依次类推。然后将所有这些数据写入到磁盘中。请注意,这种方式不会引用根哈希的第 0 层。</p>
+
+<p>总而言之,构建哈希树的一般算法如下:</p>
+
+<ol>
+<li>选择一个随机盐(十六进制编码)。</li>
+<li>将系统映像拆分成 4k 大小的块。</li>
+<li>获取每个块的加盐 SHA256 哈希。</li>
+<li>组合这些哈希以形成层。</li>
+<li>在层中填充 0,直至达到 4k 块的边界。</li>
+<li>将层组合到哈希树中。</li>
+<li>重复第 2-6 步(使用前一层作为下一层的来源),直到最后只有一个哈希。</li>
+</ol>
+
+<p>该过程的结果是一个哈希,也就是根哈希。在构建 dm-verity 映射表时会用到该哈希和您选择的盐。</p>
+
+<h3 id="mapping-table">构建 dm-verity 映射表</h3>
+
+<p>构建 dm-verity 映射表,该映射表会标明内核的块设备(或目标)以及哈希树的位置(是同一个值)。在生成 <code>fstab</code> 和设备启动时会用到此映射。该映射表还会标明块的大小和 hash_start,或者哈希大小的块的偏移量(第 0 层的长度)。</p>
+
+<p>如需关于 Verity 目标映射表字段的详细说明,请参阅 <a href="https://code.google.com/p/cryptsetup/wiki/DMVerity">cryptsetup</a>。</p>
+
+<h3 id="signing">为 dm-verity 表签名</h3>
+
+<p>为 dm-verity 表签名以生成表签名。在验证分区时,会首先验证表签名。该验证是对照位于启动映像上某个固定位置的密钥来完成的。密钥通常包含在制造商的编译系统中,以便自动添加到设备上的固定位置。</p>
+
+<p>要使用这种签名和密钥的组合来验证分区,请执行以下操作:</p>
+
+<ol>
+<li>将一个格式与 libmincrypt 兼容的 RSA-2048 密钥添加到 /boot 分区的 /verity_key 中。确定用于验证哈希树的密钥所在的位置。</li>
+<li>在相关条目的 fstab 中,将“verify”添加到 fs_mgr 标记。</li>
+</ol>
+
+<h3 id="metadata">将表签名绑定到元数据</h3>
+
+<p>将表签名和 dm-verity 表绑定到 Verity 元数据。为整个元数据块添加版本号,以便它可以进行扩展,例如添加第二种签名或更改某些顺序。</p>
+
+<p>一个魔数(作为一个健全性检查项目)会与每组表元数据相关联,以协助标识表。由于长度包含在 EXT4 系统映像标头中,因此这为您提供了一种在不知道数据本身内容的情况下搜索元数据的方式。</p>
+
+<p>这可确保您未选择验证未验证的分区。如果是这样,缺少此魔数将会导致验证流程中断。该数字类似于:<br />0xb001b001</p>
+
+<p>十六进制的字节值为:</p>
+
+<ul>
+<li>第一字节 = b0</li>
+<li>第二字节 = 01</li>
+<li>第三字节 = b0</li>
+<li>第四字节 = 01</li>
+</ul>
+
+<p>下图展示了 Verity 元数据的细分:</p>
+
+<pre>&lt;magic number&gt;|&lt;version&gt;|&lt;signature&gt;|&lt;table length&gt;|&lt;table&gt;|&lt;padding&gt;
+\-------------------------------------------------------------------/
+\----------------------------------------------------------/ |
+ | |
+ | 32K
+ block content
+</pre>
+
+<p>下表介绍了这些元数据字段。</p>
+
+<p class="table-caption" id="table1">
+ <strong>表 1.</strong> Verity 元数据字段</p>
+
+<table>
+<tbody><tr>
+<th>字段</th>
+<th>用途</th>
+<th>大小</th>
+<th>值</th>
+</tr>
+<tr>
+<td>魔数</td>
+<td>供 fs_mgr 用作一个健全性检查项目</td>
+<td>4 个字节</td>
+<td>0xb001b001</td>
+</tr>
+<tr>
+<td>版本</td>
+<td>用于为元数据块添加版本号</td>
+<td>4 个字节</td>
+<td>目前为 0</td>
+</tr>
+<tr>
+<td>签名</td>
+<td>PKCS1.5 填充形式的表签名</td>
+<td>256 个字节</td>
+<td></td>
+</tr>
+<tr>
+<td>表长度</td>
+<td>dm-verity 表的长度(以字节数计)</td>
+<td>4 个字节</td>
+<td></td>
+</tr>
+<tr>
+<td>表</td>
+<td>上文介绍的 dm-verity 表</td>
+<td>字节数与表长度相同</td>
+<td></td>
+</tr>
+<tr>
+<td>填充</td>
+<td>此结构会通过填充 0 达到 32k 长度</td>
+<td></td>
+<td>0</td>
+</tr>
+</tbody></table>
+
+<h3 id="optimize">优化 dm-verity</h3>
+
+<p>为了充分发挥 dm-verity 的最佳性能,您应该:</p>
+ <ul>
+ <li>在内核中开启 NEON SHA-2(如果是 ARMv7)或 SHA-2 扩展程序(如果是 ARMv8)。
+ </li><li>使用不同的预读设置和 prefetch_cluster 设置进行实验,找出适合您设备的最佳配置。
+ </li></ul>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/verifiedboot/index.html b/zh-cn/security/verifiedboot/index.html
new file mode 100644
index 00000000..4b01edf6
--- /dev/null
+++ b/zh-cn/security/verifiedboot/index.html
@@ -0,0 +1,59 @@
+<html devsite><head>
+ <title>验证启动</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>Android 4.4 及更高版本支持通过可选的 device-mapper-verity (dm-verity) 内核功能进行的验证启动,以便对块设备进行透明的完整性检查。dm-verity 有助于阻止可以持续保有 Root 权限并入侵设备的持续性 Rootkit。验证启动功能有助于 Android 用户在启动设备时确定设备状态与上次使用时是否相同。</p>
+
+<p>更为狡猾且具有 Root 权限的恶意软件可以躲开检测程序的检测,并以其他方式掩蔽自己。可以获取 Root 权限的软件就能够做到这一点,因为它通常比检测程序的权限更高,从而能够“欺骗”检测程序。</p>
+
+<p>通过 dm-verity 功能,您可以查看块设备(文件系统的底部存储层),并确定它是否与预期配置一致。该功能是利用加密哈希树做到这一点的。对于每个块(通常为 4k),都有一个 SHA256 哈希。</p>
+
+<p>由于哈希值存储在页面树中,因此顶级“根”哈希必须可信,才能验证树的其余部分。能够修改任何块相当于能够破坏加密哈希。下图描绘了此结构。</p>
+
+<img src="../images/dm-verity-hash-table.png" alt="dm-verity-hash-table" id="figure1"/>
+<p class="img-caption">
+ <strong>图 1.</strong> dm-verity 哈希表</p>
+
+<p>启动分区中包含一个公钥,该公钥必须已由原始设备制造商 (OEM) 在外部进行验证。该密钥用于验证相应哈希的签名,并用于确认设备的系统分区是否受到保护且未被更改。</p>
+
+<h2 id="prerequisites">前提条件</h2>
+
+<h3 id="verified-boot">建立验证启动流程</h3>
+<p>为了大幅降低遭到入侵的风险,请使用烧录到设备上的密钥来验证内核。如需详细信息,请参阅<a href="verified-boot.html">验证启动</a>。</p>
+
+<h3 id="block-otas">切换到面向块的 OTA</h3>
+<p>要为设备启用 dm-verity,您必须使用基于块的无线下载 (OTA) 更新来确保所有设备均使用相同的系统分区。如需详细信息,请参阅<a href="/devices/tech/ota/block.html">基于块的 OTA</a>。</p>
+
+<h3 id="config-dm-verity">配置 dm-verity</h3>
+
+<p>在切换到面向块的 OTA 后,纳入最新的 Android 内核或使用现成的上游内核,然后通过添加相关配置选项 <code>CONFIG_DM_VERITY</code> 来启用 dm-verity 支持。</p>
+
+<p>如果使用 Android 内核,dm-verity 会在该内核编译后启用。如需详细信息,请参阅<a href="dm-verity.html">实现 dm-verity</a>。</p>
+
+<h2 id="supporting-docs">支持文档</h2>
+<p><a href="verified-boot.html">验证启动</a><br />
+<a href="/devices/tech/ota/block.html">基于块的 OTA</a><br />
+<a href="dm-verity.html">实现 dm-verity</a><br />
+<a href="https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity">cryptsetup - dm-verity:device-mapper 块完整性检查目标</a><br />
+<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot">Chromium 项目 - 验证启动</a><br />
+<a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt">Linux 内核文档:verity.txt</a></p>
+
+</body></html> \ No newline at end of file
diff --git a/zh-cn/security/verifiedboot/verified-boot.html b/zh-cn/security/verifiedboot/verified-boot.html
new file mode 100644
index 00000000..4068f771
--- /dev/null
+++ b/zh-cn/security/verifiedboot/verified-boot.html
@@ -0,0 +1,361 @@
+<html devsite><head>
+ <title>验证启动</title>
+ <meta name="project_path" value="/_project.yaml"/>
+ <meta name="book_path" value="/_book.yaml"/>
+ </head>
+ <body>
+ <!--
+ Copyright 2017 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<p>验证启动功能旨在保证设备软件(从硬件信任根直到系统分区)的完整性。在启动过程中,无论是在每个阶段,都会在进入下一个阶段之前先验证下一个阶段的完整性和真实性。</p>
+
+<p>当用户对软件进行了不应进行的更改时,可以使用该功能向他们发出警告,比如当用户获得一台二手设备后告知他们软件经受了不应进行的更改。此外,该功能还可以提供进行远程认证时使用的其他设备完整性信号。该功能再加上加密功能以及可信执行环境 (TEE) 信任根绑定功能,三者共同为用户数据添加了另一道防范恶意系统软件的保护屏障。</p>
+
+<p>如果在任意阶段验证失败,用户都会收到醒目的通知。</p>
+
+<h2 id="glossary">词汇表</h2>
+
+<table>
+ <colgroup><col width="15%" />
+ <col width="85%" />
+ </colgroup><tbody><tr>
+ <th>术语</th>
+ <th>定义</th>
+ </tr>
+ <tr>
+ <td>启动状态</td>
+ <td>设备的启动状态用于说明设备启动后向最终用户提供的保护级别。启动状态为“绿色”、“黄色”、“橙色”和“红色”。</td>
+ </tr>
+ <tr>
+ <td>设备状态</td>
+ <td>设备状态用于指明能够以多大的自由度将软件刷写到设备上。设备状态为“已锁定”和“已解锁”。</td>
+ </tr>
+ <tr>
+ <td>dm-verity</td>
+ <td>Linux 内核驱动程序,用于在分区运行时使用哈希树和已签名的元数据验证分区的完整性。</td>
+ </tr>
+ <tr>
+ <td>原始设备制造商 (OEM) 密钥</td>
+ <td>原始设备制造商 (OEM) 密钥是一个固定不变的防篡改密钥,可供引导加载程序使用(在验证启动映像时必须使用该密钥)。</td>
+ </tr>
+</tbody></table>
+
+<h2 id="overview">概述</h2>
+
+<p>除了设备状态(在设备中已存在,用于控制引导加载程序是否允许刷写新软件)外,验证启动功能还引入了启动状态的概念,以便指明设备完整性状态。</p>
+
+<h3 id="classes">级别</h3>
+
+<p>验证启动有两个实现级别。根据设备在多大程度上实现此规范,这两个级别的定义如下:</p>
+
+<p><strong>A 级</strong>会实现具有完整信任链(直到已验证的分区)的验证启动。也就是说,这种级别的实现支持“已锁定”设备状态,以及“绿色”和“红色”启动状态。</p>
+
+<p><strong>B 级</strong>会实现 A 级实现的内容,并且还支持“已解锁”设备状态和“橙色”启动状态。</p>
+
+<h3 id="verification_keys">验证密钥</h3>
+
+<p>引导加载程序的完整性始终都是使用硬件信任根进行验证。在验证启动分区和恢复分区时,引导加载程序可以使用原始设备制造商 (OEM) 密钥(该密钥是固定不变的)。它始终会先尝试使用原始设备制造商 (OEM) 密钥验证启动分区,并且仅当此项验证失败时,才会尝试使用其他可能的密钥进行验证。</p>
+
+<p>在 B 级实现中,当设备处于“已解锁”状态时,用户可以刷写使用其他密钥签名的软件。如果设备随后进入“已锁定”状态,并且使用原始设备制造商 (OEM) 密钥进行的验证失败了,引导加载程序会尝试使用分区签名中嵌入的证书进行验证。不过,在使用通过原始设备制造商 (OEM) 密钥以外的任何其他凭据签名的分区时,会收到通知或警告,如下文所述。</p>
+
+<h3 id="boot_state">启动状态</h3>
+
+<p>在每次尝试启动时,已验证的设备最终都将启动到以下 4 种状态之一:</p>
+
+<ul>
+ <li>绿色:表示实现了从引导加载程序到已验证分区的完整信任链,其中包括引导加载程序、启动分区和所有已验证的分区。
+
+ </li><li>黄色:表示已使用嵌入的证书验证启动分区,并且签名有效。在允许启动过程继续之前,引导加载程序会显示一条警告以及公钥的指纹。
+
+ </li><li>橙色:表示可以随意修改设备。设备完整性由用户进行带外验证。在允许启动过程继续之前,引导加载程序会向用户显示一条警告。
+
+ </li><li>红色:表示设备验证失败了。引导加载程序会显示一条警告并停止启动过程。
+</li></ul>
+
+<p>此外,还会以完全相同的方式验证恢复分区。</p>
+
+<h3 id="device_state">设备状态</h3>
+
+<p>可能的设备状态以及它们与 4 种验证启动状态的关系如下:</p>
+<ol>
+ <li>已锁定:表示无法刷写设备。在每次尝试启动时,“已锁定”设备都会启动到“绿色”、“黄色”或“红色”状态。
+
+ </li><li>已解锁:表示可以随意刷写设备,不需要进行验证。“已解锁”设备始终会启动到“橙色”启动状态。
+</li></ol>
+
+<img src="../images/verified_boot.png" alt="验证启动流程" id="figure1"/>
+<p class="img-caption"><strong>图 1.</strong> 验证启动流程</p>
+
+<h2 id="detailed_design">详细设计</h2>
+
+<p>要实现完整的信任链,需要启动分区(负责装载更多分区)上的引导加载程序和软件的支持。验证元数据也会附加到系统分区,并附加到应接受完整性验证的所有其他分区。</p>
+
+<h3 id="bootloader_requirements">引导加载程序要求</h3>
+
+<p>引导加载程序是设备状态的监护者,负责初始化 TEE 以及绑定其信任根。</p>
+
+<p>最重要的是,引导加载程序会在将执行工作移交给内核之前先验证启动分区和/或恢复分区的完整性,并会显示<a href="#boot_state">启动状态</a>部分中指定的警告。</p>
+
+<h4 id="changing_device_state">更改设备状态</h4>
+
+<p>要更改设备状态,需要使用 <code>fastboot flashing [unlock |
+lock]</code> 命令。为了保护用户数据,只要设备状态发生变化,<strong>都</strong>会先清除数据分区中的数据,并会在删除数据之前要求用户确认。</p>
+
+<ol>
+ <li>用户购买二手开发设备后,应该将设备状态从“已解锁”改为“已锁定”。锁定设备后,只要没有警告,用户应该就会确信设备处于设备制造商开发的状态。
+
+ </li><li>如果开发者希望停用设备上的验证功能,应该将设备状态从“已锁定”改为“已解锁”。
+</li></ol>
+
+<p>下表列出了用于更改设备状态的 <code>fastboot</code> 命令:</p>
+
+<table>
+ <colgroup><col width="25%" />
+ <col width="75%" />
+ </colgroup><tbody><tr>
+ <th><code>fastboot</code> 命令</th>
+ <th>说明</th>
+ </tr>
+ <tr>
+ <td><code>flashing lock</code></td>
+ <td>
+ <ul>
+ <li>先提示用户确认,在用户确认之后清除数据</li><li>清除引导加载程序可读取的防写位,指明设备已解锁</li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td><code>flashing unlock</code></td>
+ <td>
+ <ul>
+ <li>如果用户尚未启用解锁设备设置,则中止解锁</li><li>先提示用户确认,在用户确认之后清除数据</li><li>设置引导加载程序可读取的防写位,指明设备已解锁</li></ul>
+ </td>
+ </tr>
+</tbody></table>
+
+<p>在更改分区内容时,引导加载程序会检查通过上述命令设置的位,如下表所述:</p>
+
+<table>
+ <colgroup><col width="25%" />
+ <col width="75%" />
+ </colgroup><tbody><tr>
+ <th><code>fastboot</code> 命令</th>
+ <th>说明</th>
+ </tr>
+ <tr>
+ <td><code>flash &lt;partition&gt;</code></td>
+ <td>如果通过 <code>flashing unlock</code> 设置的位已设置,则刷写相应分区。否则,不允许进行刷写操作。
+ </td>
+ </tr>
+</tbody></table>
+
+<p>对于可用于更改分区内容的所有 <code>fastboot</code> 命令,都应执行同样的检查。</p>
+
+<p class="note"><strong>注意</strong>:B 级实现支持更改设备状态。</p>
+
+<h4 id="binding_tee_root_of_trust">绑定 TEE 信任根</h4>
+
+<p>如果 TEE 可用,那么在启动分区/恢复分区验证和 TEE 初始化完成后,引导加载程序会将以下信息传递给 TEE,以便绑定 Keymaster 信任根:</p>
+
+<ol>
+ <li>为启动分区签名时使用的公钥</li><li>当前设备状态(“已锁定”或“已解锁”)</li></ol>
+
+<p>这会更改 TEE 派生的密钥。以磁盘加密为例,当设备状态发生变化时,这可以防止用户数据被解密。</p>
+
+<p class="note"><strong>注意</strong>:这意味着,如果系统软件或设备的状态发生变化,已加密的用户数据将无法再访问,因为 TEE 将尝试使用其他密钥来解密数据。</p>
+
+<h4 id="initializing-attestation">初始化认证</h4>
+<p>与绑定信任根时类似,如果 TEE 可用,引导加载程序会将以下信息传递给 TEE,以便初始化认证:</p>
+<ol>
+<li>当前启动状态(绿色、黄色、橙色)</li><li>操作系统版本</li><li>操作系统安全补丁程序级别</li></ol>
+<h4 id="booting_into_recovery">启动到恢复模式</h4>
+
+<p>应按照与验证启动分区时完全相同的方式验证恢复分区。</p>
+
+<h4 id="comm_boot_state">传达启动状态</h4>
+
+<p>系统软件需要能够确定之前各阶段的验证状态。引导加载程序会以内核命令行参数的形式(或通过 <code>firmware/android/verifiedbootstate</code> 下的设备树)指定当前启动状态,如下表所述:</p>
+
+<table>
+ <tbody><tr>
+ <th>内核命令行参数</th>
+ <th>说明</th>
+ </tr>
+ <tr>
+ <td><code>androidboot.verifiedbootstate=green</code></td>
+ <td>设备已启动到“绿色”启动状态。<br />已使用原始设备制造商 (OEM) 密钥验证启动分区,并且该密钥有效。</td>
+ </tr>
+ <tr>
+ <td><code>androidboot.verifiedbootstate=yellow</code></td>
+ <td>设备已启动到“黄色”启动状态。<br />已使用签名中嵌入的证书验证启动分区,并且该签名有效。</td>
+ </tr>
+ <tr>
+ <td><code>androidboot.verifiedbootstate=orange</code></td>
+ <td>设备已启动到“橙色”启动状态。<br />设备已解锁,并且未执行任何验证。</td>
+ </tr>
+</tbody></table>
+<p class="note"><strong>注意</strong>:处于“红色”启动状态时,设备无法启动到由内核执行相关工作,因此内核命令行中绝不会包含参数 <code>androidboot.verifiedbootstate=red</code>。</p>
+
+<h3 id="boot_partition">启动分区</h3>
+
+<p>当执行工作移交给启动分区后,其中的软件将负责设置其他分区的验证。由于系统分区比较大,因此通常不能采用与前面部分类似的方式对其进行验证,而是应改为在该分区被访问时使用 dm-verity 内核驱动程序或类似解决方案对其进行验证。</p>
+
+<p>如果使用 dm-verity 验证大型分区,需要先验证附加到每个已验证分区的 Verity 元数据的签名,然后再装载相应分区并为其设置 dm-verity。</p>
+
+<h4 id="managing_dm-verity">管理 dm-verity</h4>
+
+<p>在内核中作为设备映射器目标实现后,dm-verity 会在分区之上添加一个层,并根据在设置过程中传递给它的哈希树来验证每个读取块。如果 dm-verity 遇到未能通过验证的块,则会将其设为无法供用户空间访问。</p>
+
+<p>在启动过程中装载分区时,如果已在设备的 fstab 中为某个分区指定了 <code>verify</code> fs_mgr 标记,fs_mgr 会为该分区设置 dm-verity。Verity 元数据签名是根据 <code>/verity_key</code> 中的公钥进行验证的。</p>
+
+<h4 id="recovering_from_dm-verity_errors">从 dm-verity 错误恢复</h4>
+
+<p>由于系统分区比启动分区大得多,因此发生验证错误的可能性也更高。具体来说就是,出现意外磁盘损坏的可能性会更高。出现意外磁盘损坏会导致验证失败,并且如果分区中有关键块无法再访问,这还可能会导致其他功能设备无法使用。可以结合使用前向纠错与 dm-verity 来降低这种风险。建议提供这种备用恢复路径,不过这会导致元数据大小增加。</p>
+
+<p>默认情况下,dm-verity 会被配置为以“重启”模式运行。在该模式下,如果检测到损坏的块,dm-verity 会立即重启设备。这样一来,在设备损坏时就可以安全地向用户发出警告,或者回退到设备特定恢复分区(如果有)。
+</p>
+
+<p>如果设备启动时存在已知损坏,为了让用户仍可以访问自己的数据,dm-verity 会切换到 I/O 错误 (EIO) 模式。在 EIO 模式下,对于访问损坏的块的所有读取操作,dm-verity 都会返回 I/O 错误,但允许设备继续运行。要跟踪当前模式,需要持续存储 dm-verity 状态。可以通过 fs_mgr 或引导加载程序对该状态进行管理:</p>
+
+<ol>
+ <li>要在 fs_mgr 中管理 dm-verity 状态,需要为 <code>verify</code> 标记指定一个附加参数,以便让 fs_mgr 知道 dm-verity 状态要存储在哪里。例如,要将该状态存储在元数据分区中,需要指定 <code>verify=/path/to/metadata</code>。
+ <p class="note"><strong>注意</strong>:在首次检测到损坏之后,fs_mgr 会将 dm-verity 切换到 EIO 模式,并且会在任何已验证分区的元数据签名发生变化后将模式重置为“重启”。</p>
+ </li>
+ <li>要在引导加载程序中管理 dm-verity 状态,需要在 <code>androidboot.veritymode</code> 命令行参数中将当前模式传递到内核,如下所示:<table>
+ <tbody><tr>
+ <th>内核命令行参数</th>
+ <th>说明</th>
+ </tr>
+ <tr>
+ <td><code>androidboot.veritymode=enforcing</code></td>
+ <td>将 dm-verity 设置为默认的“重启”模式。</td>
+ </tr>
+ <tr>
+ <td><code>androidboot.veritymode=eio</code></td>
+ <td>将 dm-verity 设置为 EIO 模式。</td>
+ </tr>
+ </tbody></table>
+
+ <p class="note">
+ <strong>注意</strong>:要在引导加载程序中管理状态,还需要内核在设备因 dm-verity 而重启时正确设置重启原因。检测到损坏后,如果有任何已验证分区发生变化,引导加载程序都应切换回“重启”模式。</p>
+ </li>
+</ol>
+
+<p>如果出于任何原因未以“重启”模式启动 dm-verity,或如果无法验证 Verity 元数据,系统会向用户显示一条警告(如果允许设备启动),与在启动到“红色”启动状态之前显示的警告类似。必须获得用户同意,设备才能继续以 EIO 模式启动。如果在 30 秒内未获得用户同意,设备将会关机。
+</p>
+
+<p class="note">
+<strong>注意</strong>:为了防止未验证的数据泄露到用户空间,dm-verity 绝不会以记录模式启动。
+</p>
+
+<h3 id="verified_partition">已验证的分区</h3>
+
+<p>在已验证的设备中,系统分区一定已通过验证。不过,所有其他只读分区也应设为已验证。在已验证的设备中,所有包含可执行代码的只读分区都已通过验证,比如供应商分区和原始设备制造商 (OEM) 分区(如果存在)。</p>
+
+<p>要验证某个分区,需要为其附加已签名的 Verity 元数据。元数据由分区内容的哈希树以及一个 Verity 表组成(Verity 表中包含已签名的参数和哈希树的根)。如果在为分区设置 dm-verity 时未提供这些信息或提供的信息无效,设备将不会启动。</p>
+
+<h2 id="implementation_details">实现详细信息</h2>
+
+<h3 id="key_types_and_sizes">密钥类型和大小</h3>
+
+<p>AOSP 中使用的原始设备制造商 (OEM) 密钥是模数为 2048 位或更高且公开指数为 65537 (F4) 的 RSA 密钥,符合 CDD 中关于密钥安全系数不能低于此类密钥的要求。</p>
+
+<p>请注意,原始设备制造商 (OEM) 密钥遭到入侵后,通常无法再使用,因此务必要对该密钥采取保护措施,最好是使用硬件安全模块 (HSM) 或类似解决方案。另外,建议为每种类型的设备使用不同的密钥。</p>
+
+<h3 id="signature_format">签名格式</h3>
+
+<p>Android 可验证启动映像上的签名是一条经过 ASN.1 DER 编码的消息,可以使用与 <a href="https://android.googlesource.com/platform/bootable/recovery/+/f4a6ab27b335b69fbc419a9c1ef263004b561265/asn1_decoder.cpp">platform/bootable/recovery/asn1_decoder.cpp</a> 中提供的解码器类似的解码器对该消息进行解析<br />消息格式如下:</p>
+
+<pre>
+AndroidVerifiedBootSignature DEFINITIONS ::=
+ BEGIN
+ FormatVersion ::= INTEGER
+ Certificate ::= Certificate
+ AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL
+ }
+ AuthenticatedAttributes ::= SEQUENCE {
+ target CHARACTER STRING,
+ length INTEGER
+ }
+
+ Signature ::= OCTET STRING
+ END
+</pre>
+
+<p><code>Certificate</code> 字段是一个完整的 X.509 证书(您可以在 <a href="http://tools.ietf.org/html/rfc5280#section-4.1.1.2">RFC5280</a> 第 4.1 部分中找到它的定义),其中包含用于签名的公钥。当设备处于“已锁定”状态时,引导加载程序会先使用原始设备制造商 (OEM) 密钥进行验证;如果改用嵌入的证书进行验证,设备将只能启动到“黄色”或“红色”状态。</p>
+
+<p>除了 <code>AuthenticatedAttributes</code> 字段外,其余结构与 <a href="http://tools.ietf.org/html/rfc5280#section-4.1.1.2">RFC5280</a> 第 4.1.1.2 部分和第 4.1.1.3 部分中定义的结构类似。该字段中包含要验证的映像的长度(整数形式)以及该映像所在的分区(启动分区、恢复分区等)。</p>
+
+<h3 id="signing_and_verifying_an_image">为映像签名和验证映像</h3>
+
+<p><strong>生成已签名的映像:</strong></p>
+<ol>
+ <li>生成未签名的映像。
+ </li><li>为映像填充 0,以便补齐到下一页的大小边界(如果已对齐,则忽略此步骤)。
+ </li><li>根据填充后的映像和所需的目标分区填写上述 <code>AuthenticatedAttributes</code> 部分的字段。
+ </li><li>将上述 <code>AuthenticatedAttributes</code> 结构附加到映像。
+ </li><li>为映像签名。
+</li></ol>
+
+<p><strong>验证映像:</strong></p>
+<ol>
+ <li>确定要加载的映像的大小,包括内边距(例如,通过读取标头来确定)。
+ </li><li>读取位于上述偏移量处的签名。
+ </li><li>验证 <code>AuthenticatedAttributes</code> 字段的内容。如果这些值无效,则视为签名验证错误。
+ </li><li>验证映像和 <code>AuthenticatedAttributes</code> 部分。
+</li></ol>
+
+<h3 id="user_experience">用户体验</h3>
+
+<p>设备处于“绿色”启动状态时,除了正常设备启动所需的用户互动外,用户应该不会看到任何其他用户互动。设备处于“橙色”和“黄色”启动状态时,用户会看到一条至少持续 5 秒的警告。如果用户在这段时间内与设备互动,该警告持续显示的时间至少会延长 30 秒,或者直到用户关闭该警告。设备处于“红色”启动状态时,该警告会显示至少 30 秒,之后设备将会关机。</p>
+
+<p>下表显示了其他状态下的用户互动屏幕示例:</p>
+
+<table>
+ <tbody><tr>
+ <th>设备状态</th>
+ <th>用户体验示例</th>
+ <th> </th>
+ </tr>
+ <tr>
+ <td>黄色</td>
+ <td><img src="../images/boot_yellow1.png" alt="“黄色”设备状态 1" id="figure2"/>
+ <p class="img-caption"><strong>图 2.</strong> 用户互动之前</p>
+ </td>
+ <td><img src="../images/boot_yellow2.png" alt="“黄色”设备状态 2" id="figure3"/>
+ <p class="img-caption"><strong>图 3.</strong> 用户互动之后</p>
+ </td>
+ </tr>
+ <tr>
+ <td>橙色</td>
+ <td><img src="../images/boot_orange.png" alt="“橙色”设备状态" id="figure4"/>
+ <p class="img-caption"><strong>图 4.</strong> 提示设备已解锁且无法验证的警告。</p>
+ </td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>红色</td>
+ <td><img src="../images/boot_red1.png" alt="“红色”设备状态" id="figure5"/>
+ <p class="img-caption"><strong>图 5.</strong> 提示验证启动失败的警告</p>
+ </td>
+ <td><img src="../images/boot_red2.png" alt="“红色”设备状态" id="figure6"/>
+ <p class="img-caption"><strong>图 6.</strong> 提示启动到 EIO 模式的警告</p>
+ </td>
+ </tr>
+</tbody></table>
+
+</body></html> \ No newline at end of file