Header Clean

[Sabbath]

Header Clean

An idea providing consideration to users in countries with draconian laws regarding encryption, such as the UK.

This option allows the user to very quickly protect themselves from an attacker or to allow the user to attempt to defend themselves against RIPA.

The following request could be a separate portable .exe ( preferably with command line options for user scripting ) or built in to the new ciphershed TC replacement.



Function:

If provided as a portable version, the user can double click or run a script to execute "Header Clean". This tool will wipe the headers, encompassing backup headers of ALL attached hard drives and partitions including USB flash drives etc.



Wipe Pattern:

3x overwrite.
Two patterns of CSPRNG generated data and one last pattern of zero's. The last zero pattern is VERY important.



Benefits:

How it protects against brute force:

Put simply, the drives contain no header data for an adversary to attack. Immediate unbreakable protection.



How it protects against RIPA:

If there are no headers present then there is no reversible encryption. This is precisely why the last pass overwriting of zero's is so important. Zero is proof of no headers, random overwriting could be misinterpreted as a header.

With no headers there is little RIPA can do as the victim is able to provide any password they like. The victim has not refused to provide a password, so has complied with RIPA.

A user is able to freely provide any password, even the genuine one, as it may be discovered by other means. Either way, our user is protected by compliance.

For RIPA to fight this in law they would have to word the statute in such a way any file deletion was deemed illegal without prior permission from the state. Obviously an impossible restriction to enforce or even suggest.



A simple defence against any mistake:

If a user can envisage ever employing the "header clean" feature they should first create header backups and store them, encrypted, in a very safe and secure location.

Should a user mistakenly deploy the header cleaner they can easily restore their headers at a convenient time.



An added bonus feature of header clean:

Assuming my other request for a stand alone boot loader be adopted, then header clean can be used to remove the old headers from currently encrypted drives. After backing them up and also storing them on the stand alone boot loader obviously.





Arguments against:

Victim could be accused of intentional destruction of evidence.

This is only relevant if you knowingly destroy the headers when you are aware your hard drive is classed as evidence. Until the point you are arrested and your drive is held as evidence, you are free to use this tool.

You can also say you wiped your drives as you believed you were under attack from criminals or you mistakenly wiped them in the past.


There are idiots who will wipe their drives, we don't want the forum filled with complaints:

This is true and something the previous developers allowed to restrain TC's development. If we mistakenly follow this principle of only allowing progress to the lowest skilled member of the public, we will never enjoy many benefits which are already possible.




All the above is not trying to protect criminals, just the vulnerable.

[Resonance]

Sabbath, +1

Your idea, if I understand it, is that Csh should have a module that can wipe clean a container to high standards, similar to that of a secure wipe application. I agree that this a useful module for the program, and whatever module that contains that can have sufficient warning screens to inform the clueless. Care would need to be taken that header AND body would have an appearance in accordance with a generic deletion wipe, not simply a disemboweled container of a person whose is being coerced.

[Resonance]

Sabbath,

If you are concerned about coercion, I have a very dangerous idea for you. Dangerous in the sense that it will absolutely lead to data loss, unless used very carefully.

What about a module that, for example, wherein you have to give your password once per day, or all data is wiped? If you are held under duress (and your PC is analyzed and violated by coercion, a few days or hours later), there is NO WAY you can cooperate with coercion after the wipe. And if the wipe feature is documented publicly, they not only know you aren't cooperating, they know you cannot cooperate.

[Merlin]

Sabbath,

If you are concerned about coercion, I have a very dangerous idea for you. Dangerous in the sense that it will absolutely lead to data loss, unless used very carefully.

What about a module that, for example, wherein you have to give your password once per day, or all data is wiped? If you are held under duress (and your PC is analyzed and violated by coercion, a few days or hours later), there is NO WAY you can cooperate with coercion after the wipe. And if the wipe feature is documented publicly, they not only know you aren't cooperating, they know you cannot cooperate.

Problem: any competent adversary will image your drive before it happens

3x Wipe for headers is overkill though, with modern drives the single pass of zeros is sufficient.

For off disk headers/bootloaders on USB, given the small size of the headers, and the sizes shifted as part of wear levelling.. it might require nothing short of physical destruction.

[Resonance]

Problem: any competent adversary will image your drive before it happens

OK, you have to press a keyboard combination every few minutes. If you don't press it, it beeps, if you still don't press it, it's wiped. I'm not suggesting these features, I'm trying to brainstorm about unethical coercion since someone brought it up. Like a dead man switch on a train.

[Sabbath]

3x Wipe for headers is overkill though, with modern drives the single pass of zeros is sufficient.

Up until 6 months ago and for the 8 years previous I would have agreed with you totally. One reason I only suggested 3x.

I requested 3x for 2 reasons.

The first is the public’s ignorance about overwriting. 3 seems a reassuring number and the headers are so small the time required is insignificant. I hoped to pre-empt users requesting multiple passes to be added in the future if I had originally only asked for a single zero pass.

The second reason is due to a devastating experience I personally witnessed with a new friend of mine. He is a forensic geek of massive significance.

Never again will I wipe once, with zero's. 3x seems to be more than sufficient 2x should be ok.

I do not want to get involved in a long haired discussion on overwriting and stall this feature request. Everyone has their own theory on overwriting and mine was shaken about 6 months ago.

The speed of 3x in this application is not worth debating over.

For off disk headers/bootloaders on USB, given the small size of the headers, and the sizes shifted as part of wear levelling.. it might require nothing short of physical destruction.

This is correct, I agonised over mentioning USB drives as I was concerned about firmware controllers. In the end I decided to suggest it anyway in the hope someone might have thought of a way.

I also worry about the new SSD drives with hardware controllers. However I understand these drives trim anything to zero anyway. An overwrite on these drives might be an academic exercise, but again, 3x is no problem on such a small amount of data.