Nuttso That's quite unfortunate. For Molly, is it possible to implement spliting the database/storage, and use a public-private temporary key model and protect the permanent database with a key that requires unlock in strongbox? Or if the user opt in to use the notification without any content preview or sender preview, enforce unlock for all keys except the notification token. I doubt many privacy conscious Molly users use message content preview anyway
[deleted] yes ofc it is, but it doesn't make sense to implement it now. We didn't touch the data model at all. We will lose backup compatibility and we would need to do a lot more testing before releasing builds. We already have some ideas how this can be approached. But it's currently not possible with signals sever infrastructure.
No problem, just opened a new thread.
Matthai Cellebrite specifically claims they have been able to extract plaintext iPhone passcode (Instant Passcode Retrieval) from AFU iPhone since A11
yes, source https://postimg.cc/gxNXN4MK
Matthai they are able to dump Secure Enclave RAM since A11
Hathaway_Noa I uploaded all the necessary PDF files detailing their capabilities / release notes + how to use on the following link:
https://easyupload.io/m/t94ht1
With every new Cellebrite Premium / Inseyets updateI will upload the PDF files :)
Because they're able to BF in BFU mode, it necessarily implies that they can bypass secure enclave's timing delay. This strongly implies that they have code execution on secure enclave because "the Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities"
Nuttso But it's currently not possible with signals sever infrastructure.
Why would the splitting the database/storage, and using a public-private temporary key model be incompatible with server infrastructure?
Nuttso We will lose backup compatibility
If splitting the database/storage, and using a public-private temporary key model is implemented, could this be merged upstream to signal? There should be no UX difference or any impact on existing signal users
[deleted] yes, source https://postimg.cc/gxNXN4MK
I'm not sure anyone in their right mind could consider that an anonymously posted graphic with some words on it is a particularly reliable 'source'.
One thing I noticed that the page about iPads doesn't mention Instant Passcode Retrieval. That makes me wonder if iPad have something that makes it harder to pull off IPR or they just didn't spend enough time on them because iPhones are higher priority?
I was looking at their Android booklet again, for Pixel 6+ on Stock OS, BFU it says:
BFU Yes
BF No
What does it mean? I am reading "BF No" as secure element time limiter is holding up and prevents them brute forcing all possible PIN combinations.
If that's the case, what does "BFU Yes" mean? How they can extract the data in BFU state without knowing the PIN and without an ability to brute force it?
[deleted] Why would the splitting the database/storage, and using a public-private temporary key model be incompatible with server infrastructure?
Doing that would only make sense, if we manage to not expose the account credentials unencrypted, that are necessary to identify the account and be able route the messages to it. The server needs to know where to route massages. It is possible to have encrypted credentials, but we need the compatibility on the server side to do it right.
[deleted] If splitting the database/storage, and using a public-private temporary key model is implemented, could this be merged upstream to signal? There should be no UX difference or any impact on existing signal users
That would be necessary before we could do it. Signal doesn't really care about the client.
Joined just to post about this!
Instant password retrieval on iPhone
One of the slides (if legit) underlines that this is a time sensitive feature. I suspect that this feature exploits the phone via usb/lightning and the time sensitivity is due to usb restricted mode. So when the phone is in usb restricted mode, IPR is not possible. USB restricted mode starts an hour after certain events like locking the device. If lockdown mode is enabled, usb restrictions are immediate after locking the device. It also activates when doing the button combination to enter sos mode.
Obviously there’s at least two flaws for IPR to even work in the first place (usb vulnerability and then being able to dump the passcode from somewhere which is very weird).
Secure Enclave timing delay
Apple’s platform guide says the delay is about 80ms and is due to iterations rather than a timer. Not sure which models this came in on but it seems to be at least from iPhone 12. Perhaps “supersonic” in their marketing material just means -12 attempts per second with a smart list of passcodes and no regular reboots required. Also clearly the secure storage component 2 (counter lockboxes) in iPhone 12 and above have put an end to brute forcing from then on.
My take on the slides is that iPhone 12 and above, on any iOS version, is safe if lockdown mode is on, or if lockdown mode is off is safe if it’s been an hour since the last lock or is put into sos mode (or rebooted and in bfu obviously). That said I hope they find and fix the IPR vulnerabilities…
Can’t seem to edit it again and want to post a correction..
Apple’s platform guide says it takes about 80ms to entanglement the passcode with the device UID and is due to iterations rather than a timer. Separately there are escalating timers for repeated failed passwords. Possibly, “supersonic” in cellebrite’s marketing material means -12 attempts per second by avoiding the escalating delay part but is still stuck with the 80ms iteration part.
Also clearly the secure storage component 2 (counter lockboxes) in iPhone 12 and above have put an end to brute forcing by hard limiting passcode attempts to 10 in a way that hasn’t been worked around by Cellebrite.
@DeletedUser115 A BFU extraction doesn't mean a typical extraction when the device is BFU, rather it is a special type of extraction to get a limited amount of data available by a device in BFU state. It's a weird misnomer and it could be more specific. If a forensics tool can brute force a device successfully from BFU, then they are performing an Unlocked extraction since they unlocked the device first.
With BFU you're booting into the operating system to decrypt it. A very small footprint of the OS is encrypted by the device and not by a user's own credentials.
A BFU extraction is to extract that particular data. Usually it provides very limited information about the OS and other device-encrypted data like app APKs (user/app data cannot be seen, only that the app is installed on a profile)
As described in the document they have a method of extracting that data for the stock OS, but not GrapheneOS.
DeletedUser115 What does it mean? I am reading "BF No" as secure element time limiter is holding up and prevents them brute forcing all possible PIN combinations.
If that's the case, what does "BFU Yes" mean? How they can extract the data in BFU state without knowing the PIN and without an ability to brute force it?
BFU Yes and BF Yes: Can extract the limited BFU- available data and could brute force the device to try and turn it Unlocked. Whatever the 'Unlocked' extraction capabilities are on the table follows afterward, but obviously you should expect it to be FFS.
BFU Yes and BF No: Can BFU extraction but not brute force to unlock the device.
AFU state in Cellebrite documents mean the device is in AFU state but is not unlocked / consent. If there is no BF support but AFU locked support is available, it implies a device has an exploit that can bypass. Example of this could be old lockscreen bypass vulnerability or iPhone IPR if there is no bruteforcing required for it.
I am not blocked after 5 attemps
"After 5 failed attempts, chip will add 30 second delay before next guessing attempt is allowed."
Grkrz Are they legitimate attempts? Trying to enter a 2 digit PIN when the minimum is 4 doesn't count as an attempt.
Matthai You can cross reference with @GrapheneOS 's post https://grapheneos.social/system/media_attachments/files/112/462/760/076/651/069/original/abb6bfdb2d3cbc6a.png They referenced IPR here. You can also ping @Hathaway_Noa He has access to the complete capacity list.
Nuttso Doing that would only make sense, if we manage to not expose the account credentials unencrypted, that are necessary to identify the account and be able route the messages to it.
For the google play notification version, the push notification token can be secured with NSFileProtectionCompleteUntilFirstUserAuthentication along with the temporary pending database to allow content preview while the permanent database can be secured with NSFileProtectionComplete.
Or if no message preview was required, everything except this push token can be secured with NSFileProtectionComplete because no message needs to be downloaded until the app was unlocked. This way, the only thing exposed in AFU is the push token which cannot be used to decrypt any past or future messages.
I'm not too familiar with the web socket implementation. But I assume only some sub-key is used for authentication rather than the master key? So only this key can be secured with NSFileProtectionCompleteUntilFirstUserAuthentication. Furthermore, even if the profile master key were to be compromised, it would still maintain forward secrecy if the chat database was protected with NSFileProtectionComplete
