FBI Agent: Decrypting Data 'Fundamentally Alters' Evidence (vice.com) 89
Joseph Cox, reporting for Motherboard: An FBI agent has brought up an interesting question about the nature of digital evidence: Does decrypting encrypted data "fundamentally alter" it, therefore contaminating it as forensic evidence? According to a hearing transcript filed last week, FBI Special Agent Daniel Alfin suggested just that. The hearing was related to the agency's investigation into dark web child pornography site Playpen. In February 2015, the FBI briefly assumed control of Playpen and delivered its users a network investigative technique (NIT) -- or a piece of malware -- in an attempt to identify the site's visitors. [...] According to experts called by the defense in the affected case, the fact that the data was unencrypted means there is a chance that sensitive, identifying information of people who had not been convicted of a crime was being sent over the internet, and could have been manipulated. (Alfin paints this scenario as unlikely, saying that an attacker would have to know the IP address the FBI was using, have some sort of physical access to the suspect's computer to learn his MAC address, and other variables.)
Re: THIS case? (Score:4, Insightful)
You can't pick them like that - you have to use the case that raises the question most directly. And it's always the degenerate undesirables that are used to expand police powers to the detriment of civil society.
Re: THIS case? (Score:5, Informative)
Encryption != Integrity (Score:3)
Can we please stop using 'encryption' when we mean 'integrity'. They are not the same thing.
TFS is arguing that integrity has been compromised by removing encryption. BS.
Re:Encryption != Integrity (Score:5, Funny)
Hillary Clinton has no encryption.
Re: (Score:2)
Right.... decrypting does NOT compromise Integrity; so long as the decryption key used is correct AND the decryption method used is the exact reverse of the method originally used to encrypt.
# ls myfile.encrypted /usr/local/FBI_Files/Other_File_To_Plant > myfile.decrypted
# Cat
Does not count as proper decryption. If the decryption algorithm is "Insert spurious data here", then in that case, Integrity is compromised.
Re: Encryption != Integrity (Score:1)
Remember the big fuss over DVD keys, and DeCSS, that little bit of code that would unlock region specific DVDs. This bit of code was made illegal to own. Yet it could be reconstructed anywhere without any information being transferred simply by generating a particular prime number (the "forbidden prime number"), saving it as a binary file and then unzipping it. By sheer luck the unzip utility would skip over the unwanted bytes at the end of the file and reconstruct the source code.
Re: (Score:2)
Technically it does because from the human jurists point of view. Data goes into magic decryption box and data comes out of magic decryption box and the data is different, how different, hugely different, in fact so different one encrypted file could have gone and another completely different file could come out and not the decrypted other file, just a whole new file, one slipped into the magic decryption box. Likely to remain valid the encrypted file should be submitted and then decrypted with a open sour
Re: (Score:2)
However, this is no justification for not encrypting.
After all, you can send ENCRYPTED FILE plus FINGERPRINT+MESSAGE DIGEST OF ORIGINAL DECRYPTED FILE digitally signed.
Then you can have your audience copy the message digest And the decrypted file, and satisfy themselves that the decrypted file has the same message digest as the one calculated and sent alongside the original encryption process, and then verify the digital signature.....
Re: (Score:2)
Technically it does because from the human jurists point of view. Data goes into magic decryption box and data comes out of magic decryption box and the data is different
Same deal with any lab test or forensic data extraction, even if the data is not encrypted.
You need multiple independent cryptoforensic experts or experts working for both defense and prosecution to Testify under oath that they've used the supplied/available keys to decrypt and/or extract the data, And the process used is sound.
Unde
Re: (Score:2)
Under penalty of perjury, don't make me laugh, hah hah. There have been repeated and not a little but a huge incidence of perjury being committed by the authorities, exposed and with no prosecution, just a, tut, tut, don't get caught next time, tee, hee. They jury is bound by honour, oath and integrity to verify the validity of the information provided as best a possible. All evidence should be presented in a clear and unambiguous fashion, not a secret vouched for by vested interests. Yeah, sure they will
Re: (Score:1)
Can we please stop using 'encryption' when we mean 'integrity'. They are not the same thing.
TFS is arguing that integrity has been compromised by removing encryption. BS.
It's probably quite difficult for a layman to differentiate between cryptographic algorithms and what they actually are for. As in the difference between cryptographic hash function, asymmetric crypto and symmetric crypto. Not to mention how something like Diffie-Hellman functions.
It's not even all that easy to understand them as a software engineer, unless you spend quite a while with them. Personally, someone paid me to develop a functional obfuscated crypto core so I have a understanding of a few algorit
Re: (Score:1)
It's probably quite difficult for a layman to differentiate between cryptographic algorithms and what they actually are for.
It's probably quite difficult for a non-layman too. How do you prove that the result of decryption is equivalent to the original text?
Imagine simple XOR encryption. If you allow a key-size that is the same size as the data length it is trivial to generate a key for each that when applied creates the same result.
If you try to brute force that encryption you will probably encounter a large amount of other legible texts before you encounter one of the two original texts.
Can you prove that this isn't possible w
Re: (Score:2)
Re: (Score:1)
Erm, no.
Given an xor one-time pad algorithm, you can hand me a ciphertext and any arbitrary plaintext, reasonable-looking or otherwise, and I will hand you back the pad that will decrypt that ciphertext to the plaintext you provided.
In other words, given that algorithm, it is absolutely mathematically feasible for someone to say 'Here's the ciphertext and here's the key I used', while lying about it being the key they used, and have the ciphertext 'decrypt' to whatever reasonable-looking plaintext they want
Re: (Score:2)
>Given an xor one-time pad algorithm
You don't use OTPs for signing.
You don't use OTPs at all, they don't solve the key management problem.
Please keep up.
Re: (Score:2)
I know what an OTP is. An OTP uses XOR. 'XOR' OTP is just a redundant way of saying OTP.
The context was TFA talking about undermining the integrity of evidence.
Encryption through an OTP or ECB, or CTR or CBC or any other privacy mode does not ensure integrity. There never was a question about that. Stating that you can undermine integrity of a non-integrity mode is tautological.
What is appropriate to require is second preimage resistance. The article really has someone arguing that the process of evidence d
Re: (Score:2)
True, but I see the point -- you still have to show that you've done that. You still have to show that the plaintext is, in fact, a result of the ciphertext when a transformation is applied using a given key and not just some plaintext that you've invented.
Re: (Score:2)
Re: Maybe it de-alters it. (Score:2, Informative)
And thats what most people who dont understand encryption would say. Unfortunately you completely mis understand the mechanisms being used and a binary blob can decrypt to multiple different data sets depending on key and method. Its pretty much impossible to deduce after decryption whether the result is the same as the original or if the result is alternative output.
You can get a binary blob to decrypt to pretty much anything you want by being inventive with keys and algos. Like you, courts have a hard ti
Re: (Score:2)
And thats what most people who dont understand encryption would say. Unfortunately you completely mis understand the mechanisms being used and a binary blob can decrypt to multiple different data sets depending on key and method. Its pretty much impossible to deduce after decryption whether the result is the same as the original or if the result is alternative output.
You can get a binary blob to decrypt to pretty much anything you want by being inventive with keys and algos. Like you, courts have a hard time understanding whats going on.
Just like you can decrypt the encoded contents of a bookie's notebook to frame anyone you like as a bettor.
"Special" Agent needs remedial forensics training (Score:5, Insightful)
“[Had that data been encrypted,] It would still be valid, it still would have been accurate data; however, it would not have been as forensically sound as being able to turn over exactly what the government collected,” Alfin said.
Which is such utter BS its hard to credit. I figured the summary was just the usual flame bait, but unless the article is misquoting the agent that is pretty damning.
Hint: if the hash of the data before and after it is sent remains the same then that satisfies one of the requirements to being forensically sound (specifically, the data will be "accurate" -- unchanged since collection). Does the "special" agent think running it through an SSH tunnel would have altered the data? How about over a VPN connection? Does he not realize that the data was *shock* modified during transit (encapsulation at the very least, quite possibly encoded depending on the nature of the physical links along the way). What a moron.
By his reasoning all digital data is forensically unsound because spinning platters *encode* the data (hint, it isn't the bits and bytes you might think, longer story has to do with run length synchronization issues). And *encryption* is a particular means of *encoding*. So if encryption is "the bad" because it transforms data then all encodings are bad because they all inherently transform data.
Re:"Special" Agent needs remedial forensics traini (Score:5, Informative)
If the data is sent as cleartext, it becomes much, much easier for an attacker to alter the cleartext into a different form which contains a plausible message yet generates the same hash. There's an entire branch of cryptography [wikipedia.org] dedicated to these types of attacks.
If it's transmitted while encrypted, the attacker (assuming he can't break the encryption) has no way to verify that his altered ciphertext which generates the same hash still decrypts into a cleartext message which makes any sense in the context of the original cleartext, much less has been altered to his liking.
While it's not required that this sort of data be encrypted before transmission, it is prudent to do so whenever possible. It drops the chances that the data has been forensically compromised from very small to vanishingly small (it is easier for the attacker to break your encryption).
Re: (Score:3)
To be properly forensic the data should be hashed on the source machine and the hash verified on the destination. Not doing so is a failure in due diligence and introduces an implicit logical gap in the chain of custody. Now, the reality is that the obligation lies with the defense that something happened causing the data to be altered. And it sounds like they are trying to go that route. It just isn't a realistic defense (meaning it has about a snowball's chance of succeeding).
The real reason for encryptio
Re:"Special" Agent needs remedial forensics traini (Score:4, Informative)
Sorry, I didn't read your whole post so my answer is incomplete. While collisions can be generated, for even semi-modern hashes they involve more than just data changes (e.g., the size of the data is changed as well). A digital chain of custody will record both the hash and the size in bytes. And that does not alter the fact that the burden of proof lies with the defense when making allegations of alteration. That is, the allegations must be specific -- not just a general hand waving that "something could have happened". There is a presumption that evidence has not been tampered with. Breaks in chain of custody are not uncommon and normally have no impact on proceedings other than some additional testimony.
Furthermore, hash collisions are not considered to be an issue by the courts. Fingerprints have a far far greater risk of collision (or simply misidentification) than say md5 and law enforcement has done an effective job of convincing the courts that *fingerprints* are unassailable evidence and now with hashing being vastly better it is considered completely irrefutable.
Again, the purpose of encryption is to protect confidentiality, not provide integrity. While it may have some impact in that regard it is a side effect. Integrity measures (such as documenting the chain of custody, hashing evidence on collection, etc.) are what provide that.
Re: (Score:2)
How many different plausible messages that indicate you're into child porn are there? Much less than possible hashes? Because one of them has to have the same hash as the original message for this attack to be even possible.
Re: (Score:2)
Re: (Score:2, Interesting)
Not necessarily disagreeing with you here, but after reading the article I could see something to the FBI's arguments.
My understanding is that in this case, the FBI took over Playpen. Let's say that you go to visit Playpen. The FBI has an encrypted record of your visit, which only it has the keys to. How can you counter the evidence supplied by the FBI? What if the FBI's "encryption" method actually spits out false data?
Not the same, and basically not any different from the FBI falsifying evidence, which ha
Re: (Score:2)
Not necessarily disagreeing with you here, but after reading the article I could see something to the FBI's arguments.
My understanding is that in this case, the FBI took over Playpen. Let's say that you go to visit Playpen. The FBI has an encrypted record of your visit, which only it has the keys to. How can you counter the evidence supplied by the FBI? What if the FBI's "encryption" method actually spits out false data?
Wouldn't it be easier to just store a completely made up unencrypted record of your visit instead?
Re: (Score:2)
This seems to be a case of a re-explanation of what a tech told him. The 3rd party techs don't hold as much credential in a court as a "special agent" so the agent is in court trying to explain what happened. From the summary I can only establish that in order to "catch" a suspect they inserted a MITM that altered the data so it became identifiable (eg adding the string &FBISUSP=001 to every HTTP query or even every packet) - that allowed them to not touch the servers (maintaining the forensic credibili
Re: (Score:2)
No (Score:2)
Decrypting data doesn't alter evidence anymore than sequencing DNA evidence alters a blood sample, or sorting a bank transactions into deposits and withdrawls alters a bank statement used for evidence.
Re: (Score:3)
Doesn't sequencing DNA alter the blood sample? I haven't done it for 20 years, but the original sample was destroyed after gel electrophoresis as an essential part of the process, the dna was literally broken down. Their lab is probably better than what I had in HS, but I think it they also destroy the sample.
Of course you don't use the whole blood sample, you take a bit out of it. But that also "damages" the evidence (in that there's less of it).
It seems like encryption is nothing like that, the original f
Re: (Score:2)
Decrypting data doesn't alter evidence anymore than sequencing DNA evidence alters a blood sample, or sorting a bank transactions into deposits and withdrawls alters a bank statement used for evidence.
A friend and I once toyed with the concept of software which would 'decrypt' anything you gave it into porn.
Re:No (Score:4, Informative)
On a semi-related note, during the "Zip wars" in the early 90s there was a fake file compression program circulating called NaBoB that claimed to use some sort of quantum compression techniques (all compression algorithms named after quarks) to cause your files to hit "the singularity," where every archive would be reduced to a single byte in size.
Naturally, all it really did was rename your files, hide them, and write a one-byte "archive file" in their places. When you "decompressed" the archive, the full-size files would be restored. Miraculous!
Re: (Score:2)
Naturally, all it really did was rename your files, hide them, and write a one-byte "archive file" in their places.
Lol, just tell people that you have to ship a "manifest" with the 1-byte file, with the "manifest" being coincidentally the same size as the original zipped file. :)
Re: (Score:2)
It does. And it is glaringly obvious that it does: The decrypted data has entropy lower by at least the entropy in the encryption key and that entropy was distributed over the bits of the encrypted data. As such, it is fundamentally different. Some basic understanding of what encryption does is required to see this though.
Dumb Criminal (Score:1)
What kind of dumbass criminal names a kiddy-porn site "PlayPen"? Call it say "Windows10" or "Zune", then no cop will touch it.
Misleading heading and summary (Score:2)
The agent didn't say it invalidated forensic evidence just that it wasn't quite as forensically solid but not exactly what was collected:
Had that data been encrypted, “It would still be valid, it still would have been accurate data; however, it would not have been as forensically sound as being able to turn over exactly what the government collected,” Alfin said.
Re: (Score:2)
On the other hand I think it is
Re: Misleading heading and summary (Score:3)
There is a point to be made here (Score:4, Interesting)
It seems as though the FBI should be cheering for encrypted transmission by default; it means the evidence they collect is (more provably, at least) genuine.
* Let's assume they have a valid and proper warrant here, which usually isn't the case, but let's keep this simple.
Re: (Score:3)
Suppose the FBI* wanted to present evidence against me in court, which allegedly I transmitted over HTTP, telnet, SSL, or some other insecure protocol. Could I not validly say that the message was forged by a man-in-the-middle?
You could say that, but a prosecutor only needs to prove that it was you who transmitted that message "beyond a reasonable doubt." You would be innocent until proven guilty, but "the dog ate my homework" is a pretty weak defense.
Re: (Score:2)
Worked for Clinton on her espionage charges.
Re: (Score:2)
Re: (Score:1)
Well no, that's where the defense comes in.
Take letters, for example.
If there's no guarantee your mail will retain its integrity (unencrypted and unsecure), one can easily claim that the letter was opened and incriminating evidence planted. This is why opening mail that does not belong to you is a criminal offense: To help slightly reduce the chance that your data is deliberately mishandled in this way. Every 'hand' (or server, service, database, whatever) your letter (data) went through with no encryption
Re: (Score:2)
Mmmmmm, no, my message for Timmy was "Happy Birthday" and $100. If Timmy got an application letter to ISIS then I most definitely did not transmit that message. A transmission took place and Timmy received a message; just not one from me.
I understand that you're trying to explain how a MITM attack works. I'm more trying to explain how evidence works in criminal trials. Just because a message exists doesn't mean I wrote it. You would have to prove that ... not just that an envelope left my mailbox and ended
Re: (Score:2)
Not this juror. You'd still have to explain to me who conducted the original attack, why, and when -- the latter being the most crucial. If you can't prove when it happened then there's little evidence it happened.
Re: There is a point to be made here (Score:2)
Re: (Score:3)
HTTP, telnet, SSL, or some other insecure protocol. Could I not validly say that the message was forged by a man-in-the-middle?
In the interest of pedantry, SSL is not insecure - or rather, it's the only effective defense we have against man-in-the-middle attacks. You also can't actually "transmit" over SSL; SSL just turns an insecure connection into a secure one. You have to do the actual transmitting over a higher-level protocol, like HTTP.
Re: (Score:2)
SSL is insecure, all versions of the SSL protocol have serious vulnerabilities, you really need to be using TLS.
Re: (Score:2)
Re:There is a point to be made here (Score:4, Insightful)
Comment removed (Score:3)
Re: (Score:3)
during brute force attacks, sequential reads from disk into RAM contribute to the overall MTBF and MTTF statistics for the hardware. depending on how old the disk is and how complex the encryption, you could very well end up with a nontrivial number of missing sectors and potentially corrupted data on the disk just from thrashing it for personal gain. depending on the encryption, any writes will also contribute to things like SSD write life
Except they don't run the brute force attack on the physical hardware that they confiscated in a search. The very first thing that is done is that the disks are cloned. Copies of the cloned disk image are then used in any attempt to brute force passwords or encryption keys.
FBI was talking out of it's ass. (Score:3)
They had access to personal, private information, they should have encrypted it.
Encrypting it does not fundamentally alter it, anymore than making taking a shirt and folding it so that it fits inside an evidence bag fundamentally alters it.
Should they be punished for doing so? Yes. But it should not invalidate their case. Fine them $100 per suspect, and let the evidence in to court.
Not realistic (Score:2)
No one uses one-time pads.
I get that cryptonerds find it fascinating, but in the real world everyone is using AES unless they have legacy crap to support.
Some people may use Serpent or Twofish if they distrust AES, but the result is the same. "Decrypting" any real system with a custom key like that is just not going to happen.
The Road can change The Traveler (Score:2)
If the data is not encrypted, a middle man could have changed it prior to arriving back at FBI headquarters. (Doesn't everyone have a network appliance watching all traffic leaving home to scrub MAC addresses and more in plain text of packets leaving? Red lights? Klaxons? "You have ID data trying to Breach!!" )
It had me wondering on a tangent.... If Stingray's in use, and one of the methods it uses to snoop is to scream louder and force phones to revert to older, not so encrypted communication protocols, ho
Re: (Score:1)
And all this is moot. Since no privacy can be had on a network connected computer where all can/will be hacked, this also means anything on the networked computer cannot be connected to only the owners/operators. They killed computer evidence in their child preditor descision.
"If I cannot keep LEO off my machine, LEO put the pictures there, or looked after the other Hackers put it there with the same exploit LEO used!"
Umm... (Score:2)
Yes, it is definitely true that digital forensics requires care to not munge the evidence and preserve its integrity; and that gets a lot harder if you are actively attacking a remote host that multiple other people have access to and can potentially also be altering, rather than just shoving an HDD into a write blocker and reading it back; but I'm unclear on why that relates to encryption.
Basically nothing you 'find' on a computer is actually meaningful without a layer
Bad article (Score:3)
Decrypting Alters stuff (Score:2)
Lets assume the most easy encryption, a one time pad for xor encryption.
Now i encrypted something with a block of random data.
I now take your result and xor it with gplv2.txt. Then i store the resulting file as key.xor.
When you find key.xor, you can confirm, the encrypted data was gplv2.txt
When you find the real random key, you get the sensitive data.
If the result is data a, data b or total garbage only depends on the key. For aes the same, every key can decrypt stuff, but only the right one gets the data y