First Use of RIPA to Demand Encryption Keys

kylehase writes "The Regulation of Investigatory Powers Act (RIPA) is being used for the first time to force an animal activist to reveal encryption keys for encrypted files she claims to have no knowledge of. According to the article, she could face up to two years if she doesn't comply."

solution

The Regulation of Investigatory Powers Act (RIPA) is being used for the first time to force an animal activist to reveal encryption keys for encrypted files she claims to have no knowledge of.

That's why you use an encrypted file system with a duress key. In the event of coercion, you give them a key that *oops* results in the destruction of the data.

Re:solution

any forensic team with an ounce of competence will copy the original HDD and work off the copy, so that just won't work.

Re:solution

that is, of course, assuming that the police forensics team has an ounce of competence.

Re:solution

Because private companies are the pinnacle of competence and government is the pit of deepest stupidity.

Let me guess: you're either American, Israeli or Australian.

Re:Duh

Teacher hating very often fits into that same way of thinking.

Business and government are similar in that they are all staffed and run by people (that is, greedy grafty nasty people). They are different in that we elect our government people and there is some oversight of the work and the results - sometimes late, and sometimes shoddy, but the oversight is there.. A business on the other hand, involves no community decision, is run as a dictatorship and there is minimal oversight (less and less every day since the 80's).

I'm not anti-business, just honest. The problems come from the people, not the organizational method. The organizational method is supposed to be a way of compensating for the problems while minimizing the bad side-effects.

Being anti-gov't or anti-teacher is just a way of parroting something you heard from someone else -- it's not a legitimate position to argue from.

Re:solution

Because the rest of the world is smarter and more competent than people from those three countries...

No, but apparently parent's reading comprehension is superior to your own.

Or, to put it a way you might understand: "Whoooosh!"

Re:solution

Just blind them with goatse as the first file, they won't go near the rest.

Re:solution

Geez! How much trouble do you want to get into?

Re:solution

Correct- TrueCrypt has support for hidden and public volumes, both of which can use entirely seperate keys/keyfiles [truecrypt.org].

Re:solution

I don't think you understand how a hidden container works, it's not the same as a hidden partition. A hidden container is contained within another container, and looks just like random data.

During normal operation, you mount both the outer container and the hidden container using both the outer and hidden key. This enables truecrypt to see the hidden container and move around hidden data as you write to the outer container.

When you are arrested, you provide the key to the outer container, but not to the hidden one. In this mode, it's as if the hidden container doesn't exist and can of course be overwritten. There's absolutely nothing to prove that the hidden container exists, as long as you have a plausible outer container and can say "Look, this is what I was trying to hide".

Re:TrueCrypt's method is not detectable

And how do you mount the volume? If you mount it using TrueCrypt, then this only gives you deniability if the forensics people don't know about TrueCrypt. If they do, then a decent lawyer could convince a court that there was a second key that the suspect was not divulging and get them convicted under RIPA.

That's actually pretty much a stretch. Your 'decent' lawyer would have to give some sort of proof that there was a second partition there. Something that TrueCrypt is pretty much designed to prevent. You can easily show the existence of the first truecrypt partition - it's there in the open. You can't prove the existence of the second partition.

I'm not sure a judge will buy 'because we didn't find what we were looking for' as a reasonable showing of proof that a second partition exists, and unfortunately, that's all the proof that exists. The formatting method and the processing method result in random data covering the entire partition block, as data is written to both the shown & hidden partitions, that data changes from random to encrypted. However the whole goal of the crypto data is to make it look random.

So you have potentially 3 blocks of random data each constructed with the same randomizing algorythm. How exactly do you show where one begins & one ends? How do you even show that the 3rd block exists? The whole purpose of the hidden block is to make it almost impossible to prove the existence of that third block. You literally are more likely to brute force the key than you are to prove the existence of the hidden partition.

Re:solution

You don't have to prove you're innocent, they have to prove you are guilty.

That kind of thinking is *so* pre 9-11.

Re:solution

If you provide the passwords for both containers when mounting the outer container, TrueCrypt will prevent writes to the outer container from over-writing the inner container. Otherwise, it will quite happily over-write the inner container if too much data is written to the outer container.

Re:TrueCrypt's method is not detectable

I don't have the best understanding of how it all works, but I know that there are some errors here.

There are a couple of drawbacks to this method, one being that you can have two encrypted volumes start to corrupt each other if you fill the entire partition. If you plan ahead for this scenario you can avoid it, though. The other drawback is that you have to encrypt an entire partition to use it.

That's not how it works.

When you initialize your encrypted disk space, you tell Truecrypt how many containers you want. Say that you choose 2. When you mount your Truecrypt drive, you must always mount both containers. In this way, Truecrypt knows and can maintain integrity between the two--they won't start to overwrite or corrupt each other, because they are both known about and available. If you ever only give the first key (you can't just give the second key, as the second container is entirely within the first) then you run the risk of corrupting the second container--in fact, any write operation will probably do it.

Now you can choose more than just two containers, and the same applies. One thing I'm not sure of is whether the third container is fully within the second.

None of this, however, helps in hiding the existence of a PGP key. If your opponent has access to your email servers and can see you sending messages encrypted by PGP you're gonna have some explaining to do when it comes to investigation time. I don't know of any steganographic programs with plausible deniability that are out at this time. If anyone's heard of any please let us know.

Even this has some subtle nuances.

If I am sending encrypted mail using PGP, I'm using someone else's PGP key. I don't have to have a PGP key myself in order to do this. If someone else is sending me encrypted messages, they could be sending it using anyone's PGP key--it's only obviously my key if it's provable that I've read the messages. For example, Alice could encrypt a message using Bob's public key, and then send that message to Charlie in an effort to frame him. Charlie gets the junk message and deletes it, but the feds who were wiretapping Charlie come in and demand to know what was in the message. Charlie can't answer--he has no idea. So he gets 2 years in prison from the RIPA act.

Re:solution

Very easy: Assume your swap is on /dev/sda2:

    cryptsetup --key-file=/dev/random create c1 /dev/sda2
    mkswap /dev/mapper/c1
    swapon /dev/mapper/c1

This reads a cryptogtaphically very good key from /dev/random, that has a lot of true randomness in it in addition.

Re:solution

Yeah. Truecrypt does this.

http://www.truecrypt.org/hiddenvolume.php [truecrypt.org]

Truecrypt is pretty nifty all around.

TrueCrypt is the best for Windows and Linux.

TrueCrypt [truecrypt.org] allows hidden volumes [truecrypt.org], indistinguishable from one volume. The file size is constant.

TrueCrypt works very, very well. I use it with just one volume to protect passwords and other files.

When you don't want to encrypt a volume, but just a file, Gnu Privacy Guard [gnupg.org] is best.

TrueCrypt: Open Source and Free.

I forgot to say that TrueCrypt is open source and free, and, in my experience, perfectly reliable. There are Windows and Linux versions, and a Mac OS X version is planned.

Don't forget to donate if you use TrueCrypt extensively.

The present government corruption in both the U.S. and U.K. started when secret violence was authorized as a way of protecting oil investments of British and U.S. investors. Tending toward outlawing privacy is a way of continuing that corruption. Any government that can act in secret cannot be a democracy, because citizens cannot participate in things that are unknown to them.

This is a good site to read about the corruption, and to contribute links: U.S. Government corruption TimeLines [cooperativeresearch.org]. Example: Complete 911 Timeline, 3895 events.

Re:TrueCrypt: Open Source and Free.

The present government corruption in both the U.S. and U.K. started when secret violence was authorized as a way of protecting oil investments of British and U.S. investors.

I'm a cynic, so that colors what I have to say... but I disagree.

The present government corruption began as soon as our hairy forebears realized that people in positions of power would abuse those positions of power when given gifts. This can probably be traced back to the first time Ogg gave more meat to Oggette and her little Oglodytes simply because she was willing to grab her ankles for him.

It's human nature to try to twist the political structure to one's own ends, and it's a failure of modern society that 'the people' don't insist upon fairer means of government.

Any government that can act in secret cannot be a democracy, because citizens cannot participate in things that are unknown to them.

Very good point. However, I'd add that far too many people are willing to let this happen -- how many people follow the order, "Pay no attention to the man behind the curtain!" without question?

In addition to a secretive government being undemocratic, a population disinterested in the workings of government cannot produce a democratic government.

Re:TrueCrypt is the best for Windows and Linux.

Or at lest giving them a false sense if security.

If they're the type that need you holding their hand like that, do you really trust them with a system wherein they type a password then any app on the system is free to dump the entire volume? What good will that do when someone (govt or otherwise) sends them an exe in their mail that they happily run that just waits for you to decrypt the volume?

Maybe they're smart enough to not run exes so blatantly, but theres plenty of other potential code execution like software that autoupdates (+ big enough power forcing someone to sign their code so it validates), exploits, backdoors, etc.

Then theres the operating system holes in your security. Filenames and content will still end up in "recently accessed" lists in common software, that alone can be more than enough info. Theres the cleartext copy that ends up sitting in your swap file if the app swaps out. Backup/temp files saved outside the secured drive, etc.

TrueCrypt is useful for what it is, and I certainly use it daily, you just have to be careful with helping people into the world of security as they're looking for a panacea to do everything for them.

Re:TrueCrypt is the best for Windows and Linux.

The only problem is explaining that if (ok, when) they lose the password, you won't be able to crack it. Ever.

Not really. It's quite easy: "That's the whole point!"

And besides, not entirely true:

Q: We use TrueCrypt in a corporate environment. Is there a way for an administrator to reset a password when a user forgets it?

A: There is no "back door" implemented in TrueCrypt. However, there is a way to "reset" a TrueCrypt volume password/keyfile. After you create a volume, backup its header (select Tools -> Backup Volume Header) before you allow a non-admin user to use the volume. Note that the volume header (which is encrypted with a header key derived from a password/keyfile) contains the master key with which the volume is encrypted. Then ask the user to choose a password, and set it for him/her (Volumes -> Change Volume Password); or generate a user keyfile for him/her. Then you can allow the user to use the volume and to change the password/keyfiles without your assistance/permission. In case he/she forgets his/her password or loses his/her keyfile, you can "reset" the volume password/keyfiles to your original admin password/keyfiles by restoring the volume header (Tools -> Restore Volume Header).

I actually had someone ask me for something like this at work. Now I have something to tell them. (And something to suggest to our security department, we're currently using various encryptions for the various OSs we support, ugly).

Re:TrueCrypt is the best for Windows and Linux.

It's sad when you have to rely on TrueCrypt's plausible deniability to protect yourself from these things.

I agree. And AFAIK this law does not respect plausible deniability. Which also means that if the data is really random, they can throw you in prison and you cannot defend yourself.

Re:TrueCrypt is the best for Windows and Linux.

"Your honor, you see, I have a degree in Mathematics, and in computer science, and I'm trying to develop a very good random number generator [hand over stack of hex codes, on punch cards.] While I do have encryption software on my computer, I only used it to test the system. The large data file you see on my hard drive is exactly that, a large data file. It contains about 2 CPU-hours worth of random numbers as generated by an older version of my algorithm.

Now I understand that this looks suspicious, but mathematically, there is no difference between random numbers and encrypted data. Given enough time, and access to powerful computers, I could design a tool that would convert the random numbers you see there into any given text. From the Magna Carta, to the complete works of shakespear, to your own biography written in klingon.

I wish I could help you, but I'm afraid that mathematically, there is nothing to do."

Re:TrueCrypt is the best for Windows and Linux.

The problem is, the law doesn't seem to place the burden of proof on the prosecution when it comes to showing whether there is or isn't any meaningful data present. Any old bits on a hard drive are (unqualified) electronic data.

On your point about circumstantial evidence, we really need not to set a precedent that says use of encryption can be treated as any sort of evidence, circumstantial or otherwise, that you are storing data of dubious legality. The implications of giving any legal weight to drawing that conclusion are horrible.

Re:TrueCrypt is the best for Windows and Linux.

Given enough time, and access to powerful computers, I could design a tool that would convert the random numbers you see there into any given text.

Tool = XOR
Key = RandomData XOR Magna Carta

Doesn't take much time, or access to powerful computers.

Re:solution

Speaking as someone that used to teach Computer Forensics to the SFO, British Customs, the USA's FBI etc (they now have their own courses). I can assure you that the first thing that was covered was disk imaging and that you should always work from the image. The original is evidence and any damage (read change) renders that evidence inadmisable. All you have to do is turn on and the OS is likely to make a change. This is taken to the degree of not using windows as the OS for imagining as windows likes to write to secondary drives when they are mounted. If you use Linux you can more easily mount as read only. It is best to make a couple of good primary images and then work from images of them rather than continually reverting to the original drive/s when you mess up so as to minimise the risk of damage and a lost case.

Re:solution

I agree with your approach. I disagree, from direct observation, that the FBI are competent enough to actually do any of this. Despite their much-vaunted "Computer Crime Squad", they remain unwilling to investigate and incompetent to follow even basic backup and clean room procedures of materials they investigate. I've actually had to explain such issues to them, at length, regarding stolen computer property and verifying that software was taken with it.

Unless they've had a complete turnover of personnel throughout the department in the last 2 years, they're not competent from top to bottom in any of the 4 state's offices I had to deal with then.

Linux? You need a hardware write blocker, period.

Linux-based imaging is good only if you are interested in recovery. On the legal side of things, it will not do:

- Please explain to the court how you made a copy of this piece of evidence...
- I connected the drive to our forensic machine and...
- You mean, you connected this hard disk... to your machine?
- Yes of course, then I...
- Did you use a hardware write block?
- Er... I used Linux and mounted the...
- Please, just answer the question. Did you or did you not use a hardware write blocker device to connect the disk to your machine?
- I did not, but...
- Thank you, no further question. I now call for the evidence to be declared tainted and inadmissible in court, since the forensic team failed to use the proper hardware to ensure that no changes would be made to the disk.

There is a whole range of forensic-specific hardware available: write blockers, hardware disk imagers... Use them, or loose your case.

They're worse than gremlins!

Use them, or loose your case.

And it runs around free! Wreaking havoc! Smashing in windows and stealing car stereos! Eating whole bags of Cheetos and vomiting them up into your dress shoes! I'll tell you -- there's nothing worse than a case that has been loosed upon the world. Those things are wild.

Re:solution

Having a known self destruct switch may cause a person to end up even worse trouble. This is a discussion that occurs periodically on a number of cryptography forums.

Almost all police departments will image the drive, then present the person with the image to decrypt. If the image gets stung by a self destruct Trojan, then the police will know that its not a forgotten password, and then proceed to use rubber hose decryption to obtain the contents of the drive.

Better solution

A Better solution is plausible deniability [truecrypt.org].

One password gives your uber-secret-plans-for-world-conquest, the other password gives a few hundred meg of soft porn (or whatever).

That way, you appear to not be resisting their demands.

Don't just encrypt -- Hide!

Exactly!

Encrypting your data and not hiding it is the same as getting a $100k super secure safe, locking your stuff in it, but leaving it in the middle of the living room. Any { law enforcement agency / criminal gang / anyone with more resources and more muscles that you } will just force you to give them the key. In other words, they see the super secure safe and automatically assume there must be at least $1M in there and then they force you to give them the key. The govt will cite all kinds of stupid idiotic laws, the criminals will start cutting of the fingers (yours or your loved ones').

The solution is to use something like steganography and hide the data such that nobody even will suspect anything. The best secrets are the ones that are not even known to exist.

If the adversary is convinced that you do have the data and knows the data type, then create a similar but fake data set to be substituted for the real one.

Re:Better solution

And that is exactly the problem with RIPA in the first place. The assumption is that if there's encrypted data you have the key and is liable if you can't produce it. Never mind if you don't have the key, or if there's no key to be had in the first place.

I have some disks I wiped with crypto-generated randomness. Indistinguishable from encrypted disks without metadata (as linux dm-crypt can do for example). I cannot prove that there is no data on them. Completely impossible. Am I a criminal according to this law? Or do they need to have some proof that there is data on the disk?

Re:Better solution

Most are. There again, the former British Home Secretary changed the UK law to allow plausible denial when he got bombarded with encrypted files, followed by demands he turn over the decryption key. Has this been tried in the US? If not, why not? Seems like if it worked once, it should work other times. Might also try claiming that handing over the key would violate the DMCA and that you can't be ordered to commit a crime. (Not sure if that's strictly the case, but unless that event has been specifically covered, it might create enough doubt that the sentence is partially or entirely suspended, or even - unlikely as it is - the case thrown out. That's not perfect but it would be better than the pre-trial misery of Kevin Mitnick.)

Re:Better solution

I don't know about your world domination plan, but mine contains images, photographs, maps, blueprints and a few more things that cannot really easily be expressed in text.

Sounds a lot like my porn collection.

Re:Better solution

Filesize arithmetic?

You never used Truecrypt eh? It's not a zip file. It acts as a virtual hard drive partition that can be mounted as a drive.

When you create the volume it generates random bits throughout the virtual partition. You can copy whatever files you want onto the virtual partition, the rest of it is random noise. You may or may not choose to have additional hidden encrypted partitions within that noise. Adding up the size of know files tells you nothing about what may or may not lurk in the rest of the space on the virtual partition.