od2gf04pd9
ac32dorbdq
sh
com.android.browser
com.qihoo.browser
com.oupeng.browser
09 00 00 50 4B 01 02 14 00 14 00 08 00 08 00 4F ...PK..........O 91 F3 48 AE CF 91 D5 B1 04 00 00 52 09 00 00 04 ..H........R.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 32 33 38 36 50 4B 05 06 00 00 00 00 01 00 01 .2386PK......... 00 32 00 00 00 E3 04 00 00 00 00 .2.........
[collect_Head]device=Nexus 5X [collect_Space]xadevicekey=xxxxx … [collect_Space]collentmod=opappresultmode [collect_Space]registerUser=true [collect_End]
LABEL+13: V18 = -1; LABEL_18: j___config_log_println(v7, v6, v10, v11, "cf89450001"); if ( v10 )
<MD5 of the process name>36.jmd
com.android.systemui
com.android.vending
GET_REAL_TASKS
getRecentTasks()
36.jmd
We’ve become aware of an issue that affects the Bluetooth Low Energy (BLE) version of the Titan Security Key available in the U.S. and are providing users with the immediate steps they need to take to protect themselves and to receive a free replacement key. This bug affects Bluetooth pairing only, so non-Bluetooth security keys are not affected. Current users of Bluetooth Titan Security Keys should continue to use their existing keys while waiting for a replacement, since security keys provide the strongest protection against phishing.
What is the security issue?
Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key -- within approximately 30 feet -- to (a) communicate with your security key, or (b) communicate with the device to which your key is paired. In order for the misconfiguration to be exploited, an attacker would have to align a series of events in close coordination:
This security issue does not affect the primary purpose of security keys, which is to protect you against phishing by a remote attacker. Security keys remain the strongest available protection against phishing; it is still safer to use a key that has this issue, rather than turning off security key-based two-step verification (2SV) on your Google Account or downgrading to less phishing-resistant methods (e.g. SMS codes or prompts sent to your device). This local proximity Bluetooth issue does not affect USB or NFC security keys.
Am I affected?
This issue affects the BLE version of Titan Security Keys. To determine if your key is affected, check the back of the key. If it has a “T1” or “T2” on the back of the key, your key is affected by the issue and is eligible for free replacement.
Steps to protect yourself
If you want to minimize the remaining risk until you receive your replacement keys, you can perform the following additional steps:
iOS devices:
On devices running iOS version 12.2 or earlier, we recommend using your affected security key in a private place where a potential attacker is not within close physical proximity (approximately 30 feet). After you’ve used your key to sign into your Google Account on your device, immediately unpair it. You can use your key in this manner again while waiting for your replacement, until you update to iOS 12.3.
Once you update to iOS 12.3, your affected security key will no longer work. You will not be able to use your affected key to sign into your Google Account, or any other account protected by the key, and you will need to order a replacement key. If you are already signed into your Google Account on your iOS device, do not sign out because you won’t be able to sign in again until you get a new key. If you are locked out of your Google Account on your iOS device before your replacement key arrives, see these instructions for getting back into your account. Note that you can continue to sign into your Google Account on non-iOS devices.
On Android and other devices:
We recommend using your affected security key in a private place where a potential attacker is not within close physical proximity (approximately 30 feet). After you’ve used your affected security key to sign into your Google Account, immediately unpair it. Android devices updated with the upcoming June 2019 Security Patch Level (SPL) and beyond will automatically unpair affected Bluetooth devices, so you won’t need to unpair manually. You can also continue to use your USB or NFC security keys, which are supported on Android and not affected by this issue.
How to get a replacement key
We recommend that everyone with an affected BLE Titan Security Key get a free replacement by visiting google.com/replacemykey.
Is it still safe to use my affected BLE Titan Security Key?
It is much safer to use the affected key instead of no key at all. Security keys are the strongest protection against phishing currently available.
Posted by Rene Mayrhofer and Xiaowen Xin, Android Security & Privacy Team
With every new version of Android, one of our top priorities is raising the bar for security. Over the last few years, these improvements have led to measurable progress across the ecosystem, and 2018 was no different.
In the 4th quarter of 2018, we had 84% more devices receiving a security update than in the same quarter the prior year. At the same time, no critical security vulnerabilities affecting the Android platform were publicly disclosed without a security update or mitigation available in 2018, and we saw a 20% year-over-year decline in the proportion of devices that installed a Potentially Harmful App. In the spirit of transparency, we released this data and more in our Android Security & Privacy 2018 Year In Review.
But now you may be asking, what’s next?
Today at Google I/O we lifted the curtain on all the new security features being integrated into Android Q. We plan to go deeper on each feature in the coming weeks and months, but first wanted to share a quick summary of all the security goodness we’re adding to the platform.
Storage encryption is one of the most fundamental (and effective) security technologies, but current encryption standards require devices have cryptographic acceleration hardware. Because of this requirement many devices are not capable of using storage encryption. The launch of Adiantum changes that in the Android Q release. We announced Adiantum in February. Adiantum is designed to run efficiently without specialized hardware, and can work across everything from smart watches to internet-connected medical devices.
Our commitment to the importance of encryption continues with the Android Q release. 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. This will ensure the next generation of devices are more secure than their predecessors, and allow the next billion people coming online for the first time to do so safely.
However, storage encryption is just one half of the picture, which is why we are also enabling TLS 1.3 support by default in Android Q. TLS 1.3 is a major revision to the TLS standard finalized by the IETF in August 2018. It is faster, more secure, and more private. TLS 1.3 can often complete the handshake in fewer roundtrips, making the connection time up to 40% faster for those sessions. From a security perspective, TLS 1.3 removes support for weaker cryptographic algorithms, as well as some insecure or obsolete features. It uses a newly-designed handshake which fixes several weaknesses in TLS 1.2. The new protocol is cleaner, less error prone, and more resilient to key compromise. Finally, from a privacy perspective, TLS 1.3 encrypts more of the handshake to better protect the identities of the participating parties.
Android utilizes a strategy of defense-in-depth to ensure that individual implementation bugs are insufficient for bypassing our security systems. We apply process isolation, attack surface reduction, architectural decomposition, and exploit mitigations to render vulnerabilities more difficult or impossible to exploit, and to increase the number of vulnerabilities needed by an attacker to achieve their goals.
In Android Q, we have applied these strategies to security critical areas such as media, Bluetooth, and the kernel. We describe these improvements more extensively in a separate blog post, but some highlights include:
Android Pie introduced the BiometricPrompt API to help apps utilize biometrics, including face, fingerprint, and 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.
In the explicit flow, the user must perform an action to proceed, such as tap their finger to the fingerprint sensor. If they’re using face or iris to authenticate, then the user must click an additional button to proceed. The explicit flow is the default flow and should be used for all high-value transactions such as payments.
Implicit flow does not require an additional user action. It is used to provide a lighter-weight, more seamless experience for transactions that are readily and easily reversible, such as sign-in and autofill.
Another handy new feature in BiometricPrompt is the ability to check if a device supports biometric authentication prior to invoking BiometricPrompt. This is useful when the app wants to show an “enable biometric sign-in” or similar item in their sign-in page or in-app settings menu. To support this, we’ve added a new BiometricManager class. You can now call the canAuthenticate() method in it to determine whether the device supports biometric authentication and whether the user is enrolled.
Beyond Android Q, we are looking to add Electronic ID support for mobile apps, so that your phone can be used as an ID, such as a driver’s license. 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.
This initiative requires expertise around cryptography and standardization from the ISO and is being led by the Android Security and Privacy team. We will be providing APIs and a reference implementation of HALs for Android devices in order to ensure the platform provides the building blocks for similar security and privacy sensitive applications. You can expect to hear more updates from us on Electronic ID support in the near future.
Follow