{"id":8981,"date":"2017-08-29T10:30:07","date_gmt":"2017-08-29T18:30:07","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/08\/29\/news-2754\/"},"modified":"2017-08-29T10:30:07","modified_gmt":"2017-08-29T18:30:07","slug":"news-2754","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/08\/29\/news-2754\/","title":{"rendered":"Android 8.0 in-depth: Oreo's not-so-obvious security enhancements"},"content":{"rendered":"

<\/p>\n

Credit to Author: JR Raphael| Date: Tue, 29 Aug 2017 10:01:00 -0700<\/strong><\/p>\n

When you read about a splashy new software update like Google’s fresh-from-the-oven Android 8.0 Oreo<\/a> release, you tend to hear mostly about the marquee features \u2014 the most attention-grabbing elements and refinements<\/a> you’re likely to notice when you get the update<\/a> on your own device.<\/p>\n

It’s understandable, since those are the things we all see most immediately and directly. Beneath the surface, though, Oreo has some pretty significant stuff going on in the realm of security \u2014 stuff that hasn’t been widely covered\u00a0but is as important as anything else to understand.<\/p>\n

Some of it’s fairly technical and much of it’s the sort of info you’d probably never encounter if you didn’t frequent developer-targeted talks and forums. But all of it affects your phone’s ability to keep you safe from theoretical threats \u2014 and all of it is worthwhile to be aware of.<\/p>\n

Here are the high points, translated from mumbo jumbo into practical, plain-English terms.<\/p>\n

Whenever you install a new app, you grant it permission to access certain types of data and perform certain types of functions on your device. (You know when you first run an app, and it shows you a bunch of info \u2014 all those prompts you hit “OK” on without paying close attention? Yeah, that’s the stuff.) With Oreo, Android is rethinking a couple of those permissions and scaling back what apps are allowed to do.<\/p>\n

Up first is a permission for generating something called a System Alert Window. It’s ostensibly for displaying, y’know, system alerts \u2014 but over time, it’s been adopted for a variety of other overlay-oriented purposes. Some apps use it to provide picture-in-picture-like elements that float on top of other apps, for instance, while password management utilities have traditionally used it to generate pop-up boxes for filling in forms across the operating system.<\/p>\n

That’s all well and good, but Google realized the same System Alert Window permission actually raised the potential for abuse. Randomware apps could essentially use it to take over your screen and trick you into providing sensitive info or clicking on questionable links to escape.<\/p>\n

Oreo addresses this by introducing some new System Alert Window limits. Specifically, the contents of such windows can no longer cover up critical areas of your screen like your status bar or lock screen, and a new persistent notification now appears whenever an overlay is present so you always have a built-in way to dismiss it and move on.<\/p>\n

Another long-standing Android permission, Device Admin, is also being restricted as of Oreo so that apps can no longer use it to prevent themselves from being uninstalled or to alter your system password \u2014 again, with the goal of reducing the potential for abuse by any ill-intending apps.<\/p>\n

So why did the broader versions of the permissions stick around for so long? That’s what I wondered, too. I had the chance to ask Xiaowen Xin, Google’s product manager for Android platform security. Xin says that in some cases, Google recognized the legitimate ways developers wanted to use the permissions and wanted to make sure those use-cases were covered \u2014 by implementing a proper picture-in-picture option<\/a> and native auto-fill function<\/a>, in the case of Oreo and the System Alert Window \u2014 before introducing any limits.<\/p>\n

“Android comes from a stance of trying to be more open, and we’re trying to provide APIs that in some cases are for power users,” Xin explains. “It’s a constant challenge for us and that’s unique to Android of balancing how to protect users and [yet still providing advanced] functionality.”<\/p>\n

Android has had a Verified Boot system since 2013, when KitKat was the name of the day. From its beginning, the system has checked your phone’s software every time your device starts up to make sure everything’s in proper working order.<\/p>\n

With Oreo, the system is expanding: In addition to performing the standard startup checks, Android’s Verified Boot feature will now prevent your device from starting if it’s been rolled back to an older and thus less secure version of the operating system.<\/p>\n

Why? Simple: Such protection would prevent anyone from taking control of your device and manually downgrading you to a previous version of Android in order to exploit an old bug that’s patched in the more\u00a0current version.<\/p>\n

“Once you reboot, you’d actually be clean again \u2014 so any exploit would no longer be running on your phone,” Xin says.<\/p>\n

Oreo also supports the ability for the secure hardware area of a device to generate a statement guaranteeing that the system has passed that Verified Boot check and <\/em>has a reasonably recent Android security patch. That could be utilized by something like a bank \u2014 to ensure a device hasn’t been compromised before granting access to a customer \u2014 or even an enterprise, to confirm with near-certainty that its employees’ phones are secure.<\/p>\n

Ready for more? Oreo introduces support for new tamper-resistant hardware \u2014 so basically, the same sort of chip that stores sensitive info in a modern credit card could store your PIN, pattern or password on a future Android phone. That info is already stored in an area known as the Secure Element, but moving it to the chip makes it even more difficult for someone to perform a physical attack on your device and get around your lock screen.<\/p>\n

So what about fingerprint data? That’s precisely what I wondered, too. (You and I are just on the same page today, aren’t we? We really oughta hang out more often.) Turns out biometric security info like your pawprints aren’t<\/em> included in the new chip-based system \u2014 because the tradeoff of the system’s added security is reduced speed. In other words, it’s slower than the regular method of authentication, and Google doesn’t want you to have to wait multiple seconds for your pointer to be recognized.<\/p>\n

But for an enterprise scenario where bulletproof security trumps everything else in importance, it’s easy to see how this capability could be beneficial.<\/p>\n

This isn’t the playground kind of sandbox fun (though if you’re reading this while in a sandbox, kudos to you, sir and\/or madam). Android has long utilized sandboxing to keep different parts of the operating system in their own isolated areas \u2014 so that if something does manage to infect one part of the software, it won’t be able to reach another.<\/p>\n

With Oreo, the effort expands on a few different levels. First, there’s Project Treble \u2014 you’ve heard of it, right? Treble isolates the device-independent parts of the operating system from the device-dependent parts of the operating system. Much of the focus thus far has revolved around how this separation could (theoretically, with some asterisks<\/a>) make it easier for manufacturers to process and send out Android OS updates, but there’s an equally important factor in its effect on security. Remember? Sandboxing.<\/p>\n

“If you have an exploit in one [area], it’s now harder for that to affect a different part of the operating system,” Xin says.<\/p>\n

Android 8.0 also sandboxes apps more closely with something called a seccomp filter (gesundheit!). For the non-engineers among us, the short version is that this makes it more difficult for a naughty app to do anything dangerous to the kernel \u2014 the operating system’s brain or command center, in the simplest possible terms \u2014 by limiting the ways in which apps can interact directly with it. (If you want the full technical version, you can find it here<\/a>. Godspeed.)<\/p>\n

Last but not least, Android’s WebView function \u2014 which allows developers to show you web-based content within their apps \u2014 moves to its own separate process as of Oreo. That means if you run into some sort of web-based bug while viewing a site within an app, it shouldn’t be able to reach or affect any other areas of the operating system. Sandboxing. Again.<\/p>\n

Got all that? Good. Let’s move on.<\/p>\n

This point’s relatively minor, but if you’re using Android in an enterprise environment, it’s significant: As of Android 8.0, all devices use a different key for encrypting personal profiles and work profiles. And beyond that, the device administrator has the ability to activate the work profile key remotely and make sure work data is fully secured anytime, anywhere.<\/p>\n

Oh, and a tantalizing tease: Google is working on “a lot more” with encryption for 2018’s Android P release, Xin says. So stay tuned.<\/p>\n

Last but not least: If you’re using two-factor authentication to protect your accounts (and you absolutely should be<\/a> \u2014 c’mon!), Oreo allows you to use a physical security key<\/a> as your second form of authentication. Just connect your key to your Android device via Bluetooth, NFC or USB, and you won’t have to find and input the usual two-factor code when you sign into a secured account.\u00a0<\/p>\n

The asterisk is that this is available via a new API \u2014 so that means it’ll be up to individual apps to support it as a feature, and you won’t find many places where it’ll work just yet. Long-term, though, it could be a relevant addition for security-minded users who don’t mind carrying an extra contraption for convenience.<\/p>\n

And a bonus: This update is actually being delivered via Google Play Services, so it’ll apply to devices running software all the way back to Android 5.0 (Lollipop) or higher. Google tells me it’ll eventually be supported at the system level, too, for adding two-factor-protected Google accounts onto your device.<\/p>\n

From a bigger picture perspective, of course, Android security is a puzzle with lots of moving pieces. All the stuff we’re talking about here works alongside a multilayered system for scanning and protection<\/a> \u2014 one that’s present and functional on practically every reasonably recent Android device\u00a0\u2014 and is supplemented by monthly security patches to fill in the gaps between OS releases.<\/p>\n

When it comes to both security and mobile software, the evolution never ends.<\/p>\n

[Android 8.0: The complete Oreo FAQ<\/a>]<\/strong><\/p>\n

http:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

<\/p>\n

Credit to Author: JR Raphael| Date: Tue, 29 Aug 2017 10:01:00 -0700<\/strong><\/p>\n

\n
\n

When you read about a splashy new software update like Google’s fresh-from-the-oven Android 8.0 Oreo<\/a> release, you tend to hear mostly about the marquee features \u2014 the most attention-grabbing elements and refinements<\/a> you’re likely to notice when you get the update<\/a> on your own device.<\/p>\n

It’s understandable, since those are the things we all see most immediately and directly. Beneath the surface, though, Oreo has some pretty significant stuff going on in the realm of security \u2014 stuff that hasn’t been widely covered\u00a0but is as important as anything else to understand.<\/p>\n

To read this article in full or to leave a comment, please click here<\/a><\/p>\n<\/section>\n<\/article>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[11062,10643],"tags":[10462,10554,10463,714],"class_list":["post-8981","post","type-post","status-publish","format-standard","hentry","category-computerworld","category-independent","tag-android","tag-mobile","tag-mobile-security","tag-security"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/8981","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=8981"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/8981\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=8981"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=8981"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=8981"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}