Window 7 Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Monday, 26 January 2009

Closed Source Conspiracy

Posted on 08:56 by Unknown
Many people in the industry have an innate fear of closed source (AKA proprietary software), which especially applies to everything crypto-related.

The usual arguments go this way: this (proprietary) crypto software is bad, because the vendor might have put some backdoors in there. And: only the open source crypto software, which can be reviewed by anyone, can be trusted! So, after my recent post, quite a few people wrote to me and asked how I could defend such an evil thing as BitLocker, which is proprietary, and, even worse, comes from Microsoft?

I personally think this way of reasoning sucks. In majority of cases, the fact something is distributed without the accompanying source code does not prevent others from analyzing the code. We do have advanced disassemblers and debuggers, and it is really not that difficult to make use of them as many people think.

Of course, some heavily obfuscated programs can be extremely difficult to analyze. Also, analyzing a chipset's firmware, when you do not even know the underlying CPU architecture and the I/O map might be hard. But these are special cases and do not apply to majority of software, that usually is not obfuscated at all.

It seems like the argument of Backdoored Proprietary Software usually comes from the open-source people, who are used to unlimited accesses to the source code, and consequently do not usually have much experience with advanced reverse engineer techniques, simply because they do not need them in their happy "Open Source Life". It's all Darwinism, after all ;)

On the other hand, some things are hard to analyze, regardless of whether the source code is available or not, think: crypto. Also, how many of you who actively use open source crypto software, e.g. TrueCrypt or GnuPG, have actually reviewed the source code? Anyone?

You might be thinking — maybe I haven't looked at the source code myself, but because it is open source, zillions of other users already have reviewed it. And if there was some backdoor in there, they would undoubtedly have found it already! Well, for all those open source fetishists, who blindly negate the value of anything that is not open source, I have only one word to say: Debian.

Keep in mind: I do not say closed source is more secure than open source — I only resist the open-source fundamentalism, that defines every proprietary software as inherently insecure, and everything open source as ultimately secure.

So, how should one (e.g. a government institution) verify security-level of a given crypto software, e.g. to ensure there are no built-in backdoors in there? I personally doubt it could be performed by one team, as it just usually happens that the same people who might be exceptionally skilled in code review, system-level security, etc, at the same time are average cryptographers and vice-versa.

Imagine e.g. that you need to find out if there are any weaknesses in your system drive encryption software, something like BitLocker. Even if you get access to the source code, you still would have to analyze a lot of system-level details — how is the trusted boot implemented (SRTM? DRTM? TPM interaction?), which system software is trusted, how the implementation withstands various not-crypto-related attacks (e.g. some of the attacks I described in my previous post), etc…

But this all is just system-level evaluation. What should come later is to analyze the actual crypto algorithms and protocols. Those later tasks fall into cryptography field and not into system-level security discipline, and consequently should be performed by some other team, the crypto experts.

So, no doubt, it is not an easy task, and the fact if there is or there is not C/C++ source code available, is usually one of the minor headaches (a good example is our attack on TXT, where we were able to discover bugs in Intel's specific system software, which, of course, is not open source).
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in philosophical | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Windows 7 seamless GUI integration coming to Qubes OS!
    Finally, after months of hard work, seamless mode for Windows 7 AppVMs is coming to Qubes OS! The new Windows Support Tools will be releas...
  • Converting untrusted PDFs into trusted ones: The Qubes Way
    Arguably one of the biggest challenges for desktop security is how to handle those overly complex PDFs, DOCs, and similar files, that are ...
  • The MS-DOS Security Model
    Back in the '80s, there was an operating system called MS-DOS . This ancient OS, some readers might not even remember it today, had a ve...
  • The three approaches to computer security
    If we looked at the computer systems and how they try to provide security, I think we could categorize those attempts into three broad categ...
  • Running Vista Every Day!
    More then a month ago I have installed Vista RTM on my primary laptop (x86 machine) and have been running it since that time almost every da...
  • Attacking Xen: DomU vs. Dom0 consideration
    As it usually happens, there is some confusion regarding the attacks presented in our Xen 0wning Trilogy. Some people think they are possibl...
  • Thoughts on Intel's upcoming Software Guard Extensions (Part 2)
    In the first part of this article published a few weeks ago, I have discussed the basics of Intel SGX technology, and also disc...
  • Qubes 2 Beta 2 has been released!
    Qubes R2 Beta 2 with KDE 4.9 environment (click for more screenshots) We're progressing fast and today I would like to anno...
  • Disposable VMs
    While we're still busy with some last few tickets left for Qubes Alpha 2 milestone, Rafal has already started working on a new feature ...
  • SVV Source Code Made Public!
    I decided to publish the full source code of my System Virginity Verifier. The license grants you to do anything with the code, including us...

Categories

  • attack
  • backdoors
  • bad guys attacking joanna
  • BIOS
  • bitlocker
  • challanges
  • chipset
  • cloud
  • company news
  • conferences
  • disk encryption
  • exploit
  • fighting for a better world
  • formal verification
  • general
  • hypervisor rootkits
  • nested virtualization
  • os security
  • personal
  • philosophical
  • qubes
  • rootkits
  • saving-the-world-afterhours
  • secure architecture
  • smm
  • tpm
  • trusted computing
  • trusted execution technology
  • usb
  • virtualization based rootkits
  • xen hacking
  • xen heap exploiting

Blog Archive

  • ►  2013 (7)
    • ►  November (1)
    • ►  September (1)
    • ►  August (1)
    • ►  June (1)
    • ►  March (1)
    • ►  February (2)
  • ►  2012 (8)
    • ►  December (1)
    • ►  September (2)
    • ►  July (1)
    • ►  June (1)
    • ►  March (1)
    • ►  February (1)
    • ►  January (1)
  • ►  2011 (17)
    • ►  December (2)
    • ►  September (3)
    • ►  August (1)
    • ►  June (2)
    • ►  May (4)
    • ►  April (3)
    • ►  March (2)
  • ►  2010 (15)
    • ►  December (1)
    • ►  October (1)
    • ►  September (4)
    • ►  August (2)
    • ►  July (1)
    • ►  June (1)
    • ►  May (2)
    • ►  April (2)
    • ►  January (1)
  • ▼  2009 (21)
    • ►  December (1)
    • ►  October (1)
    • ►  September (2)
    • ►  August (2)
    • ►  July (2)
    • ►  June (3)
    • ►  May (1)
    • ►  March (4)
    • ►  February (2)
    • ▼  January (3)
      • Closed Source Conspiracy
      • Why do I miss Microsoft BitLocker?
      • Attacking Intel® Trusted Execution Technology
  • ►  2008 (15)
    • ►  September (3)
    • ►  August (4)
    • ►  July (2)
    • ►  May (1)
    • ►  April (4)
    • ►  March (1)
  • ►  2007 (15)
    • ►  October (2)
    • ►  August (2)
    • ►  June (1)
    • ►  May (1)
    • ►  April (2)
    • ►  March (2)
    • ►  February (3)
    • ►  January (2)
  • ►  2006 (8)
    • ►  November (1)
    • ►  October (1)
    • ►  September (1)
    • ►  August (1)
    • ►  July (1)
    • ►  June (1)
    • ►  May (2)
Powered by Blogger.

About Me

Unknown
View my complete profile