That's just hilarious! Nice way of saying we got our hands onto one of these boxes, but we don't want to reveal how. It fell of a truck.
https://www.uspis.gov/wp-content/uploads/2020/02/FY-2019-ann... (p. 35)
See: https://news.ycombinator.com/item?id=26892180 https://news.yahoo.com/the-postal-service-is-running-a-runni...
Don't get me wrong, the implication is enough to discredit Cellebrite, but my initial thoughts are that either this bluff gets called, or there's a non-zero risk of someone landing in even hotter water down the line for using Signal. Of course, this assumes that you're not already neck-deep for having encrypted data and upholding your right to privacy.
Correctly me if I am wrong, but did they really say they were going to be doing active attacks against Cellebrite units? Also funny... but they probably are not actually going to be doing that.
If Cellebrite decides to punch a spiky rock they could have just not done that in the first place.
Yeah, but they probably figured they're not being attacked. But now? Now they'll have to figure they are.
- Cellebrite helps oppressive regimes read your messages
- Signal keeps your messages private
- Cellebrite announces "Signal support"
- Signal finds 9 years of vulnerabilities in Cellebrite
- Signal permanently pwns Cellebrite
You come at the king, you'd best not miss.
Additionally, I see from the video that the purported vulnerability is present in UFED version 7.40.0.229. There is nothing stopping Cellebrite from patching this purported vulnerability, and shipping trustworthy versions of UFED going forward.
If there is a concern that the purported vulnerability still exists, the burden of proof will be with the person claiming the vulnerability exists, for each new version of UFED. Cellebrite doesn’t even need to implement actual code, but merely increment the UFED version number. It will be an endless cat and mouse game driven by baseless claims from both sides.
Since this vulnerability has not been reproduced by third parties, it could be equally likely that Signal is using a psyop rather than exploiting a genuine vulnerability. In either scenario, it casts doubt on Cellebrite; the damage is done by convincing you, the reader.
Also, not disclosing specifics is reasonable here, given that the vendor is themselves known for using, hoarding, and selling access to 0days.
There is no obligation for a researcher to share their research with such a corrupt vendor.
As it stands, the vulnerability is not reproducible by anyone other than Signal. Reproducibility is key in the scientific method and in the court of law.
Couldn't Apple simply revoke the signature?
>Looking at both UFED and Physical Analyzer, though, we were surprised to find that very little care seems to have been given to Cellebrite’s own software security.
People keep saying this. It has never changed since the 90s. There is no bar to become a "software engineer".
If Moxie can get his hands on these devices and hack them, why can't Apple or Google, with all their resources, seem to be capable of REing them to fix the mobile device bugs they currently exploit?
Tinfoil hat perspective suggests they don't want to.
[1] https://www.phrases.org.uk/meanings/fell-off-the-back-of-a-t...
"In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software.[...]"
Does anyone find a package dropping off a truck and first take a picture of it, pick it up and go home to open it?
Even if someone picks up the package, usually taking a picture of it doesn't come to their mind. It's an unsual bit in the story. Unless, they went back and put the bag on the road to show that it was found just for the sake of "recreating the story" purposes.
How does something like a small briefcase just "fall from a truck"? By what mechanism? Briefcase would be stored inside the cabin.
If you're the author, can you explain my suspicion?
Assuming these files actually contain exploits. Maybe they do maybe they don't. You feeling lucky Cellebrite?
If you want to start trying to project human legality into the computing world, you're going to have a really, really bad time. Human legal logic and digital logic do not at all mix.
Things get even hairier with things like a hard disk full of a nation state's classified info, where a root terminal has been left open.
The computer will not argue a lick about producing those contents, but I assure you, someone else will most vigorously object.
And by CFAA, and everything else under the sun, Law Enforcement wants extra-priviliged access reserved for themselves which no inherent property of digital logic or programming need guarantee.
Practically implementing such programs/filesystems/systems-as-a-whole is an exercise left to the reader. As is the consequences of doing so in a particularly authoritarian leaning society at the moment.
> "For example, by including a specially formatted but otherwise innocuous file in an app on a device that is then scanned by Cellebrite, it’s possible to execute code that modifies not just the Cellebrite report being created in that scan, but also all previous and future generated Cellebrite reports from all previously scanned devices and all future scanned devices in any arbitrary way (inserting or removing text, email, photos, contacts, files, or any other data), with no detectable timestamp changes or checksum failures. This could even be done at random, and would seriously call the data integrity of Cellebrite’s reports into question."
They've may have just got a lot evidence collected using Cellebrite from phones with (or without) Signal installed on them thrown out of court.
I don't recall the details, but there was an absolute unsubstantiated speculative and surely fictional rumor of at least one entirely theoretical zero-day non-gif formatted image file that exploited a similar class of vulnerability in what was probably not a market leading tool used tangentially for the same purposes, floating around well over a decade ago as well.
I for one am very glad that these hypothetical issues have almost surely been fixed.
It attacks Cellebrite's ability to operate by casting doubt on the reports generated by the product that their customers may wish to use in court.
It places them in legal peril from Apple, and removes any cover Apple would have to not take legal action. (I assume someone at Apple knew they were shipping their DLLs?)
It makes a thinly-veiled threat that any random Signal user's data may actively attempt to exploit their software in the future and demonstrates that it's trivial to do so.
edited to add a bonus one:
Publish some data about what they are doing to help create a roadmap for any other app that doesn't want their data to be scanned.
Fortunately, parallel construction means you never really have to throw out bad evidence as long as you can find some good evidence too!
It reminds me of the story of https://en.wikipedia.org/wiki/Annie_Dookhan
The defense lawyers have to read it, and the people in law enforcement need to read the cases where judges throw out Cellebrite evidence based on that.
CoreFoundation is open source: https://github.com/opensource-apple/CF
libdispatch is open source: https://apple.github.io/swift-corelibs-libdispatch/post/libd...
ASL is open source: https://opensource.apple.com/source/syslog/syslog-349.1.1/li...
The objective C runtime is open source: https://github.com/opensource-apple/objc4/blob/master/APPLE_...
icu, pthread, zlib, and libxml did not even originate at Apple.
That does not make me feel good about Signal.
In contrast, it would strike me as strange if a Signal user switched to another messenger that allowed the data extraction because they were uncomfortable with Signal blocking it.
Last year I've managed to gain partial access to one of their systems and it took me weeks emailing their internal email addresses to finally fix the bug. They were total ass about it.
Now I've got complete access to their entire database and I don't know what do. Can HN advise?
So if the database is fingerprintable to the GP specifically in any way, they're very very dead. And the random username doesn't even count here; they probably didn't post from Tor, so their real IP is connected to this post.
I wish I could see those files in action...
"We have strict licensing policies that govern how customers are permitted to use our technology and do not sell to countries under sanction by the US, Israel or the broader international community."
And these policies are obviously quite effective at preventing such uses.
[1] https://www.theregister.com/2021/04/21/signal_cellebrite/
The official Cellebrite policy has always been "don't worry, if you get stuck, we can send you an expert to testify to the reliability of the scientific evidence due to previous cases" but what happens when the pyramid of previous cases fall apart? Do you suddenly own a paperweight?
I've also published papers (with NIST's help) on using consumer grade hardware for forensics and why testing your tools across a wide variety of scenarios is critical.
This purported vulnerability does not rely on FFmpeg, hence the disclaimer.
My fear, and prediction, is that the authorities will frame this as an even more egregious attack on law enforcement and that interfering with investigations is a crime (I'm not a lawyer, but I play one in hacker news comments, and that sounds like a crime). They'll lean on the app stores and the app stores will lean on or remove Signal.
2. Signal stirred FUD in a blog post. That's a very different thing from actually doing it.
I am SO IMPRESSED with this middle finger from the Signal team.
On the one hand:
> One way to think about Cellebrite’s products is that if someone is physically holding your unlocked device in their hands, they could open whatever apps they would like and take screenshots of everything in them to save and go over later. Cellebrite essentially automates that process for someone holding your device in their hands.
But on the other hand:
> We are of course willing to responsibly disclose the specific vulnerabilities we know about to Cellebrite if they do the same for all the vulnerabilities they use in their physical extraction and other services to their respective vendors, now and in the future.
If UFED just copies data from unlocked phones, why would they be using vulnerabilities to do so?
I guess my question is, is Cellebrite capable of copying locked devices, or more to the point - has vulnerabilities to unlock devices without knowing the access PIN?
Yes, they even brag about it in their marketing materials: https://www.cellebrite.com/en/a-practical-guide-to-checkm8/
That's a public vunerability, it's anyone's guess how many nonpublic ones they're using.
"Lawfully access locked devices with ease Bypass pattern, password or PIN locks and overcome encryption challenges quickly on popular Android and iOS devices"
"Required" to comment? By whom and for what reason?
Obviously there may be some backchannel, but that is probably how it would go if you assume Apple and Cellebrite have no relationship.
By stockowners who might not like their valuable IP used in this way or by this company without permission?
This, if Apple does pursue it, is a copyright matter, not trademark.
The "Physical Analyzer" is just a forensics tool. There are dozens of competitors out there that will take a phone and surface the things that might be interesting in a court case or law enforcement investigation.
The product Signal didn't talk about - which I think is the one they are upset about - is Cellebrite Premium. That is their service where law enforcement can send locked or damaged devices to their lab and get back a an image to load into PE. However in 99% of cases devices are either accessed because they are running old software with public vulnerabilities, or using the magic phrase "would you mind unlocking your phone so we can clear this matter up?"
Nailed it!
This will just prompt Cellebrite to improve its security process and sandbox the entire tool.
If they wanted to destroy the credibility of the tool, using the vulnerabilities to silently tamper with the collected data or even leaking it online would be a much better option and hit them without any warning, not only jeopardizing those cases but forever casting doubt on not just Cellebrite but their competitor tools.
Couldn't Apple now sue Cellebrite?
1) "..saw a small package fall off a truck ahead of me..."
2) The very last paragraph is just great!
Aren't Cellebrite products/services more advanced than that? I mean don't they use publicly unknown zerodays to extract data from locked phones?
"In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage.
These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software.
Files will only be returned for accounts that have been active installs for some time already, and only probabilistically in low percentages based on phone number sharding.
We have a few different versions of files that we think are aesthetically pleasing, and will iterate through those slowly over time. There is no other significance to these files."
That does not mean adding stuff like untraceable cryptocurrency payments or very publicly tweaking the noses of law enforcement, and bragging about how you're putting exploits in your app to hack them.
This isn't 1993 and the last thing we need is more pretexts to ban E2E encrypted apps in the countries where they're needed the most. I think this trades a moment's satisfaction for a very bad long-term outcome.
Mwahahahaha. Tell us how you hack our app and everyone else's, and we'll tell you how we hacked yours.
The middle finger is strong with this one.
Curious if there'll be a response of sorts.
Pretty sure it's the former, since the above is a way to ensure that Cellebrite can't just gather all implied exploit files and make sure they've got those specific problems all patched. This is, quite literally, an informational attempt at guerilla/asymmetric warfare, where Signal is trying to make engaging with them too costly, while also making a few blows quite a bit above their weight level. Cellebrite now has to decide whether to keep after this adversary that both is hard to pin down, ambushes them, and has shown it can hit them really hard where it matters (credibility, and thus their pocket book).
They are basically putting the threat out that if you use Cellebrite on Signal in the future, you might not get the data you expect, and at worst, it may corrupt the report/evidence.
This also brings into question the chain of custody, as an untrusted device being imaged can alter reports of unrelated devices.
It's as though Theo decided that OpenSSH should respond to portscanners by trying to pwn the source systems.
I think what he meant to say was that if Cellebrite is used on your locked phone it could be the equivalent of a person having your unlocked phone in their hands where they can do whatever they want. Only cellbrite doesn't do look at random things, it grabs everything.
Cellebrite devices are also frequently used by phone carriers to image your old phone and transfer the data to your newly purchased phone, to give you a clearer idea of what they can do.
Sandboxing doesn't really help. The problem isn't that the tool is used to infect the rest of the system, but that the tool itself is compromised, the reports it generates are compromised, and and past reports may be compromised. Unless you're pushing that data outside the sandbox (which is a hole in the sandbox, and while much more limited might also be an exploit vector or a way to cause problems in the data) it's still fair game if the sandboxed tool is compromised.
There's multiple reasons to disclose it. First, because as another comment noted it attacks the credibility of the company, and credibility is very important for tools used in court.
Second, because their main goal is to protect Signal, not attack Cellebrite. Making Signal a problem to attempt to gather data about will possibly make them just blacklist Signal as an app they gather for. This could be temporary, but since Signal alluded to many exploits and that they have a bunch queued up for the future, it will always be a risk for Cellebrite to attempt to gather info from Signal, so they might just continue to skip it.
The process of e-discovery is rife with risks of this sort. When you forensically collect data from a random set of devices from a party that may or may not have porn, HIPAA, GDPR, sample viruses, malware, who know what all.
The short version of it even if the inhaling of this data crashes the device, there are mitigations and protections that will allow the evidence to be ultimately produced.
A crash of the windows host in collection will not invalidate the case.
disclosure: ex-CSO of Relativity, leading provider of e-discovery software.
edit:
One thing they could try to do is to sandbox the parser itself to lower attack surface area... but the damage is done here and I really doubt they will win a security tit-for-tat with Signal.
IANAL but I could imagine Cellebrite has existing or pending litigation where this disclosure upsets their position.
I assume Apple will choose to file for copyright infringement than risk being accused of collusion and lose the copyright on that iTunes or parts of it.
> When Cellebrite announced that they added Signal support to their software, all it really meant was that they had added support to Physical Analyzer for the file formats used by Signal.
Your case is valid about potential judiciary impact, but it would require for Signal to monitor cases involving Cellebrite and step forward to help the defense while unprompted to do so. Furthermore, Cellebrite clients seems to include entities that do not care so much about a fair trial.
Silently tamper with the data might cross a legal line. doing this might put at risk current or past cases where there is a legitimate reason to use this sort of tool.
Privacy can be hard. While i 100% defend everybody has the right to privacy, i can also see the need for the capability to break it. Maybe the answer for this is a very tight regulation around the uses of this kind of hardware/software, but that regulation would have to keep up with the pace of technology
i've always wondered if there could be a cryptographic solution to this. issuing decryption keys to governments seems rife for abuse, but some sort of multi-party situation where governmental and non-governmental entities have to cooperate (with actual multiparty key material) to perform a decryption authorized by warrants- with said non-governmental agencies acting as a check on usage of those warrants, their frequency and the eventual publication of their usage could be an interesting approach.
personally i think strong encryption should be a requirement for digital evidence, but even that can be forged.
strange times we live in.
And it doesn't destroy the credibility of the tool to silently mess with its data. People have to know it's happening.
I'm trying to understand the risk profile here.
I guess I see the value for, e.g., a border crossing, where they can inconvenience you and ask you to unlock your phone, but instead of flicking through your messages briefly, they authorize a pairing and quickly backup your entire disk content. You expected a quick perusal by a human, but unknowingly gave them a lot more. If you've blocked pairing, they can't get nearly as much data as quickly.
But if you're being investigated for committing a crime, everything we think we know about device unlocking is still true, right? They'd need me to unlock it before it'd trust a new device to pair to, and they'd need a court order to get me to unlock it for them. Five quick taps of the power button and biometric unlocks are off--now they need my passcode.
Perhaps there's still value, even in that case, in that if I were compelled via court order to give my passcode, they still can't quickly / easily dump the disk contents from a device pairing. Although I imagine if you have the passcode there's probably many other ways of accomplishing the same result.
Well, mostly yes, that's considering Cellebrite doesn't have 0-days or other exploits which can send a SMS to the device or similar things. Using Cellebrite's software you can also send silent SMS, so it's not far off either.
A german Cellebrite ambassador showed me and colleagues the mentioned tools of the blog post and told us he participates at Law Enforcement raids. At 6 in the morning they raid the houses of the suspects, detain them and immediately ask for PINs and passwords. He said that surprisingly often it works and no further decryption tries have to be performed.
In the US that won't work if unlocking the device requires a password or pin. In practice, you can't be compelled to provide that unless you openly admit that you know it. (Even then, the 5th amendment might afford you some protection.) YMMV, IANAL, etc.
That being said, I agree with you 100% on the cryptocurrency payments issue and think that was a misstep on their part.
The reason I want e2e encryption is because I want control of my devices, control of my information, control of what's going on. It's not Moxie's phone to drop random files on to, regardless of purpose. It's my phone, and I consider programs that are doing things that I'm not aware of malware.
(Admittedly, Android is rife with stuff I don't want going on, so it's not really my phone, it's Google's and Motorola's and a bunch of other entities who have their tentacles in it, but still...)
Maybe the last paragraph is a joke, and they have no intention of randomly placing files on unwitting client machines. It's open source, so I could compile the client myself and make sure it's not doing anything funny. What a pain though. At that point, so much trust is lost in the organization and codebase that really I need to find some other messaging protocol / app / network.
Signed by Apple's key!
I would be willing to consider a solution where you need to have agreement from the UN Security council (maybe just the permanent members) in order to decrypt whatever you want. If you can get those countries to agree, it's probably important.
Not clear which the parent was talking about. Maybe both?
Now imagine if Hack Back laws actually passed... companies like Whisper Systems would have had impunity for even more shenanigans :)
Must have been a turnip truck https://twitter.com/KimZetter/status/1384936715769503745
That's a dig at the turnipesque savvy of Cellebrite, which royally stumbled into this.
cf. https://www.dwt.com/blogs/privacy--security-law-blog/2015/03... > FCC chair Wheeler said the FCC “didn’t just fall off the turnip truck.” Through CALEA, CPNI, and CSRIC, Wheeler said the agency has been working to protect consumer privacy.
https://www.phrases.org.uk/meanings/fell-off-the-back-of-a-t...
I think this taints any phone having Signal installed.
But also users don't know now if their systems will explode if they try to gather Signal (or other app) data.
There may be mitigations, but without knowing the full details of the exploit, it sounds a lot like reasonable doubt to me. A good lawyer would spin it exactly that way, putting any cases without sufficient corroborating evidence in jeopardy.
There are a whole set of rules about challenging evidence, including electronic evidence. Keep in mind that the other side gets a crack at it also. It is unlikely that the whole case would be thrown out because of a corrupted file. Reasonable doubt is not part of the forensic process--this is what a jury needs to consider to render a verdict.
As pointed out elsewhere, many uses of this tool are extrajudicial.
That isn't the point being made here. The data could have been compromised at the point of when it was gathered, not any time later.
So whether they're fetching aesthetically pleasing files would be easy to tell, but trickier to tell if those files actually have payload.
> Files will only be returned for accounts that have been active installs for some time already, and only probabilistically in low percentages based on phone number sharding.
You would have to have an already existing Signal account that's been around for some time and hope you get sent one of these files.
And prior extracts on the device.
It's a method that crooked law enforcement uses to deceive courts. It's so common as to have its own name now.
If I search a phone with a tainted UFED and get a conversation between Bob (my subject) and Carl (his friend) about the drugs they're selling, that conversation either exists or doesn't exist. Now, let's assume that the court won't accept this evidence, based on a defense argument that it should be inadmissible after seeing the vulnerabilities of UFED, as detailed by Signal.
The next investigative step in to go interview and search Carl, since there is probable cause to believe that a conversation occurred about their drug dealing on his phone. Unless I a) know my UFED is vulnerable and b) have reason to believe the text conversation between Bob and Carl is fake, my warrant for Carl's phone is valid. Now, I search Carl's phone with the same UFED and find the exact same conversation.
At this point, it's still possible for the UFED to have made the conversation up on both sides and for both extractions, and this would probably make the resulting conversation (and potentially everything in the report) inadmissible, but any admissions from Bob or Carl, including based on questions asked about the conversation itself, would still be admissible. I could show the report to Bob and Carl as evidence against them and get a confession, which would be admissible. Additionally, if the court determines that the UFED report is inadmissible based on the potentially for it to be forensically unsound, I would still have the phones themselves. UFED (except in rare circumstances) requires the phone to be unlocked before it can make its extraction. As such, I could manually browse the phone to the conversation in question and take photos of the phone with the real conversations between Bob and Carl. I could also verify through an ISP/messenger app that evidence of those conversations occurred (for example, metadata demonstrating matching times and message sizes that align with the potentially-fabricated message).
The FOTPT defense only applies to illegally obtained evidence. Assuming you obtained a valid warrant or consent to conduct the search, there was nothing illegal about the UFED extraction that would make the FOTPT defense applicable.
~~~ The undated documents show that federal agents are trained to “recreate” the investigative trail to effectively cover up where the information originated, a practice that some experts say violates a defendant’s Constitutional right to a fair trial. If defendants don’t know how an investigation began, they cannot know to ask to review potential sources of exculpatory evidence - information that could reveal entrapment, mistakes or biased witnesses. ~~~
If you believe any of "fruit of the poisonous tree" stuff makes any difference, I've got a bridge to sell you. There is clear evidence that DEA agents are trained to create a "clean" story of evidence around the illicit information they get.
[1] https://goldsteinmehta.com/blog/can-the-police-force-you-to-...
Even then, I believe there would still be the additional issue of demonstrating that the defendant actually knows the password. Which is why I previously mentioned that if you openly admit to knowing the password then you likely have a problem. (This came up in a case where the defendant admitted to the FBI that he was capable of decrypting an external hard drive but refused to do so because "we both know what's on there".)
The unclear part seems to be how strong the evidence needs to be that the device is yours and that the evidence is on there. In this case, his sister testified to both. But would it be strong enough with forensic evidence alone? Unclear.
> As far as I understand things you've lost the case by that point anyway.
Perhaps, but there may still be significance to what's on that drive. There may be incriminating evidence there for other crimes for which you're not yet being prosecuted.
> Even then, I believe there would still be the additional issue of demonstrating that the defendant actually knows the password.
They're saying the sister's testimony was sufficient to prove that he knew the passwords previously.
Proving present-day capability to decrypt doesn't seem to be necessary, at least in the article I linked.
> The federal court denied the Motion to Quash and directed Doe to unlock the devices for the investigators. Doe did not appeal, but he refused to unlock some of the devices, claiming that he had forgotten the passwords. He was eventually held in contempt by the District Court, and the Court ordered that he remain in federal custody until he was willing to unlock the devices.
The accused claimed he could not decrypt the hard drive because he had forgotten the passwords, but he was still being held in contempt.
No amount of certainty about Marlinspike's actions should comfort Cellebrite, though, because Moxie Marlinspike isn't the only person allowed on the app store.
No need to tell the court how you found out about the lawnmowing for the neighbour that was never reported to the IRS...
Not to mention regimes that don’t actually care about things like evidence being “legally admissible”.
More realistically it is like dropping a file on your private file server DONT_RUN_THIS_BLOWS_UP_YOUR_COMPUTER.exe. You never run it, but maybe somebody exploits your file server, gets all your files, and automatically runs them?
Oh well.
Of course, if some criminal exploits your file server, they are not likely to press charges, but if it triggers on law enforcement who have a warrant to scan your fileserver, that's a different issue.
You'd be just as liable as for physical boobytraps on your property, with pretty much the same reasoning.
They have to use the exploit to figure out if the phone can nuke that hardware's usability in the future or integrity of any locally stored, non-offsited data.
UNLESS Cellebrite can produce publically for a court of law proof that any potential exploit isn't a valid concern, which means spilling implementation details about how the device works.
Nobody can continue to shut up AND maintain the status quo. Either everyone clams, and Signal can sow reasonable doubt without challenge, crippling Cellebrite's value as a forensic tool. Or someone has to open up about the details of their tool, which, like it or not, will speak very loudly about the ways and methods behind these exploits.
The Checkmate is implied, and oh my, is it deafening.
Liable for what? You haven’t promised that the code is safe, and they chose to run it.
> there's no significant difference from active retaliation
There is a significant difference, in active retaliation you choose to attack someone elseks computer, with a trap file the attacker chooses to run files they have stolen from you. Big difference.
> You'd be just as liable as for physical boobytraps on your property, with pretty much the same reasoning.
The reasoning is different, lethal or injurious man traps are prohibited because you don’t respond to trespassing with lethal force and you don’t know who or what may trigger the trap. Man traps that lock the intruder in a room without injuring them are fine, and used in high security installations.
The insinuation that my device may be host to something potentially malicious is concerning. It gets a little worse that it can change, without notice. I'd tend to trust Signal and their security, but the potential for that mechanism to be hijacked is always present. They've certainly made it hard, though, and I think the folks at Signal are probably clever enough that my anemic observations don't tell the whole story.
Do you use an iPhone or a phone with Google Play Services on it?
Those both have the technical capability of receiving targeted updates.
The principles of laches may still apply and provide a defence for Cellebrite if Apple makes an "unreasonable delay".
For example, let's say they extract the Signal message data from your phone. You successfully convince everyone that this data might have been the result of some tampering. However, that doesn't prevent investigators from using that message history to find the other person, and get them to testify against you.
That’s not a guarantee, of course, and it could be possible for police to corroborate that you had contact with someone else in another way (through records from a wireless carrier or by doing shoe leather investigative work) and use try to get data on that person to get them to testify, but if their only link was through messages that had been deemed inadmissible, they can’t use that witness.
The more likely question in a scenario you describe would be if the compromised Signal data would be enough to raise questions about the validity of all the data on the device. I.e., if Signal is out, can they use information from WhatsApp or iMessage or whatever. Past case law would suggest that once compromised, all of the evidence from the device is compromised — but a judge might rule otherwise.
It would be cool if Signal or another app could use those exploits they’ve uncovered to inject randomized data into the data stores of other messaging applications too. You know. Just as an experiment.
In the example being discussed here, it's absolutely still fine for LE and there isn't a need to find a secondary source that side-steps the FOTPT argument. In fact, I could drag a subject into an interview, take his phone and present a warrant to search his phone.
If he refuses to unlock the phone, I can say "fine, we'll use our special software instead" and take it back to another room. After the interview, I give him back his phone and immediately bring in his co-conspirator. If I show the conspirator fake messages between him and my first subject and get him to testify against my subject, that's still admissible. If this is the case, why would using potentially-false/unverifiable Cellebrite data be inadmissible?
Cellebrite has never claimed any particular exploits in Signal. Signal is exploitable in this particular way for entirely obvious and common reasons.
In computer forensics it's ALL about being able to verify, without a shadow of doubt that something is what they say it is. Chain of custody rules everything. This blasts a huge gaping hole in all that. He's proven that chain of custody can be tampered with and undetected. Files can be planted, altered or erased. Reports can altered. Timestamps can be changed. The host OS can be exploited. It calls all past and future cellbrite reports into question. Cellbrite can no longer guaranty their software acts in a consistent reliable verifiable way. It leaves doubt.
Mostly. The other side gets all the evidence that the opposing side sees. They both get a chance to review it.
> Chain of custody rules everything.
Agree.
> This blasts a huge gaping hole in all that.
Not really. The analysis goes in two steps. One is to pull all the data from the phone, in a chain-of-custody manner. In an adversarial case, both sides can do this.
The collection and analysis go into two steps. First is moving the data to windows box. Next is the analysis. As I understand it, the analysis portion is where things can explode. Then, if in the hands of someone skilled in forensics, the extracted data would be saved in some other device, possibly to be shared with the other side. Then the risky, potentially explosive analysis would be done. It is very unlikely that all previous cases exist on that device and nowhere else.
Therefore,
> It calls all past and future cellbrite reports into question.
is not true, as the extracted files are likely not on the collecting windows device.
In any case, it is not clear how many uses of this device are in actual legal environments.
95% of all criminal cases in the US are Plead out largely because the defendant can not afford competent legal representation
This is why all kinds of questionable investigative tactics are still used even some that have clearly been ruled unconstitutional, they know most of the time it will not matter, they just need to get enough to make an arrest, the system will destroy the person anyway no conviction needed, and most likely the person will plead guilty even if innocent just to make the abuse stop
If evidence is obviously (or with high chance) disputable, then it puts pressure even in those cases where the attorney recommends the defendant to eventually plead.
Or maybe the attorneys available to those who can't afford are just crap in general?
In theory yes, but in most cases that will be a overworked lawyer that has 100's or 1000's of other active cases, and will not spend time other than negotiation the best deal.
Even if you happen to get a good public defender that has the ability to devote lots of time to your individual case, they would have no budget to hire an expert witness to present the vulnerabilities in the Cell-bright software to a jury
Your best bet would be if the ACLU or EFF took an interest in your case, but they take on very few cases relatively speaking and tend to focus on precedent setting cases, or cases that have high public interest (or can be made to have high public interest)
>Or maybe the attorneys available to those who can't afford are just crap in general?
In some cases they are incompetent, however in most cases they are just underfunded and massively over worked. In most jurisdictions the public defenders office is funded is 1/10 or less of what the prosecutors office is funded at.
Consider https://www.securityweek.com/forensics-tool-flaw-allows-hack.... Have any cases been thrown out? I don't think so.
The 5th amendment protects you from having to testify against yourself, but it doesn't protect you from having to turn over incriminating evidence against yourself. The 4th amendment protects your stuff, but only up to the point of requiring probable cause for a warrant.
At issue in these sorts of encrypted storage scenarios is whether you would be incriminating yourself by demonstrating that you know the password. Knowing the password for an encrypted device basically proves that it's your device, so forcing you to decrypt a device would amount to forcing you to testify against yourself in the event that there is doubt about whether the device is yours.
So to force you to decrypt a device there needs to be a warrant for the contents, and it needs to be no doubt about the fact that it is indeed your device. So it needs to be a foregone conclusion that the device is yours, but only requires probable cause to believe that something specific and illegal is stored on the device.
I think it originated with "RTFM" which was an old unix admin way of saying read the fucking manual (or man page).
Edit: looking up a bit more, it seems like this idiom is used to denote goods sold for cheap because they were stolen. Like "Bob is selling genuine iPhones very cheap, I fear they fell from the back of a truck".
Edit edit: I initially took it as "we won't tell how we got this", because I didn't know this idiom, but it seems several people agree with this interpretation. Not necessarily stolen, but obtained from an undisclosed source.
Perhaps even in a faraday cage..
One of the screenshots[0] shows the VMware Tools Service running, so yeah, looks like a virtualized guest.
[0]: https://signal.org/blog/images/cellebrite-dlls-loaded.png
lol
And Signal can develop a few land mines to deploy at any time, and just... hold on to them for a rainy day.
At some point if someone breaks through multiple levels of advanced security to, say, steal your gun and then shoot themselves in the face with it, whose fault is that really...
It's not signals job to secure 3rd party software, that's entirely on the 3rd party.
It's not Signal's job to secure third party software, they can intentionally post incompatible data, but it definitely is their job (just as everyone else's, mandated by criminal law) to abstain from any activities that would tamper with evidence. If that incompatible data isn't limited to randomness or crashes but contains, quoting the article "a file that executes arbitrary code on the Cellebrite machine" or "undetectably alter previous reports, compromise the integrity of future reports (perhaps at random!), or exfiltrate data from the Cellebrite machine" then it obviously was intentionally made that way, which crosses the line and at that point yes, it's definitely Signal's fault. If that gets actually executed on a machine owned not by Signal but e.g. some law enforcement agency, then Signal and any involved developers personally may face criminal charges.
It does not even need to involve any computer specific laws (though those are also likely to apply) - if there's an incident where evidence got disrupted, if there's evidence that this incident was caused by "aesthetically pleasing files" developed by Signal, and there's some evidence (e.g. this blogpost) that they made these files knowing that they might result in other evidence being destroyed - that's completely enough, that's tampering with evidence, a felony. Go directly to jail, do not collect $200, don't expect sympathy from law enforcement and the legal system.
In my personal opinion this is all FUD and scaremongering, because actually doing so carries little benefit and high risk for Signal. But, of course, no one can be sure.
If you can't figure out a way to satisfy your desire for your devices to be resistant to surveillance tools with legal means, well, then you can't satisfy that desire.
Furthermore, not only the ends don't justify the means, the ends can be prohibited too - if you explicitly design something to destroy your own data knowing that this data would get used in a criminal investigation, that may be a crime on its own (tampering with evidence/obstruction of justice, location matters of course); you don't have to testify against yourself, but destroying evidence is a crime even if it's your property (e.g. throwing your gun into a river after a shooting so it wouldn't be found) and furthermore in that case the court may be allowed to assume that the destroyed evidence was unfavorable to you, that the data contained the damning things they expected to find there - so if you want to protect your devices from surveillance tools operated with a legal warrant, you might want to consult a lawyer to find out if that's a good idea in your jurisdiction, it may well be worse for you than doing nothing.
I fear this part of your argument is fallacious. A peaceful and hilarious response to an abuse is not illegal. An if it is, it should not be. This post just highlights how petty the means and methods used by "some companies" are. Moxie is rightfully mocking Cellebrite and its customers, and it's fantastic.
About the obstruction of justice... If governments around the world are having an appetite for abuses, we shall not fall for it. There are other ways to get to criminals. Tell state officers they can do their job without abusing the private sphere of citizens.
It's Cellebrite devices that should be made illegal, because "justice" should not depend on surveillance tools. Just days ago the same US IC shared a memo/report about the rise of authoritarianism and how western democracies are threatened by it. Let's stop this double standard.
As for tampering with evidence, your claims are certainly overbroad, otherwise one could consider Signal's vanishing messages and deliberate lack of logging to be tampering with evidence. In any case, an individual is hardly responsible for those actions; they presumably did not deliberately seek to destroy Cellebrite data since Signal may choose to do this entirely at random.
This very blog post says they have found similar vulnerabilities in both steps.
Exploits may fuck up phone, backup and even cellebrite host os.
As such, phone, backed up data and reports are useless going forward.
[0] https://www.law.cornell.edu/wex/fruit_of_the_poisonous_tree
I think the police have been using "parallel construction" to get around that for some time.
https://en.wikipedia.org/wiki/Parallel_construction
> Parallel construction is a law enforcement process of building a parallel, or separate, evidentiary basis for a criminal investigation in order to conceal how an investigation actually began.[1]
> In the US, a particular form is evidence laundering, where one police officer obtains evidence via means that are in violation of the Fourth Amendment's protection against unreasonable searches and seizures, and then passes it on to another officer, who builds on it and gets it accepted by the court under the good-faith exception as applied to the second officer.[2] This practice gained support after the Supreme Court's 2009 Herring v. United States decision.
Now, that's not to say that cops wouldn't do this in order to finally get a case around a particular subject who was able to sidestep previous investigations or something. I just doubt that it happens often enough to be worthwhile.
A report doesn't have to be generated by PA. A forensic examiner is free to use other methods to examine the binary. So long as the examiner can explain all the actions and any artifacts that would be left behind.
Plus, most law enforcement seizes the device and keeps it until after the trial. If there were valid arguments against the authenticity of data in the extraction report, it would be easy to verify that data's existence by checking the phone, re-extracting the data using a known-clean UFED, etc. This isn't the end of the world by any means for legal mobile device searches.
In the Metzler kidnapping case the first confession was not admissible in court which had been obtained under threat of torture.
For the UFED Touch, for example, the device runs the extraction and saved the result to a flash drive or external drive. This is then reviewed with the UFED software on another machine (laptop, desktop, whatever). What you're describing would mean that the extraction takes place (one-way. The Touch requests an ABD or iTunes backup process, phone responds with the backup files). The the malicious file in the backup pops and executes a command that runs software on the phone, thus infecting the phone with false data to cover the tracks and make the data on the report match the device. This is unreasonably complex, and I doubt any judge would accept it as enough to consider the data inadmissible. Let alone the fact that the data likely exists elsewhere in a verifiable way (Facebook Messenger, WhatsApp, Google Drive, etc), which the initial extraction results should give probable cause to the cops to obtain.
