`Case 2:17-cv-00514—JRG Document 221-6 Filed 02/21/19 Page 1 of 14 PageID #: 19218
`
`
`
`EXHIBIT E
`EXHIBIT E
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 2 of 14 PageID #: 19219
`
`EXHIBIT 4
`!Andrew Wolfe, Ph .D.
`
`2/1/19
`
`Reported by: Holly Thuman
`CSR 6834, RMR, CRR
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 3 of 14 PageID #: 19220
`
`Contents
`
`3
`
`Overview
`
`7
`
`Google Security
`Services for Android
`
`25
`
`Android Platform
`Security
`
`33
`
`Ecosystem Data
`
`43
`
`Noteworthy PHAs
`and Vulnerabilities
`
`48
`
`Appendix
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 4 of 14 PageID #: 19221
`
`Overview
`
`Google is committed to ensuring that Android 1s a safe ecosystem for
`users and developers We do that by investing in multiple layers of protection
`across a large and growing ecosystem. We provide security applications and
`services for Android, constantly strengthen the core Android platform, and
`foster an ecosystem rich with security innovation We also regularly measure
`the effectiveness of these efforts by collecting, analyzing, and sharing data
`about the security of the Android ecosystem. We consider transparency to be
`critical, so our second annual Android Security Year in Review is intended to
`share the progress we've made with regards to security in the last year, as well
`as provide our view of the state of security in the Android ecosystem.
`
`Google security services for Android
`
`To protect the Android ecosystem and its users. Google provides a complete
`set of endpoint security services that is included automatically as part of
`Google Mobile Services (GMS). These include both cloud-based services and
`on-device services delivered as Android applications, so users don't have
`to install additional security services to keep their devices safe. In 2015, these
`services protected over 1 billion devices, making Google one of the world's
`largest providers of on-device security services.
`
`In 2015, we increased our understanding of the ecosystem using automated
`systems that incorporate large-scale event correlation and machine learning
`to run more than 400 million automatic security scans per day on devices with
`Google Mobile Services. Thanks in part to these scans, successful exploitation
`of vulnerabilities on Android devices continued to be extremely rare during
`2015. The largest threat was installation of Potentially Harmful Applications
`(PHAs), or applications that may harm a device, harm the device's user, or
`do something unintended with user data. On average, less than 0.5% of devices
`had a PHA installed during 2015 and devices that only installed applications
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 5 of 14 PageID #: 19222
`
`from Google Play averaged less than 0.15%. Ongoing protection by Verify Apps,
`which scans for PHAs, and SafetyNet, which protects from network threats-as
`well as actions taken by the Android Security Team-helped stop the spread
`of PHAs like Ghost Push and reduced Russian fraudware by over 80%. We also
`released the SafetyNet Attest API to help developers check device compatibility
`and integrity.
`
`Android platform security
`
`All Android devices share a common security model that provides every
`application with a secure, isolated environment known as an application sand(cid:173)
`box. The Android security model has grown stronger over time, with further
`application isolation enabled by SELinux, enhanced exploit mitigations, and
`cryptographic features, such as full disk encryption and verified boot.
`
`In 2015, Android continued to iterate and expand platform security technology
`with the launch of Android 6.0. Most new devices with Android 6.0 have a
`hardware root of trust and provide a verifiable good boot state We introduced
`support for device fingerprint sensors, improving user security through ease of
`use We changed the perm1ss1on model so that users can see, grant, and revoke
`permissions for applications at a granular level, allowing for better control of
`the data and capabilities that each application can access Encryption is now
`mandatory for all devices capable of supporting it, and has been extended to
`allow for encrypting data on SO cards. We continue to guide the Android
`ecosystem to widely adopt the strongest available security technologies.
`
`Ecosystem security programs
`
`Android also has a number of efforts under way to promote security best
`practices in the ecosystem. The Android Compatibility Def1nit1on Document
`and Compatibility Test Suite provide a detailed series of security requirements
`and tests to prove compatibility with these requirements. Google works with
`device manufacturers to ensure that current devices are secure, and to define
`a roadmap of constantly increasing security for devices (such as the require(cid:173)
`ment introduced in 2015 for most new Android devices to use encryption
`and verified boot). Google Play encourages application developers to adopt
`security best practices; we introduced policy changes that enhanced user
`data protection in 2015, and also notified developers about potential security
`issues, resulting in improvement of security for over 100,000 applications.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 6 of 14 PageID #: 19223
`
`Google's role in Android ecosystem security
`
`Android SOK
`Google services I APls
`Security best practices
`Security improvement p ro g /
`
`
`AOSP
`CTS/CDD
`Security updates
`
`.
`
`·t~>t~
`
`-
`?:··
`h
`1
`Device
`. ;i
`~ · ' Makers
`:~ _, ·-~"·=. ~~~~--;~J
`~:~.~:
`~·~'
`
`I ~curity best practices
`Google Play l
`/
`
`I~, t
`
`~ > 1;.~
`
`Application
`,3~
`Dev,elopers
`· ·,>~l
`.
`~.,;. J~
`< v_:.,.Y-•:!'hi'~
`
`Google security services
`
`'
`
`•t
`
`.. '
`'.
`
`:;
`
`<'
`
`-
`
`,.
`
`'
`
`~ ...
`
`.
`k~ ' -~" ... 1
`
`: -
`
`Users
`
`• • 1•
`
`... :.:i. ~ ,,. ~
`
`. '
`~;.. .. ,_;;_ ~
`
`We launched the Android Vulnerability Rewards program to encourage
`independent security researchers to test Android's security protections and
`help us make the Android platform and ecosystem even safer.
`
`We continued to provide device manufacturers with ongoing support for fixing
`security vulnerabilities in devices, and have expanded the program to include
`monthly public security bulletins with security patches released to the Android
`Open Source Project (AOSP). In addition to the updates that we release for
`Nexus devices, several device manufacturers and network providers are also
`working toward monthly updates of their devices and services for users As
`part of this process, we introduced the Android security patch level, which
`makes checking if an Android device is up-to-date with all security patches as
`simple as knowing today's date.
`
`Openness strengthens security
`
`Over time, we've come to recognize that the diversity of devices is a security
`strength unique to the Android ecosystem. It is well known that highly uniform
`ecosystems are at risk of ecosystem-wide compromise. The classic real-world
`example of this phenomenon is crop blights, but the Internet-wide worms of the
`late l 990s are more recent, digital examples. Because Android is open source,
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 7 of 14 PageID #: 19224
`
`it has allowed device manufacturers to customize devices and introduce
`diversity. Android's varied ecosystem (with over 60,000 different device models)
`provides a naturally occurring defense against simple widespread exploitation,
`and has made it more difficult for attackers to be successful against the
`platform as a whole
`
`Android's open source model has also allowed device manufacturers to
`introduce new security capabilities Samsung KNOX, for example, has taken
`advantage of unique hardware capabilities to strengthen the root of trust
`on Samsung devices. Samsung has also introduced new kernel monitoring
`capabilities on their Android devices. Samsung is not unique in their contrib(cid:173)
`utions to the Android ecosystem. Blackberry has worked to enhance the
`security of their devices by enabling kernel hardening and other features
`in the Blackberry PRIV. CopperheadOS has both introduced security improve(cid:173)
`ments to their own version of Android and made significant contributions
`to the Android Open Source Project. These are just some of the various contrib(cid:173)
`utions made possible through open sourcing that improved the Android
`ecosystem in 2015.
`
`To summarize, Android has multiple layers of security technology in place
`to protect our users. In 2015, we improved our security technology, our
`understanding of the threats that the ecosystem faces, and our ability to
`respond to those threats. Android continues to advance the state of security,
`while protecting our users
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 8 of 14 PageID #: 19225
`
`Google Security
`Services for Android
`
`As stated earlier, Google provides security services to protect the Android
`ecosystem that includes both cloud-based services and on-device services
`delivered as Android applications. All devices with Google Mobile Services have
`the complete set of endpoint services that protect against a wide range of
`common threats including network attacks, application exploits, Potentially
`Harmful Applications, and physical attacks such as device theft
`
`Through aggregated, anonymized security data sent from user devices,
`we gather information and monitor the general state of the Android ecosystem.
`These services scan for Potentially Harmful Applications at install time,
`perform regular scans of installed applications, and provide user protection.
`The services also automatically send anonymized data back to Google,
`which we use to monitor the overall cleanliness of the Android ecosystem.
`
`As of the end of 2015, there were over 1 billion devices protected by
`Google's security services, and over 400 million device security scans were
`conducted per day. We believe this makes our security services the most
`widely deployed and used endpoint protection in the world .
`
`We believe this makes our security services
`the most widely deployed and used endpoint
`protections in the world.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 9 of 14 PageID #: 19226
`
`Google security services for Android, 2015
`
`Apps
`
`0 On Device 0
`
`On Cloud
`
`Install Apps
`
`0
`
`Attest API
`
`App Install Checks
`
`0
`
`'
`
`' ~
`
`~ ~
`
`Data
`App features
`Install source
`
`Knowledge
`Risk signal
`
`Data
`Rare Apps
`
`0
`
`Chrome
`
`Goo gle Mobile Services
`
`Smart Lock
`
`I
`
`Knowledge
`PHA or not
`
`D evice Manager
`
`Safe Browsing
`
`SafetyNet
`
`Verify Apps
`
`... ...
`..
`•
`
`Device Data
`Events
`Measurements
`Configuration
`Etc.
`
`Protection s
`Warnings
`Configurat ion Changes
`Etc
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 10 of 14 PageID #: 19227
`
`On-device protections
`
`One of our design goals is to provide the right protection at exactly the
`moment when it is needed most by the user. Google's use of both on-device
`and cloud-based services provides Android devices using GMS with flexibility
`to improve security in ways that are not possible within a traditional client
`operating system. The endpoint protections Google provides include preventing
`installation of Potentially Harmful Applications, enabling users to protect
`a lost or stolen device, protecting users against potentially harmful websites,
`simplifying the user-authentication process, and even helping third-party
`applications check the security of a device.
`
`Google on-device protections, 2015
`
`Service
`
`Protection
`
`VerifyApps
`
`Protection from Potentially Harmful Applications
`
`SafetyNet
`
`Protection from network and application-based threats
`
`Safebrowsing
`
`Protection from unsafe websites
`
`Developer API
`
`Provide applications with a way to use Google's security services
`
`Android Device Manager
`
`Protection for lost and stolen devices
`
`Smart Lock
`
`Improve user authent1cat1on and physical protection
`
`This section provides a description of these services and details the
`improvements to these services in 2015.
`
`Verify Apps
`Introduced in 2012, Verify Apps uses a cloud-based service to check every
`application prior to install to determine if the application is potentially harmful.
`In 2014, these checks were extended to scan applications already on the device
`to ensure none of them were harmful. Verify Apps will prompt the user to
`remove a PHA if one is found. Verify Apps can also remove an application
`without requiring the user to confirm the removal. We may use this functionality
`in rare cases to remove PHAs we determine are purely harmful and have no
`possible benefit to users.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 11 of 14 PageID #: 19228
`
`In 2015, we improved the ability of Verify Apps so that it can remove applic(cid:173)
`ations that register as Device Administrators. We also added the ability for
`Verify Apps to disable applications that have been installed onto the system
`partition following a compromise of the device security model.
`
`Not all security improvements are technical in nature. Some of them come
`from understanding user behavior and making the easiest choice also the
`safest In late 2015, we made several changes to the Verify Apps warning dialog
`to make it easy for users to proceed with the safe option of not installing a
`PHA. We added a red icon with an exclamation mark to signal to the user that
`this dialog needs their full attention. We also moved the option to proceed
`with installation under a cut to prevent cases where a user clicks OK without
`fully reading what the dialog says.
`
`Changing the user experience resulted in 50%
`fewer users installing PHAs.
`
`Comparison of Verify Apps Dialog Improvements
`
`Previous Verify Apps
`warning dialog
`
`New Verify Apps warning
`dialog, with the option to
`proceed with install hidden
`
`New Verify Apps warning
`dialog, showing the option
`to move forward with install
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 12 of 14 PageID #: 19229
`
`Verify Apps-Rare app collect1on
`Verify Apps protects users against applications that are installed from any
`source-whether they come from Google Play or outside of Play-so it is
`important that our systems have visibility into as many applications as possible.
`All applications that are submitted to Google Play undergo a review. Similarly,
`all applications that Google's cloud-based systems are able to locate on public
`websites are reviewed.
`
`Starting in 2015, users can send applications from their device to Google for
`review. This increases the effectiveness of the protection provided by Verify
`Apps for all users.
`
`SafetyNet
`SafetyNet allows devices to contribute security-related information to
`Google's cloud-based services This information can include information
`about security events, logs, configuration information. and other security(cid:173)
`relevant information. SafetyNet was introduced in 2013.
`
`SafetyNet-Exploit detection
`Many vulnerabilities have tell-tale characteristics associated with exploitation,
`such as passing a too-long string into a buffer, or receiving two different
`responses from a ONS server when requesting a single lookup.
`
`Google began to use this knowledge to improve Android device security in
`2013 when we added logging as part of vulnerability patches to detect
`exploitation. When a vulnerability 1s fixed, code is inserted into the platform
`(or application) which generates a log when a potential exploit attempt is
`detected. This log contains information required to track exploitation trends
`and better understand the effectiveness of our security improvements
`
`In 2015, we added exploit detection for multiple new vulnerabilities, including
`several related to Stagefright .
`
`SafetyNet-Network probes
`Certificate pinning and blacklisting were introduced in Android 4.2 to provide
`a mechanism to respond to potential compromises in the Certificate Authorities
`installed by default on Android devices. On devices with Android 4.4 and later,
`Android displays a warning if a certificate was installed locally on the device
`that could allow interception of SSL traffic. Starting in October 2014, SafetyNet
`used active network probes to identify cases where the system certificate store
`has been manipulated
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 13 of 14 PageID #: 19230
`
`Throughout 2015, SafetyNet found that fewer than 2 out of every million
`devices had installed a local certificate to man-in-the-middle network
`connections to Google services. In most cases, those certificates were installed
`by the user, although we have seen a small number of instances where devices
`were compromised and had a certificate installed directly into the system
`certificate store, which avoids the security warning to users on newer devices.
`All instances appear to be part of legitimate enterprise security efforts At this
`time, we have not detected any manipulation of the system certificate store
`efforts that we would classify as "malicious."
`
`Android Device Manager
`In 2013, Google introduced the Android Device Manager service to help users
`locate their lost Android devices. Users are also able to remotely set up a lock
`screen or erase the device entirely to protect their personal data and accounts.
`This is available to Android users who sign into their Google accounts on their
`phones. No additional downloads are required, and the service is enabled
`by default on devices running Android 4.4 and above.
`
`In 2015, 17.8 million people used Android Device Manager to locate their device,
`representing a 43% increase in usage over 2014. Of these, 22% were using
`Android Device Manager for the first time. Most users find their devices with
`the Locate and Ring functionality. Lock and Wipe functions are used
`significantly less. This may indicate that in general, devices are simply lost and
`users are able to recover them.
`
`We saw a steady growth in Android Device Manager usage, with more than
`200,000 1 daily users at the end of 2015.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-6 Filed 02/21/19 Page 14 of 14 PageID #: 19231
`
`Smart Lock
`Using a lockscreen greatly increases user privacy and security. Our research
`has found that many users of mobile devices choose not to use a lockscreen
`because manually unlocking their device dozens or even hundreds of times
`a day is too burdensome. In 2014, Android 5.0 introduced Smart Lock, which
`allows a user's device to remain unlocked as long as it remains in their
`possession, as determined by certain security signals. This reduces the
`number of times that a user needs to manually unlock their device and
`encourages adoption of a more secure lockscreen. Initially, Smart Lock
`supported trusted faces and trusted Bluetooth devices. In 2015, we extended
`Smart Lock to include on-body detection and trusted places. As the graph
`below shows, on average, users of Smart Lock need to unlock their device
`about half as often as before they enabled the feature And users that have
`configured Smart Lock to use multiple unlock mechanisms have even better
`results-use of trusted Bluetooth devices, trusted places, and on-body
`detection reduces the number of manual unlocks by about 90'%.
`
`Smart Lock Usage
`
`