1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
|
<html devsite>
<head>
<title>System Security Best Practices</title>
<meta name="project_path" value="/_project.yaml" />
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
<!--
Copyright 2018 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
//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>This section contains recommendations for ensuring the security of the core
Android operating system and devices.
</p>
<h2 id="biometric-authentication">Biometric authentication</h2>
<p>Acquire, store, and process <a href="/security/biometric">biometric data</a>
for user authentication carefully. You should:
</p>
<ul>
<li>Mandate the primary authentication method before using any other form of
authentication (including biometrics).</li>
<li>Require an explicit confirmation to indicate intent when using passive
biometric modalities, such as facial recognition, for transactions (for
example, payments) that involve authentication-bound keys.</li>
<li>Require the primary authentication method every 72 hours.</li>
<li>Use a fully secure pipeline for all biometric data and handling.</li>
<li>Never send biometric data (including raw sensor measurements and derived
features) off-device. If possible, keep this data in a secure isolated
environment, such as the <a href="/security/trusty">Trusted Execution
Environment (TEE)</a> or Secure Element.</li>
</ul>
<p>Devices with biometrics should support the
<a href="https://developer.android.com/preview/features/security#fingerprint-auth"
class="external">BiometricPrompt API</a>, which offers a common and
consistent interface for app developers to take advantage of biometrics-based
authentication in their apps. Only
<a href="/security/biometric/#strong-weak-unlocks" class="external">strong
biometrics</a> can integrate with <code>BiometricPrompt</code> and
integrations must follow <a href="/compatibility/cdd">Android Compatibility
Definition Document</a> (CDD) guidelines.</p>
<p>For more biometric guidelines, see
<a href="/security/biometric#hal-implementation">Biometric HAL implementation
guidelines</a>.</p>
<h2 id="selinux">SELinux</h2>
<p>SELinux provides the definition and enforcement of much of Android's
security model. Correctly using SELinux is critical to the security of
Android devices and can help mitigate the impact of security vulnerabilities.
All Android devices should implement a
<a href="/security/selinux/device-policy#granting_the_dac_override_capability">robust
SELinux policy</a> for this reason.</p>
<ul>
<li>Implement a least privilege policy.</li>
<li>Avoid granting <code>CAP_DAC_OVERRIDE</code>, <code>CAP_SYS_ADMIN</code>,
and <code>CAP_NET_ADMIN</code> permissions.</li>
<li>Don't log system data to the SD card.</li>
<li>Use provided types for driver access, such as <code>gpu_device</code>,
<code>audio_device</code>, etc.</li>
<li>Use meaningful names for processes, files, and SELinux types.
<ul>
<li>Ensure default labels are not used and access is not granted to them.</li>
</ul>
</li>
<li>Device-specific policy should account for 5–10% of the overall policy
running on a device. Customizations in the 20%+ range almost certainly
contain over-privileged domains and dead policy. Unnecessarily large policy
wastes memory, wastes disk space by necessitating a larger boot image,
and negatively affects runtime policy lookup times.
</li>
</ul>
<h3 id="dynamic-loading-selinux-policy">Dynamic loading of SELinux policy</h3>
<p>Do not dynamically load SELinux policy on Android devices. Doing so can
result in issues, such as:</p>
<ul>
<li>Preventing the acceptance of critical security patches.</li>
<li>Exposing the ability to root a device through reloading of policies.</li>
<li>Exposing a vector for man-in-the-middle attacks against the policy
updater.</li>
<li>Resulting in bricked devices due to errors with policy updates.</li>
</ul>
<h2 id="backdoors">Backdoors</h2>
<p>Android apps should not have any backdoors or ways to access the system or
data that bypass normal security mechanisms. This includes diagnostics,
debugging, development, or warranty repair special access gated by secrets
known to the developer. To prevent backdoors:</p>
<ul>
<li>Scan all third-party apps using an industry-recognized app vulnerability
scanning tool.</li>
<li>Perform code reviews of all code with sensitive access, including
third-party libraries.</li>
<li>Utilize Google Play Protect by uploading apps to Google Play for
scanning. You can upload apps for scanning without publishing to Google
Play.</li>
<li>Do not preload diagnostics- or repair-focused tools on release
builds. Only install these tools on-demand to solve specific issues.
Additionally, these tools must not operate upon or upload any
account-specific data.</li>
</ul>
<h2 id="development-tools">Development tools</h2>
<p>Development tools, such as debugging, testing, and diagnostic tools, can
often create unintended security gaps on your device by revealing how they
operate and the data that they collect. To make sure that development tools
don't make it into production builds:</p>
<ul>
<li>Develop a blacklist of in-house debug and testing tool hashes and scan
builds for these APKs prior to using the system image.</li>
<li>Scan all first-party apps using an industry-recognized app vulnerability
scanning tool.</li>
<li>Hire a third-party app security testing firm to evaluate all critical
on-device diagnostic apps before any major update, especially if the app is
developed by a third party.</li>
<li>Ensure that only the user can enable the tool, either verbally or over
chat, during a support session. Store artifacts of consent and disable the
tool after collecting the necessary diagnostic information.</li>
<li>Store this tool's record of use in a log accessible by the user in their
carrier account.</li>
<li>Ensure that any personally identifiable information (PII) or device
telemetry data collected by the tool is subject to anonymization, retention
and deletion practices relevant to the country. Only data relevant for the
support call should be collected. This data should be deleted after each
call.</li>
<li>Ensure that techniques that can be used for spyware, such as keystroke
logging, microphone usage, or camera usage, are not used without explicit
user consent. Apps utilizing these potentially privacy-invasive methods
should be very clearly disclosed along with a privacy policy that the user
must consent to. Apps like this should not be enabled without explicit
consent by the user.</li>
</ul>
<p>Here are some additional suggestions to refer to when implementing
disclosure and consent:</p>
<h3 id="in-app-disclosure">In-app disclosure</h3>
<ul>
<li>Display the normal usage of the app directly in-app. Do not require the
user to navigate into a menu or settings.</li>
<li>Describe the type of data being collected and explain how the data will
be used.</li>
<li>Ideally do not embed this information in a privacy policy or terms of
service. Do not include it with other disclosures unrelated to personal or
sensitive data collection.</li>
</ul>
<h3 id="request-consent">Request for consent</h3>
<ul>
<li>Consent must be affirmative. Don't consider navigation away from the
disclosure, including tapping away or pressing the back or home button,
as consent.</li>
<li>Present the consent dialog in a clear and unambiguous way.</li>
<li>Require affirmative user action, such as tap to accept or speak a
command, to accept.</li>
<li>Don't collect personal or sensitive data before obtaining
affirmative consent.</li>
<li>Don't use auto-dismissing or expiring messages.</li>
</ul>
<h2 id="embedded-functionality-in-aosp">Embedded functionality in AOSP</h2>
<p>Embedding additional functionality in AOSP can often have unexpected
behavior and consequences; proceed with caution.</p>
<ul>
<li>Ensure that the user is prompted if they want to use different default
apps (for example, search engine, web browser, launcher) and disclose
sending data off device.</li>
<li>Ensure that AOSP APKs are signed with the AOSP certificate.</li>
<li>Run regression tests and keep a change-log to determine whether the AOSP
APKs have had code added.</li>
</ul>
<h2 id="security-updates">Security updates</h2>
<p>Android devices should receive ongoing security support for at least two
years from launch. This includes receiving regular updates that address
known security vulnerabilities.</p>
<ul>
<li>Work with hardware partners, such as your SoC vendors, to put
appropriate support agreements in place for all components on your
Android device.</li>
<li>Ensure that security updates can be installed with minimal user
interaction to increase the likelihood of users accepting and installing
updates on their Android device. Implementing
<a href="/devices/tech/ota/ab/">Seamless System Updates</a> or an
equivalent security feature is strongly recommended.</li>
<li>Ensure that you understand the cumulative requirement of the Android
Security Patch Level (SPL) as declared in the
<a href="/security/bulletin/">Android Security Bulletin</a>. For example,
devices that use the 2018-02-01 security patch level must include all
issues associated with that security patch level, as well as fixes for
all issues reported in all previous security bulletins.</li>
</ul>
<h3 id="dynamic-kernel-updates">Dynamic kernel updates</h3>
<p>Do not dynamically modify critical system components. While there is some
research to suggest that dynamic kernel updates help protect against
emergency threats, the assessed cost currently outweighs the benefits.
Instead, create a robust OTA update method to quickly distribute
vulnerability protections.</p>
<h2 id="key-management">Key management</h2>
<p>Maintain good key management policies and practices to ensure the security
of signing keys.</p>
<ul>
<li>Do not share signing keys with external parties.</li>
<li>If a signing key is compromised, generate a new key and double sign all
apps going forward.</li>
<li>Store all keys in high-security module hardware or services requiring
multiple factors to access.</li>
</ul>
<h2 id="system-image-signing">System image signing</h2>
<p>The signature of the system image is critical to determine device integrity.</p>
<ul>
<li>Do not sign devices with a publicly known key.</li>
<li>Manage device-signing keys in a manner consistent with industry-standard
practices for handling sensitive keys, including a hardware security module
(HSM) that provides limited, auditable access.</li>
</ul>
<h2 id="unlockable-bootloaders">Unlockable bootloaders</h2>
<p>Many Android devices support unlocking, enabling the device owner to modify
the system partition or install a custom operating system. Common use
cases include installing a third-party system image and performing
systems-level development on the device. For example, to unlock the system
image on a Google Nexus or Pixel, a user can run <code>fastboot oem
unlock</code>, which displays this message:</p>
<aside class="caution">
<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 apps 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>
</aside>
<p>As a best practice, unlockable Android devices must securely erase all user
data prior to being unlocked. Failure to properly delete all data on
unlocking may allow a physically proximate attacker to gain unauthorized
access to confidential Android user data. To prevent the disclosure of user
data, a device that supports unlocking must implement it properly.</p>
<ul>
<li>After the user confirms the unlocking command, the device must start an
immediate data wipe. The <code>unlocked</code> flag must not be set until
after the secure deletion is complete.</li>
<li>If a secure deletion can't be completed, the device must stay in a locked
state.</li>
<li>If supported by the underlying block device,
<code>ioctl(BLKSECDISCARD)</code>or equivalent should be used. For
embedded MultiMediaCard (eMMC) devices, this means using a Secure Erase or
Secure Trim command. For eMMC 4.5 and later, this means using a normal Erase
or Trim followed by a Sanitize operation.</li>
<li>If <code>BLKSECDISCARD</code> is not supported by the underlying block
device, <code>ioctl(BLKDISCARD)</code> must be used instead. On eMMC
devices, this is a normal Trim operation.</li>
<li>If <code>BLKDISCARD</code> is not supported, overwriting the block
devices with all zeros is acceptable.</li>
<li>A user must have the option to require that user data be wiped
beofre flashing a partition. For example, Nexus devices use the
<code>fastboot oem lock</code> command to wipe user data.</li>
<li>A device may record, via eFuses or similar mechanism, whether a device
was unlocked and/or relocked. However, we strongly recommend that relocking
the bootloader with subsequent factory reset should restore full device
functionality.</li>
</ul>
<p>These requirements ensure that all data is destroyed upon the completion of
an unlock operation. Failure to implement these protections is considered a
<a href="/security/overview/updates-resources#severity">moderate level
security vulnerability</a>.</p>
<p>A device that is unlocked may be subsequently relocked using the
<code>fastboot oem lock</code> command. Locking the bootloader provides the
same protection of user data with the new custom OS as was available with the
original device manufacturer OS (e.g. user data will be wiped if the device
is unlocked again).</p>
<h2 id="device-pentesting">Device pentesting</h2>
<p>Devices should be reviewed by a competent pentester prior to shipment.
Pentesting should establish that the device followed security guidance
provided here as well as internal OEM security guidance.</p>
</body>
</html>
|
