User talk:Drdevil44/Tiny Linux Bootloader orig

integration of content?

There are a couple of points to discuss regarding this section:

1. The introduction and reasoning of the page needs consideration. Currently, it breaks (at least) Forum_etiquette#Avoid Controversy.2FControversial Topics, which must be discussed prior to linking it into the Arch Wiki dm-crypt article.
2. We have a fixed set of subpages described at Dm-crypt. No further subpages should be added without prior discussion in order to keep the article manageable and integrated. According to content, the contribution on this page may fit into Dm-crypt/Specialties, after Dm-crypt/Specialties#Securing the unencrypted boot partition (to be discussed). It may not fit there, if the expansion (proposed obfuscated bootloader) in it gets too long. If it is decided to stay in the Dm-crypt article sections, it should properly crosslink the setup steps with the rest of the article, just like the other content does. However, since the contribution itself proposed that tcplay is a preferred method to use it, maybe it is a better solution to move it there?

What are the opinions on the points? Any other to discuss?

--Indigo (talk) 17:27, 12 October 2014 (UTC)

1. I agree the intro is very biased and inaccurate, it should be greatly simplified and rewritten in a more objective way. Currently it makes it look like this method adds a lot more security over the traditional /boot partition way, while it's clearly not true: basically it relies on the fact that the "attackers" will discard the hard drive as malfunctioning in the hope that the only test they do is to use Gparted to see if and how the drive is partitioned... If somebody has such important data to protect that they need to induce possible attackers to think that that data doesn't even exist, it means they are after deniable encryption, which this method absolutely does not provide.
2. I think this method can be mentioned somewhere, after all it could indeed be the best solution for some scenarios and the ArchWiki's way is to present all the known options in an objective way and let the users choose among them. Of course all the content should be de-duplicated as you say. About tcplay, it's mentioned because it doesn't use a header, but the plain dm-crypt mode seems to be completely ignored for no apparent reason, while it would probably be most natural choice in this case.

Meanwhile I've renamed the article because "No-boot-partition" was too ambiguous, it could lead somebody to think that this is another way to keep the /boot data out of the hard drives, which is not the case. I don't think the current "Boot loader obfuscation" is such a great idea either, but it's the best one I've been able to think of for the moment.

-- Kynikos (talk) 10:35, 13 October 2014 (UTC)

The new name is better, but how do you see the contribution being added as a new subpage? It breaks consistency of the section somewhat, if the content is listed under Specialties and then links out to its own subpage. I don't want to make this complicated, but we want to keep consistency. Another option would be to add it under Dm-crypt/Specialties/Boot loader obfuscation? (or is that not possible, I dont remember)

1. My particular focul was the term "national laws" and how it is used as a reference for "attackers". Aside all pros/cons of a technical solution references like that are totally inappropriate here. Such arguments should to be posted to a blog or a wiki for Tails, but not our technical wiki on installing/maintaining Arch Linux. Sure agree to your points.
2. Well plain dm-crypt was not created for a deniability purpose per se. Truecrypt/tcplay explicitly added such features, so I understand the author proposing it as a preferred tool. Besides Tcplay is a really short article until now. It could benefit from content how to set up a root file system and making it optional to go regular partitioning/boot loader or a method like this. Add a crosslink/related to dm-crypt Specialties and done. That said I don't mind, just considering options.

--Indigo (talk) 21:36, 13 October 2014 (UTC)

1. You are perfectly right too, as I said that intro is very biased and controversial indeed, and must be rewritten.
2. I see what you mean, however I refuse to categorize this method as a form of deniable encryption, in fact the presence of the boot loader itself makes it clear that there must be something to boot, the only problem is finding it. And, by the way, just trying to boot the hard disk would ask for the passphrase and all, right? That's why I don't see the presence or absence of a LUKS header so important in this case.

Anyway I was thinking, since this whole idea revolves around the use of Tiny Linux Bootloader, why not create a "Tiny Linux Bootloader" article and move the content there, linking it from dm-crypt/Specialties and tcplay?

-- Kynikos (talk) 01:14, 15 October 2014 (UTC)

+1, that's definetely the most straight forward place for the content. Why did I not think of that ..

--Indigo (talk) 08:24, 15 October 2014 (UTC)

1. Fair points
2. tc-play is recommended over plain dm-crypt because a key derivation function is used. The aim is to modify tiny linux bootloader to be obfuscated and difficult to detect (think polymorphic - different for each install) and for it to expect the password to be keyed but no prompt or denial is given until the correct password is typed. This is not more than a day or two's work - just need to find the time in the coming weeks. The kernel and initrd are encrypted too. It doesn't yet do this - maybe it might be better to archive the page until I've modified it to do this. I accept the bootloader is only obfuscated but is detectable but would require time consuming reverse engineering. the truth is, hidden partitions from tc-play do not work on ext filesystems. So whilst not deniable encryption in its purest form, strong obfuscation does provide a degree of deniability.

--Drdevil44 (talk) 16:47, 15 October 2014 (UTC)

For the moment I've moved the article as we discussed, no need to archive it somehow, unless you want to move it as a subpage of your User page because you don't want people to test your software until it reaches a more advanced state.

I'm not saying this project is useless, it's even rather interesting IMO, but regarding deniability, if the hard drive is stolen/seized, the evidence of the existence of the data (i.e. the boot loader) will always remain in the hands of the attackers, so it will be only a matter of time before they find out that your denying is actually lying (if they've taken the time/risk/money to grab your drive, they won't stop at just reading the partitions). With a more classic /boot partition hosted in a separate device, instead, you may have been able to securely hide or even destroy the unencrypted stuff after losing control over the encrypted data, thus granting you the ability to deny its existence with confidence. This is deniable encryption, which IMHO is a boolean value: you either reached it or not, there's no such thing as "degree[s] of deniability".

-- Kynikos (talk) 14:36, 16 October 2014 (UTC)

Kynikos - yes we are in agreement - I do not disagree with what you say. Given a sufficiently skilled reverse engineer, detection of a bootloader is inevitable. I agree also that deniabilitity is boolean and that having /boot on a seperate USB is potentially better (although the reference to root= might give some support to the drive being encrypted along with other crypto= options - particularly if it's found alongside the drive or in close proximity). Ultimately though, headerless encryption is deniable regardless of the presence of a bootloader, because one can just say he erased the partition with /dev/urandom before the drive was seized (in the absence of distinguishing attacks against the cipher - to which AES is not currently vulnerable in this case). My personal view is that obfuscation does present a serious obstacle to analysis (just ask any malware analst) and certainly here my local Police unit is handling 50 case/week with fewer than 10 staff - you can't spend months analysing something to prove it's encrypted (when really you cant prove this anyway) in the real world. So I think obfuscation does have value although it is not value in the absolute sense (but neither is a USB stick) - the goal being that an obfuscated loader presents no password prompt and it is hard or impossible to build a automatic tool to detect it (because it's strongly polymorphic - although it's an interesting research question). --Drdevil44 (talk) 08:31, 17 October 2014 (UTC)

So, regarding the 'boolean', it is agreed not enough and this must be clear from the wiki instructions. FWIW I'd say the first feature you want to achieve the boolean is geographical separation between data and key, but let's keep that out-of-scope here.

Then, no offense, I don't like your "50 case/week" example (re (1) above). It is not needed anyway, because IMO you have put your bar higher. Like Kynikos implied your bar should be data thieves, who have enough determination and resources to investigate how to get to the data valuable for them.

Now for data thieves a laptop that does not boot indeed raises even more interest. Hence, the reasoning of the Truecrypt project years back to add a feature for a secondary hidden system partition: the first obfuscation the laptop needs is a valid partition table and fast boot with the default OS (/kernel options) when it is turned on. Nonetheless, the "obfuscation" you work on could be applied to the separate boot device (e.g. usb-stick) as well, could it not? That would be how I see your instructions/morphing bootloader be best linked in to our existing content once it is ready. And for your consideration: devices usually come up with something ala "NO BOOT DISK" and not a blank screen when the boot loader is corrupt ;) --Indigo (talk) 15:19, 17 October 2014 (UTC)

Indigo, data thieves are thwarted by the encryption of the root partition. The purpose of an obfuscated bootloader serves one purpose only, and that is to make it difficult to determine that there is a bootloader present and hence thwart use of key disclosure laws. As already said, an encrypted partition with no header is deniable regardless of whether there is a bootloader because one can assert that it is just random data. An obfuscated bootloader just makes it less likely that one would need to explain the presence of the bootloader and hence the random partition - it is not a substitute for data encryption. Ultimately I guess this debate is over the finer points, and ultimately the article just needs to be clear about these points. I will move it to my talk page and come back later with the polymorphic loader and a clearer explanation. thanks for your comments. --Drdevil44 (talk) 10:59, 18 October 2014 (UTC)

To give you another reason why it can be important to have a bootable laptop: have you ever heard of border controls that may ask you to boot it, not because they have interest in your data but to check it is not a bomb? Happens these days unfortunately, how often just depends on world news.. But anyhow, regarding the intention to thwart applicable laws, I am unsure if we can cover such content even with a big warning disclaimer to be honest. It is on your user page for now and sure an interesting project you are working on there. I gotta test it sometime :) --Indigo (talk) 17:43, 18 October 2014 (UTC)