android.googlesource.com/platform/frame… is the place to start if you're interested in finer details of the implementation.

For Pixel 2 and later, isWeaverAvailable() is true.

SyntheticPasswordCrypto.personalisedHash(...) is used to quickly derive a value with SHA-512.
For example, the Weaver key is made by passing "weaver-key" and the password token to SyntheticPasswordCrypto.personalisedHash(...). That way, the password token derived with scrypt isn't actually sent to the secure element. That's used for deriving a bunch of different keys.
There's also other hashing that's not really noteworthy such as the lockscreen implementation hashing the password in a similar way before passing it along, etc. The actual work factor is provided by scrypt and the SoC-specific hardware-accelerated, hardware-bound key derivation.
Focusing on the important aspects in the FAQ section. Skipping over how it works on devices without Weaver and user profiles without a password also helps keep things simpler. Devices without Weaver use personalisedHash of a 16kiB randomly generated file to help with wiping keys.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with DanielMicay

DanielMicay Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @DanielMicay

27 Dec
CAKE works extremely nicely for providing fair allocation of outgoing bandwidth from a server:

tc qdisc replace dev eth0 root cake bandwidth 500mbit besteffort

Bandwidth parameter needs to be properly set so that it becomes the bottleneck and actually shapes the traffic.
It will evenly divide the bandwidth between hosts so a host opening many connections (download managers) doesn't end up with higher bandwidth. It also evenly divides the per-host bandwidth between the flows to the host. SSH latency will also remain very low even under heavy use.
CAKE:

* client A with 1 connection gets 48mbit
* client B with 8 connections gets 6mbit each adding up to 48mbit

No CAKE:

* client A with 1 connection gets ~6mbit to ~16mbit
* client B with 8 connections gets ~6mbit to ~16mbit each adding up to ~80-90mbit

Stark difference.
Read 6 tweets
5 Nov
github.com/GrapheneOS/har… was initially released in August 2018. I developed it to replace the port of OpenBSD malloc to Linux and Android that I made in 2014.

Copperhead was founded in late 2015 and split from my open source Android hardening project in June 2018.
My open source Android hardening project had already been renamed to the Android Hardening project when hardened_malloc was developed and released.

The hardened_malloc license requires attribution. License and copyright header needs to be included by anything using the code.
Copperhead is misrepresenting my allocator hardening work throughout the years as their own. They're fraudulently misrepresenting my open source work throughout the years as their own and by not complying with the licensing. This is a particularly egregious case of it though.
Read 21 tweets
4 Nov
We need help building a more complete historical archive of the GrapheneOS code. Please get in touch with me if you have clones of the Git repositories from 2015 or earlier. The repositories on GitHub were the ones created for the CopperheadOS Beta but don't have older tags, etc.
There was an earlier generation of repositories for the CopperheadOS Alpha and earlier when the project was based on CyanogenMod, including before it was branded as CopperheadOS. It would be ideal to obtain an archive of this code. Obtaining this would make a big difference.
The network graphs like github.com/GrapheneOS/pla… and github.com/GrapheneOS/pla… show some of the forks of the project from the CopperheadOS Beta era. There were also forks in the earlier Alpha era and earlier. Ideally, we can get a full archive of it, not just specific repositories.
Read 5 tweets
1 Oct
@mamushi_io @intimitatem @Fonta1n3 @GrapheneOS You're just selling a proprietary project forked from our code in violation of the licenses. You're supporting a company that's anti-open-source and is waging a nasty war against the open source project they depend on. It's hard to take a proprietary ripoff seriously.
@mamushi_io @intimitatem @Fonta1n3 @GrapheneOS CopperheadOS is a fork of our legacy codebase in violation of the licenses with DRM and tracking added to the Updater app. It is primarily just AOSP with a custom boot animation and wallpaper, since they have not meaningfully maintained or developed real privacy/security work.
@mamushi_io @intimitatem @Fonta1n3 @GrapheneOS You're selling people a very expensive product that's making them less private and secure. The original open source project is available for free with far more privacy and security, and without tracking. People are far better off with iPhones than yet another 'secure' phone scam.
Read 5 tweets
21 Sep
The public Android security bulletins are not nearly as useful as they used to be since so much information was stripped out of them. Need to figure out even basic details entirely from the commit message and changes to the code. Internal bulletins still have more information.
This makes it difficult to figure out when a bug was fixed with only the details of the bug including the impacted subsystem but not a CVE ID. threatpost.com/bluetooth-spoo… says the issue is unpatched on Android but that seems based on the researchers testing a device without updates.
It's highly likely that android.googlesource.com/platform/syste… is the fix for this issue since it's a fix for a security bug in pairing tied to authentication of a device that was previously paired. I'm not entirely sure it's the same bug since there aren't enough details available for the fix.
Read 9 tweets
16 Sep


Android 11 disables usage of stable "privacy" addresses for networks where MAC randomization is being used. We'll no longer need to disable this feature. The other issues we've discovered and put initial work into addressing are still problems though.


Silly bot.

Disabling IPv6 would certainly be an easy way to address multiple issues in the Linux kernel implementation providing a way to track users across networks. Linux kernel's take on "privacy" addresses regresses privacy in some very serious ways.
Linux reuses "privacy" addresses across networks. This leaks that it's the same device connecting from a different network. It does this even when randomizing the MAC address. It also uses a very long lifetime for these addresses by default. It's a pretty bad implementation.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!