Just an FYI if someone wants to dig further
ZTE can no longer use Qualcomm chips
Leads me to believe they were the ones who reverse engineered a backdoor into the phone chipsets for the Chinese Government. This would also explain the merger being halted between Qualcomm and Broadcom.
Anons, why is the container or pallets so important?
Kinda seems like a useless venture or a shill tactic to keep the board distracted.
The flaws affect Qualcomm chip software drivers installed at the point of manufacture, meaning updates must be pushed from the hardware company to phone vendors before it can flow to users.
Dump the container and pallets and I think you are on to something.
$130,000 is an interesting number to come up multiple times.
What the fuck was Comey up to? Was he working for the MB or China? Selling hacks into our technology through the FBI?
https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute
https://oig.justice.gov/reports/2018/o20180413.pdf
Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption
After covering a TrustZone kernel vulnerability and exploit in the previous blog post, I thought this time it might be interesting to explore some of the implications of code-execution within the TrustZone kernel. In this blog post, I'll demonstrate how TrustZone kernel code-execution can be used to effectively break Android's Full Disk Encryption (FDE) scheme. We'll also see some of the inherent issues stemming from the design of Android's FDE scheme, even without any TrustZone vulnerability.
I've been in contact with Qualcomm regarding the issue prior to the release of this post, and have let them review the blog post. As always, they've been very helpful and fast to respond. Unfortunately, it seems as though fixing the issue is not simple, and might require hardware changes.
If you aren't interested in the technical details and just want to read the conclusions - feel free to jump right to the "Conclusions" section. In the same vein, if you're only interested in the code, jump directly to the "Code" section.
SETTING THE STAGE
https://bits-please.blogspot.in/2016/06/extracting-qualcomms-keymaster-keys.html
In Apple's case you can't extract the hardware key no matter what software attack you carry out (w/ the OEMs or without). At most, you can bypass the software protections, but you'll still have to perform the bruteforce attempt strictly on the device.
CONCLUSIONS
The key derivation is not hardware bound. Instead of using a real hardware key which cannot be extracted by software (for example, the SHK), the KeyMaster application uses a key derived from the SHK and directly available to TrustZone.
OEMs can comply with law enforcement to break Full Disk Encryption. Since the key is available to TrustZone, OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device. This would allow law enforcement to easily brute-force the FDE password off the device using the leaked keys.
Patching TrustZone vulnerabilities does not necessarily protect you from this issue. Even on patched devices, if an attacker can obtain the encrypted disk image (e.g. by using forensic tools), they can then "downgrade" the device to a vulnerable version, extract the key by exploiting TrustZone, and use them to brute-force the encryption. Since the key is derived directly from the SHK, and the SHK cannot be modified, this renders all down-gradable devices directly vulnerable.
Android FDE is only as strong as the TrustZone kernel or KeyMaster. Finding a TrustZone kernel vulnerability or a vulnerability in the KeyMaster trustlet, directly leads to the disclosure of the KeyMaster keys, thus enabling off-device attacks on Android FDE.
HDC22@clintonemail.com
SEC_TEST
RSP_COUNT 1
session_close
Apache Keystone
supplemental addition
Hints:
POTUS tweet caps: SJC FBI BAD
Investigation report
https://oig.justice.gov/reports/2018/o20180413.pdf
http://www.keystone-engine.org/