字幕表 動画を再生する 英語字幕をプリント [MUSIC PLAYING] DAVE KLEIDERMACHER: Hello, and welcome to the Android P edition of what's new in Android security. My name is Dave. I lead mobile security here at Google. And in a few minutes, I'll hand it over to Xiaowen, who is the lead security product manager for the Android platform. We have a lot of ground to cover, so we'll start with a brief state of the union on Android security, and then jump into all the really cool things we've been working on in Android security over the past year and launching here at Android P, including secure hardware support advancements, lock screen authentication, integrity, and privacy. So state of the union. Let's talk a little bit about what the Android security strategy looks like. There are really three main pillars. First, Google Play Protect. This is the malware protection and mobile security services that run on over 2 billion Android devices today. The second pillar is platform engineering. These are the core operating system defenses that we build into Android to improve security to systems, such as SELinux, control-flow integrity protection, which we've been investing in a lot in P, and encryption, verified boot, lots of other features. The third pillar is the security development lifecycle. These are all the programs that we put in place to ensure a consistent, high-quality level for security across the Android ecosystem. So this includes things like testing infrastructures, and also includes our security patching programs. We've been working really hard on that. A couple of things we are investing in, we've been trying to make Android just easier to patch. So Google, we have a pretty steady track record for years now every single month delivering those patches to the market. But we want to make sure that all Android OEMs are delivering patches regularly to their devices as well, not just Google's devices. And so making Android more modular like with projects like Treble really help contribute to that. We've also worked on building security patching into our OEM agreements. Now, this will really lead to a massive increase in the number of devices and users receiving regular security patches. So we're really excited about that. But there are a couple of also really important philosophical principles that underlie everything we do when it comes to security. We believe in transparency and openness, because that breeds confidence and it breeds trust. Conversely, a closed platform, secrecy, that breeds distrust. But actually, there's a really important security advantage to be open. Today's mobile devices are faced with really sophisticated attack threats. When you have billions of users, it's an attractive target. And so it deserves the strongest possible defense. With a closed platform, the defenders are the employees of the one company that owns the platform. But with Android, we have the thousands of Googlers that wake up every morning thinking about how best to protect users and our platforms. We have the device manufacturers who have their own security team to work closely with Google on protecting Android and its users. We have the microprocessor manufacturers-- Arm, Intel, Qualcomm, Broadcom, and others, also with their security teams helping to protect Android. We have the worldwide open-source Linux community contributing to Android security every day. We have the academic research community, which simply prefer working on open platforms. So this is a mass force multiplier in protection. And as operating systems have matured, the power of open has really become evident to the point where today, the protective capabilities of Android are now on par with any other mobile platform. And I strongly believe that the power of open will accelerate those protective capabilities for our users going forward. The other really important philosophy that underlies our strategy is measurability. We always look for objective independent measurements to help not only inform the work that we do to ensure we're investing in the right directions, but also to measure progress. And so one example you see here is the incidence of malware or Potentially Harmful Applications we call PHA on devices. The bottom curve are devices that load only from Play, and the top curve are devices that load from sources other than Play. And you can see over time, it's been reducing across all users. So we are committed to protecting users, regardless of where they get their applications from. But this improvement is due to many things. It's locking down APIs and permissions over time. We're constantly looking at that. And it's investing in the malware detection engine itself. Today, 60% of malware is detected through machine learning. And that's been one area of big investment for us. Over the past year, we've had a 50% reduction in PHA on Play. And so we're really happy with the progress, but certainly, we're not content with where we stand today. Although, I will say that the odds of loading a PHA from Play is about the same as being struck by lightning. So it is a safe place to live on your mobile life, but we're going to continue to invest tremendously in this area. Another really important measurement is the overall ability of the operating system to protect itself against exploitation. In any complex product, there are going to be bugs. But there's no reason why bugs have to lead to exploitation to harm users. And so we work really hard on building features and improvements that make Android much more difficult and expensive to exploit. So how do you measure how well you're doing? Well, lots of people want to purchase exploits. There's a vibrant market for that. And as exploits get more difficult, of course, the law of supply demand, the prices are going to go up. And so we watch the pricing over time. And there's a number of different markets you can look at. On the left-hand side, you see the device manufacturers rewards programs. So the green bars are Google's rewards programs, which now are paying out the highest rewards in the industry. Another market you can look at are the elite hacking contests, like Mobile Pwn2Own. And you can see on the graph on the right, the price of Android exploits has risen each year to the point where now this is the most recent event a few months ago. The pricing for Android is on par with other platforms. And if you haven't seen the results, Android performed quite well in that event. Another market is the gray market. It's independent researchers and brokers who will sell exploits to the highest bidder. This market is a little bit harder to track, but we have connections to a lot of researchers out there. And again, anecdotally, what we're seeing is the price of exploitation on Android is now as high or higher than any other platform. So this is really great. We're happy with the progress, but we continue to invest in all these areas. And now let's switch gears and talk about some of the new emerging features in Android P, starting with the feature called Android Protected Confirmation. So the problem here is in today's secure mobility, we use mobile devices for much more than we ever did before, much more critical things. But there's still a ceiling of trust that we haven't quite broken through. We don't vote for prime minister or president from our phones. We don't program life-critical medical devices like an insulin pump from our phones. We don't have our passports built into our phones. It is our goal to break through that ceiling, and Android Protected Confirmation is a bold step in that direction. I'll talk about a few use cases-- medical, financial, enterprise. But the key innovation here is Protected Confirmation is the first time in any major operating system API that we now have the ability to execute a high-assurance user transaction completely within secure hardware running in a Trusted Execution Environment, or TEE, that runs separate from the main operating system. So how does it work? So an application developer, say you're a medical company that's developing a solution for people with diabetes, and so you're managing an insulin pump. You want to inject two insulin units into your insulin pump. And the application will enable the user to select two insulin units, and then call the protection API to transmit that data to the secure hardware area where a completely independent trusted user interface will execute. The interface you see here on the screen shows the two insulin units. The user then confirms it by pressing a button. The input is guarded in this protected area. And then this entire transaction is signed using a cryptographic key that never leaves that secure area. This provides higher assurance to the relying party, whether it be an insulin pump, or a financial service, or enterprise that the integrity of this data was not corrupted. Even if you had root level malware, you cannot corrupt the integrity of that transaction. So in code, this is really easy. We use the standard Android KeyStore API to create a public key. We have this new method to set the flag confirmation required. We create the dialog for the confirmation dialog using the Confirmation Dialog API. And then we simply call the present prompt method to transfer control from the main Android OS to this trusted execution environment, where the user will then interact with that special screen. Really easy. So we have a number of launch partners who've been working really closely with us on this technology. They've been building prototypes that they intend to make product into a product in the future. So Bigfoot Biomedical is a firm that works on solutions for people with diabetes. And you see here an app, the Bigfoot Biomedical app. The user is looking at the glucose level and deciding, I want to inject 1 and 1/2 insulin units. Uses the app to select that, then calls the API to invoke the new user interface that you see there. The user confirms. And then, and only then, will the insulin pump administer that dose. In the medical side, we have Royal Bank of Canada, RBC, that is working to integrate Protected Confirmations into their application. I don't have a video for this one, but you can track left to right. This application is moving a person-to-person financial transfer. We see we're going to send $1,500 to [? Robbie. ?] The application invokes the Protected Conformations API, which you see in the middle. The user confirms $1,500. So $1,500 can't be changed to $15,000. The relying party on the other end has high confidence that indeed, we intended to send [? Robbie ?] $1,500, and the transaction goes through. Duo Security is a firm that's working on strong enterprise authentication. Imagine you're logging into your Chromebook, into your G Suite application, and it launches a second factor authentication to your phone. You see the request come in on the left. The Duo Security application comes up and asks for confirmation, but then there's the second level confirmation using the Protected Confirmation API that provides, again, a higher level of assurance for the enterprise that it is the device, and user, and location that's expected for that authentication. So there are a lot of other launch partners we've worked closely with on this. Insulet Corporation is also integrating their application for control of diabetes. ProxToMe is doing proximal-based authentication. Nok Nok Labs in the enterprise authentication space as well. I'd also like to throw a shout-out to Qualcomm. We've been working really closely with Qualcomm to integrate the Protected Conformations API into the next generation Qualcomm chipsets. Because Protected Conformations requires a deep integration at the hardware level, it is optional for P, and so it requires a supported Android P device. We're breaking through that last ceiling of assurance in mobility, so it's very exciting. There's a lot more to talk about, and so I'd like to now call up Xiaowen to take us through the story. [APPLAUSE] XIAOWEN XIN: Thanks, Dave. Good morning, everyone. And I'm really excited to be here to talk about a lot more of the security and privacy features that we've built into Android P. So as Dave mentioned, secure hardware is a huge focus area for us, because they can provide defenses against attacks that software alone is simply not sufficient to handle. And so Protected Confirmation was an API that really leveraged secure hardware. And another feature that we're making in Android P, it leverages secure hardware also to provide stronger protection for private keys. So why do we need stronger protection for private keys? Well, Google Pay transit is a great example here. And in fact, we're working closely with them on this P feature, and they're going to launch with it later this year. Consider their security goal. In the traditional transit use case, they need to make sure that your transit card and only your credit card can be used to pay for your bus ride. So your transit card has your account information, a lot of secrets in there that represents your account. Now, the transit cards are simply made using a secure element inside of it, so it's very hard to break into it, extract secrets out of it, and duplicate that card. So Android Pay transit is now working to replace that transit card with your phone. And so we need to make sure that we provide the same security guarantees, which is that your secrets cannot be extracted out of your phone and put onto another phone. So in order to pay for your bus ride, you must present your phone. And a great solution here is to use secure hardware. Now, Google Pay transit is one example of an in-person transaction. Payments is another. In all of these use cases, you want to make sure that your phone and only your phone can make that transaction. There are quite a few other examples where we benefit from stronger protection for private keys. For example, if you have high value cloud data, if you're an enterprise, or if you are a financial institution, you want to make sure that all requests, all data access is coming from a known phone, a phone that you trust. And that phone is identified by a private key. Also, if you have high-value local data, let's say your password manager, you're storing passwords locally on disk, then you may want to encrypt it again with a private key that's well-protected. And so how do we provide stronger protection? Traditionally, secure elements such as those built [INAUDIBLE] smartcard credit cards, and second factor security keys and credit cards, are the gold standard for hardware security. They're built to exacting standards, and certified by professional labs to be resistant to hardware tampering. And phones are now starting to incorporate that exact hardware directly into the phone so that your phone can replace your transit card, replace your credit card, and replace your second factor security key. And so with Android P, we're now exposing APIs so that all the applications on Android can take advantage of this type of temporariness and hardware on compatible devices and potentially enable brand new use cases. Specifically, we're adding a new type of KeyStore called StrongBox. StrongBox is built using a tamper-resistant hardware, like a secure element, that has isolated CPU, RAM, and secure storage. The fact that it has its own dedicated CPU and RAM is pretty important, because it makes it so that it's resistant to shared resource attacks. For example, many of the high profile hardware attacks that we've heard about recently, StrongBox is resistant to those, as well as resistant to side channel attacks, like timing attacks, as well as physical attacks, like glitching the power line. So when we look at the KeyStore types that are available on Android, there are now three types of KeyStore. On older Android devices, KeyStore was typically implemented using the Android operating system directly. On new Android devices that ship with Android Nougat and above, KeyStore was implemented using the TE, the Trusted Execution Environment. And now with Android P, we're providing a new KeyStore called StrongBox that can run alongside it together with the existing KeyStore and the TE. StrongBox is resistant to the widest variety of attacks, and is really well-suited if you have a use case that requires strong protection for your private keys. Now, the caveat here is that because it does require new hardware, StrongBox will be available on only some new devices that ship with Android P. To use StrongBox, it's fairly straightforward. When you create your KeyStore key, set a new flag to request that the key be backed by StrongBox. If the device supports StrongBox, then everything succeeds and goes well. If the device does not support StrongBox, you'll get a StrongBox unavailable exception. So to summarize, StrongBox is implemented using tamper-resistant hardware, like a secure element. Secure elements are the gold standard for hardware security, and this is the first time that we're offering a generic API to access this type of secure hardware for key management. This feature, as well as the Protected Conformation API, are really pushing the boundary for secure hardware support on mobile. And we're really excited about the use cases that this enables. So protecting your private keys is one thing that apps need to do. Another thing that apps often need to do is to make sure that the right user is present. When you look at a typical Android device, especially one that's up to date and fully patched, the most likely security incident to happen to that device is not malware, but rather getting lost or stolen. And so a lock screen is very important for Android. Make sure you set a lock screen. And also, as an app developer, make sure that you do gate-sensitive access on user presence, on user authentication. So in Android P, we added a few different features to help app developers do that, starting with keyguard-bound keys. Keyguard-bound keys are KeyStore keys that are well-suited for protecting very sensitive data that you store directly on the device. Like the name implies, keyguard-bound keys have their functionality tied to the keyguard, which is the lock screen on Android. And so these keys can be used to encrypt data at any time, and can be used to decrypt data only when the device is unlocked. And so the lifecycle of these keys are tied to the lifecycle of the lock screen. For example, if you have very sensitive, very confidential enterprise data or very private health and fitness data, you might want to encrypt it with a keyguard-bound key before you store it to disk, so that if that device does get lost or stolen, as long as there's a lock screen on that device, it's now a little bit harder for an attacker to access the sensitive data. To use a keyguard-bound key, it's also fairly straightforward. When you create your KeyStore key, set a flag to require that the device be unlocked to use it for decryption. Then when you create your cipher objects, you can create it for encryption at any time. And you can create it for decryption only when the device is unlocked. So fairly straightforward, fairly simple. Now, what if your device has been properly unlocked, but you want to check for user authentication one more time, let's say, before a very sensitive action like a payment happens? This is where BiometricPrompt comes in. BiometricPrompt is our replacement for FingerprintManager. Now, a lot of apps today are using FingerprintManager to reauthenticate the user using fingerprints one more time. Now, FingerprintManager had a few limitations. One is it only works for fingerprint. A lot of devices today are starting to support face, iris, and other biometric modalities. And so with BiometricPrompt, we do support more than just fingerprint. We support several different modalities. And it will automatically pick the right modality for that user and for that device. Another benefit of BiometricPrompt is that it uses a standard system UI, which is really nice from a user experience perspective to show the user a standard UI when they're making a security-relevant decision. Also, it sets us up well for future advances in sensor technology when you have, for example, an end display fingerprint sensor. It's much easier for the OEM to customize this UI to tell the user exactly where to put their finger, and less scalable for an app to have to create device-specific UI. We know that BiometricPrompt is quite different from FingerprintManager. And so to ease the pain of migration, we're also providing a support library. And so apps will be able to call the one API in that support library, and that will use biometric prompt on Android P devices, and fall back gracefully to FingerprintManager on older devices. To use BiometricPrompts, create the builder object, and pass it, the title, and subtitle in these kinds of properties. Then call the authenticate method on the prompt to create to show the authentication prompt. We do recommend that you pass in the crypto object, because that's how you tie successful authentication attempts to a subsequent cryptographic operational. All right, so biometric prompt works really well when your users try to authenticate your native Android app. Now, what if the users actually go into your website in Chrome? How do you authenticate them there? This is where a WebAuthn and FIDO2 come in. Coming later this year in Q4, Chrome on Android will support WebAuthn, which means if the user's going to your website, they can now use their lock screen or their biometric signals to authenticate to your website. And I think this is very useful because, for example, if you like to buy things on the web, PayPal now actually has a demo running where you can use your fingerprints to authenticate to PayPal and use that to make your purchase. And so that's a lot more convenient than typing in your password every time you go to PayPal to make a purchase on the web. So then to summarize the several different methods that we talked about to gate access based on authentication. First, with keyguard-bound keys, you can tie data access to the lifecycle of the lock screen. If the user has already unlocked the screen and you want to reauthenticate the user, then you can use BiometricPrompt to show the system UI to prompt for biometric. And finally, if that user is going to your website instead of your native app, you can use WebAuthn to authenticate the user via fingerprint in Chrome on Android. OK, now that you've determined it's the right user, let's switch gears one more time to talk about integrity. A lot of apps really need to ensure the integrity of their data as well as the integrity of the device that they're running on. So how do we do this? In Android P, to help you protect the integrity of your data in transit, we're going to require TLS by default. So for all new apps that target the P API level, the system will throw an exception if the app sends data in the clear. Using TLS should be a no-brainer for apps today, because it protects the privacy of your users, and it also protects your content from being modified in transit, whether it's injection of unwanted ads, or injection of tracking identifiers, or especially formatted data to exploit a weakness in your app. So you should always encrypt. Now, if you're connecting to a legacy website that has not migrated to TLS yet, then you can still opt out of specific domains by updating your network security config. So do visit the website on this slide to learn more about customizing TLS enforcement for your app. Now, before you run off to change your code, we have one more piece of good news. A lot of apps care about FIPS cryptographic compliance, because it's really important and regulated industries and the government. So we're really happy that BoringSSL, which is used to secure SSL traffic on Android, recently received CAVP certificates from NIST for many FIPS-approved algorithms. And so this means that developers targeting regulated industries now basically have automatic FIPS compliance built in. So we're very excited about that. All right, so another topic in the integrity section that developers often care about is, how do I make sure that the device itself has not been tampered with? The device itself is still healthy? In Android O, we introduced a feature called key attestation. And it's been updated in Android P. Key attestation allows you to get a signed statement directly from the hardware itself, from StrongBox, from TE about the state of the device and about the properties of your private keys. So for example, key attestation can tell you whether the device passed verified boot, whether it's running a recent security patch, whether the private keys are protected by TE or StrongBox. Another thing that key attestation will return to you on compatible devices on Android P is the firmware hash that the device is running. So this is the digest of the operating system that you're running at this time. Think of this as transparency-enabled verified boot. What this means is that if you're running a firmware digest that's the same as that of a known good version, then you're actually running a bit for bit identical version of the operating system as a known good version. So that's a really powerful thing to know about what you're running. And it's really important for a tightly controlled environment, like enterprises, to know that the operating system that you're running is an exact copy of a known good version. For users of the SafetyNet attestation API, the implementation of that will call the platform key attestation API under the hood. So you [? would ?] be able to take advantage of this without any changes to your code. Now, in some cases, if you want to get more information from the API than what's returned by SafetyNet, you can still call the key attestation API directly. Now, last, but certainly not least, privacy. Privacy is an important area to security. We actually talked about privacy quite a bit already when we talked about, for example, the TLS by default feature coming in Android. But there are a few other privacy features that are in Android P that we want to cover now. First, this is probably one of my favorite features, sensor access only in the foreground. Running on an Android P device, regardless of your API level, if your app is in the background and idle, you will no longer be able to access the camera, microphone, or sensors. This behavior now is slightly different based on the exact characteristics of the API that you're targeting. So for example, with the microphone API, you will get silence when you try to access a microphone from the background in idle. With the camera API, it will behave as if you were preempted by a higher priority camera client. With sensors, it depends on whether the sensor returns data continuously or via callback. The bottom line is that if your app is in the background and idle, you can no longer access user data from sensors. Now, if you need to access the camera, microphone, or sensors and you're in the background, create a foreground service with a persistent user visible notification. So that gives users a lot more control and more transparency into which apps have access to their sensors at that time. To start a foreground service, create that persistent notification first, and then call the startForeground method, and pass in that notification. All right, besides restricted background access to sensors, we've also added a lot more user control over your data. So Android is the first major operating system to have DNS over TLS support built right in. And so your DNS queries will be redirected to a trusted resolver of your choice. That means that third parties on the web can no longer monitor or manipulate your DNS traffic. Now, if your default DNS resolver already supports it, then we will automatically encrypt your data. We did this in collaboration with Alphabet's jigsaw team, who are working on many other initiatives in this area. And so we're really looking forward to many new developments here. Another cool feature that we added an Android P in the privacy space is lockdown mode. So lockdown mode is useful if you're in a situation where you may temporarily lose access to your device. Let's say you need to hand it over for inspection at a security checkpoint. So at that time, you can put your device into lockdown mode, which is now in a state where only your knowledge factor, your pinpad and password can be used to unlock the device. And so your fingerprint and other biometrics will be disabled. Your Smart Lock will be disabled. In fact, notifications will no longer show on the lock screen. So you would now have much higher assurances on the state of the lock screen, on the security of a lock screen when the device is temporarily out of sight. So that was a quick overview of the features that are coming with Android P. There's a lot more that we didn't have time to cover. And so please do give us your feedback at google.com/io/schedule. And send us an email, security@android.com. Thank you for coming, and have a great day. [MUSIC PLAYING]
B1 中級 米 Androidセキュリティの新機能(Google I/O '18 (What's new in Android security (Google I/O '18)) 14 1 Tony Yu に公開 2021 年 01 月 14 日 シェア シェア 保存 報告 動画の中の単語