Android Q Hardens Security, Adds Better Encryption – BleepingComputer


Google announced the integration of more security features into Android Q designed to further harden the security of critical areas like the kernel, as well as making storage encryption standard and updated biometrics API.

The new Android Q updates were announced during today’s Google I/O developer conference keynote and showcased on Google’s Android Developers Blog.

Just in from #io19, we lifted the curtain on #AndroidQ‘s new security features 

• Better encryption with Adiantum & TLSv3
• Enhanced Platform Hardening
• Updated BiometricPrompt API & FIDO2 support

Read the post for more info

— Android Developers (@AndroidDev) May 9, 2019

Hardening Android Q’s security

Android comes with a number of defense strategies designed to block bug exploitation that could allow the built-in security systems to be circumvented.

Among these security protection strategies, “process isolation, attack surface reduction, architectural decomposition, and exploit mitigations” are applied to make it a lot harder to take advantage of Android vulnerabilities.

These security defense approaches are now utilized in Android Q to secure “critical areas such as media, Bluetooth, and the kernel.”

Some of the new improvements added to the platform in Android Q are explained in more detail in this Google Security blog post and highlighted below:

  • A constrained sandbox for software codecs.
  • Increased production use of sanitizers to mitigate entire classes of vulnerabilities in components that process untrusted content.
  • Shadow Call Stack, which provides backward-edge Control Flow Integrity (CFI) and complements the forward-edge protection provided by LLVM’s CFI.
  • Protecting Address Space Layout Randomization (ASLR) against leaks using eXecute-Only Memory (XOM).
  • Introduction of Scudo hardened allocator which makes a number of heap related vulnerabilities more difficult to exploit.

Default device encryption

Support for storage encryption has been expanded to all devices compatible with Android Q, even for those that do not come with “cryptographic acceleration hardware” with the help of Adiantum.

The Adiantium storage encryption method was introduced in February and it allows underpowered Android devices which come with low-end CPUs such as ARM’s Cortex-A7—a processor that does not feature built-in hardware support for AES—to also encrypt the storage without a performance hit.

“All compatible Android devices newly launching with Android Q are required to encrypt user data, with no exceptions. This includes phones, tablets, televisions, and automotive devices,” says Google.

Performance comparison between AES-256-XTS and Adiantum
Performance comparison between AES-256-XTS and Adiantum

TLS 1.3 was also added as a default option in Android Q, leading to the automatic removal of weaker cryptographic algorithms, together with various security fixes for TLS 1.2 weaknesses.

The TLS 1.3 protocol was approved by the Internet Engineering Task Force (IETF) back on March 21, 2018, after no less than four years of discussions and 28 protocol drafts.

As detailed in IETF’s TLS 1.3 Internet Draft, “TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.”

On top of that, as explained by the Android Security & Privacy Team, “TLS 1.3 can often complete the handshake in fewer roundtrips, making the connection time up to 40% faster for those sessions.”

TLS 1.3 comes with the following differences when compared to the TLS 1.2 protocol which it deprecates:

  • Removes older encryption and hashing algorithms (such as MD5 and SHA-224) and adds harder to crack alternatives (such as ChaCha20, Poly1305, Ed25519, x25519, and x448).
  • Is a lot faster at negotiating the initial handshake between the client and the server, reducing the connection latency and removing the excuse of not supporting HTTPS because of lower browsing speeds.
  • Supports features like Zero Round Trip Time (0-RTT) and TLS False Start designed to also cut down the time needed to establish encryption handshakes with hosts to which the client has talked before.
  • Comes with downgrade attack protection that prevents an attacker from tricking a server into using older versions of the protocol, susceptible to known vulnerabilities.

Push for biometric authentication

Google updated the BiometricPrompt API as part of the Android Q release, an API used by Android apps to allow users to authenticate using their face, fingerprints, or iris.

Since the launch, we’ve seen a lot of apps embrace the new API, and now with Android Q, we’ve updated the underlying framework with robust support for face and fingerprint. Additionally, we expanded the API to support additional use-cases, including both implicit and explicit authentication.

BiometricPrompt now also allows developers to create apps which can check if biometric authentication support is available on the device before invoking the API, thus making it simple to have the “Enable biometric sign-in” displayed within the app’s user interface if the Android device comes with a compatible authentication sensor .

As the Android Security & Privacy Team also mentioned at the end of their Android Q security update, Googel is also planning to “add Electronic ID support for mobile apps, so that your phone can be used as an ID, such as a driver’s license.”

For the time being, the feature is in the works because it still requires “standardization from the ISO,” and effort that’s “being led by the Android Security and Privacy team.”

“Apps such as these have a lot of security requirements and involves integration between the client application on the holder’s mobile phone, a reader/verifier device, and issuing authority backend systems used for license issuance, updates, and revocation,” also says the Android Security & Privacy Team.

Let’s block ads! (Why?)

Original Post Source link