Slashdot Mirror
How I Compiled TrueCrypt For Windows and Matched the Official Binaries
First time accepted submitter xavier2dc writes "TrueCrypt is a popular software enabling data protection by means of encryption for all categories of users. It is getting even more attention lately following the revelations of the NSA as the authors remain anonymous and no thorough security audit have yet been conducted to prove it is not backdoored in any way. This has led several concerns raised in different places, such as this blog post, this one, this security analysis [PDF], also related on that blog post from which IsTrueCryptAuditedYet? was born. One of the recurring questions is: What if the binaries provided on the website were different than the source code and they included hidden features? To address this issue, I built the software from the official sources in a careful way and was able to match the official binaries. According to my findings, all three recent major versions (v7.1a, v7.0a, v6.3a) exactly match the sources."
But can you trust xavier2dc? It's turtles all the way down.
I was kinda hoping he'd built some elaborate timing setup to somehow match the exact timestamps and compile speed as the official binaries were built with.
This is still a great analysis though, and the detail provided is a fun read and useful insight into the general mindset and method of how this kind of analysis is done.
He provides pretty clear instructions on how to duplicate the process he used. He's not just saying "I did it and it's safe, trust me."
You don't have to trust this person, they've given you the exact steps to do it yourself.
No, TrueCrypt is a popular piece of software. You don't have "a hardware" or "a clothing" or "an information" — and likewise you cannot have "a software."
At this point it means that if you go through the source code and understand it, you know what the truecrypt binaries are doing, because you can be pretty sure (modulo built-in compiler exploits affecting both your and their compiler the same way) their binaries match the source code.
If I have been able to see further than others, it is because I bought a pair of binoculars.
TFA painstakingly explained how you can check it yourself. I'm sure several people will, including enough people that I trust enough. Especially given that there is zero evidence of a backdoor. Nobody is claiming there is a backdoor, so it's a question if yyou trust the testers more than you trust - nobody.
If you're that worried about a ken thompson attack (which this topic always devolves in to) then why even use a computer at all?
500 dollar reward for tip(s) leading to the arrest of the person(s) who stole my sig.
You're not quite 40 YEARS behind the times....
I think this whole NSA brouhaha will make some people start taking auditability a little more seriously.
Which means documenting the whole tool chain used and all options used. Of course, that only helps if you have access to the source. SUX to be you, Microsoft.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
He made very clear that he didn't audit the source code. Only that the binaries match the source code.
Define the universe. ;-)
Give two examples.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
I don't. I build all of code in hardware. That is rendered in MineCraft.
Why is it so hard to only have politicians for a few years, then have them go away?
The compiler (and support stack) is a MS compiler, and MS is already owned by "the man", so as Kernighan demonstrated you still can't trust it.
The disassembler he used is not. So it is (at least theoretically) possible to see if there is a back door. The compiler has a very low-level view of what it is doing. In order to add a back door, it would need to recognize when it is compiling TC. This could be a much more difficult technical problem than what Kernighan did to login, and, if discovered, would be devastating to MS from a PR standpoint.
Well, you can't trust any software you do not have the source code of. So of course you can not trust the MS compiler.
I'm a little suspect of this ./configure --enable-backdoor option.
Do you have the attention span of a gnat? What you ask about is covered In the second sentence of the summary.
I did the exact same thing as in TFA a few days earlier and ended up finding the exact same variations and causes for those variations.
My conclusion was also identical, binaries are indeed coming from the provided sources and can be trusted if no further backdoor is found in the sources themselves.
A cryptographic and coding oriented audit is still much required.
And how can I trust the cpu to actually execute the code as compiled and not insert it's own microcode into the process?
By using free compilers and ensuring clean binaries using diverse double compiling. (Thud457 mentioned it, and we discussed it a week ago.) Essentially what you do is bootstrap the compiler (compile the compiler's source code with your existing compiler binary, then recompile it with itself) on several different brands of compiler. If the binaries resulting from all bootstraps match, then either none of them have a backdoor or they all have the same backdoor. The more compilation processes you use, the less likely it will be that they all have the same backdoor. To exclude CPU microcode bugs that target a particular compiler, you could try running some of the bootstraps in an emulator such as DOSBox or bootstrap them as cross-compilers on another CPU architecture.
Is his mothers name Sarah Conner?
I was promised a flying car. Where is my flying car?
http://cm.bell-labs.com/who/ken/trust.html
It was a joke. Apparently not a successful one.
---- Booth was a patriot ----
The NSA wages a massive psychological warfare campaign in yearly psy-ops that are budgeted at multiple billions of dollars. Telling people that good, cheap, easy solutions are 'bad' is very very effective. Most people are very easily manipulated, when messages are regularly inserted into their media of choice.
Take one real-life NSA project:
- years ago, the US government passed laws insisting that ALL mobile phones in the USA could be location tracked using ANY viable technology solution. In reality, this means cell tower 'triangulation' methods, where the mobile network providers ensure that ANY phone visible to more than one tower has its precise position noted multiple times per minute. This process does NOT require any form of GPS chip, or for the phone to be 'in use'.
- the law, created for the benefit of the full surveillance activities of the NSA, was described to the sheeple at the time as 'assisting' the authorities in locating 911 callers who, for some reason, couldn't give their current location.
- for several years afterwards, TV dramas and Hollywood films built the location tracking nature of ALL mobile phones into their plots.
- then, the NSA decided that it wanted the American sheeple to FORGET this functionality, and contacted all the major media companies, requesting they no longer reminded viewers that their phones are effectively location tracking bugs. The excuse was that criminals would use their phones without regard for self-incrimination, if TV and films stopped reminded them of the risks represented by mobile phone use.
- now, for almost FIVE YEARS, most TV shows and films, if having characters with mobile phones, specifically state to the audience that phone location tracking is HARD, unlikely, and can only be done under very restricted circumstances. The TV show 'Shameless' (US remake) has a supposedly expert hacker kid STATE that mobile phones cannot be location tracked. The recent movie "The Call" states that only phones with GPS chips can be location tracked.
The NSA is in the game of perceived truths. The NSA has the money and influence to contact ANY mainstream media organisation, and have them carry an NSA designed form of propaganda.
Commercial encryption solutions don't just ALL contain NSA back-doors, they also prohibit the concept of 'plausible deniability'. Truecrypt doesn't tie the concept of password entry to the package that is to be decrypted. You cannot accurately say "this is a truecrypt data block". Commercial encryption products, on the other hand, bind the password process with the encrypted data, denying a user the ability to deny the use of encryption. NSA FUD shills suggest the government do NOT need proof of encryption when demanding passwords, but this is laughable. Legally, you CANNOT demand something you have no proof exists. With the use of Truecrypt, the government needs to collect pre-existing data about its use (say, like the fact the suspect has been witnessed STATING he/she keeps certain encrypted data on the suspect computer). A commercial encryption package, on the other hand, even without back-doors, still works to alert any third party where exactly encryption is active on the computer.
But did this guy check why the Windows version writes mysterious random bytes in the header but not in the Linux version?
There is one problem with his findings. In order to compile TrueCrypt you have to use Microsoft Visual C++ compiler, which is made by Microsoft from a closed source. If I was the NSA I would but the backdoor in the compiler and it would get injected into the binary whenever TrueCrypt was compiled.
Include source with the binary, in a non-executable section.
On first run, the machine builds the source (running as a very limited user) and compares the result against the rest of the binary. If it doesn't match, it simply ignores the binary supplied, replaces it with the new compiled version and signs it with a key unique to your own computer/compiler.
Of course, there are myriad problems here (not least that commercial software will never be released in that format), but that's the only way "to be sure". If in doubt, recompile from source. This is just an automation.
We already have the tools. PE and ELF already have sections we could use for this. We already do a lot of "multiple architectures stored in a single binary" magic (e.g. for MacOS, ELF allows you to do similar, etc.). We already have most of this in things like Software Restrictions policies, Authenticode, etc. it's just a case of going that one step further.
There's no reason that open-source software couldn't adopt a standard that - if you wish - you can just run the binary "as-is" (and it just ignores the source sections and works as currently), but if you have a system with the right option turned on, before a single byte of a program is executed it is compiled as a limited users from the source contained within it (in a way that produces constant binaries - it's not hard, we just prefer to debug with relevant build dates, etc. - this could be easily standardised to produce "consistent" builds if compiled on the same versions), checked against the resulting binary and/or just overwriting the binary (sometimes you'll have a newer compiler - swell - just ignore the "old" signed binary and replace with one generated from the binary's source contained within itself), signing the result and then "whitelisting" that particular signed binary. It only needs to be done once per executable per computer, won't take that long even for the largest software, and you get a "free" copy of the source too.
And while you're there, if you want to turn it off and just trust the binary (with source, and a message inside it detailing the checksum of that source, say, signed by FireFox Inc. or whatever), then you can just add that cert to your systems trusted lists and not worry about having to recompile every app.
To be honest, I don't get why open-source security distributions aren't already doing it. It would also solve an awful lot of "custom Makefile" problems that never get resolved. I spent hours the other week getting SDL to compile on ARM - sure, someone somewhere has done that for me but it's a pain in the arse involving editing Makefiles, changing options, patching configure scripts, etc. because "nobody ever does that, just use the binary".