OK, the answer to the title of this blog is clearly NO. Let's take a bug that causes a program to crash as soon as it starts running. Unless the program is used to protect something else, crashing it as soon as it starts is probably the safest thing you can do (you are guaranteed that it won't leak anything!). But, barring such obvious exceptions, is it possible that all bugs can somehow be utilized to breach security? I don't know the answer. However, when I see something like this, I get nervous. Kris Kaspersky has demonstrated that it's possible to use bugs in Intel's CPUs in order to carry out attacks that cannot be patched. This is another suprise attack, utilizing bugs that until now were never considered "security flaws". So, are all bugs security flaws? I would guess that most definitely have the potential...

One of the key problems of the security industry is that even when the design of a product is excellent and guarantees security, much can go wrong in the implementation stage. A product that uses IPsec or SSL to carry out secure communication, but is careless about how it manages keys, or doesn't properly check the signatures and so on, will not be secure. Likewise, a buffer overflow or other flaw could be used to completely bypass the secure protocol. This is actually very worrisome because it means that it is not enough to carry out an in-depth code review on the portion of code that deals with security; flaws in other parts of the code can still cause a compromise. Despite the above, in many cases we have good solutions that provide a good level of security.

But, what happens when we get to applications where security is critical. No, I am not talking about the military or the intelligence community; I am talking about elections. There are many secure election schemes that have been proposed, and some of them come with rigorous proofs of the security guarantees. However, these proofs only talk about the design. There can be no proof that the scheme is still secure when it is badly implemented, because it just isn't true. This introduces a serious problem which is that we now have to trust the implementation. Anyone with experience in the software development industry knows that trusting the code to be bug-free is somewhere between stupidity and blind naivity. Is there any solution?

A very interesting suggestion that Ron Rivest mentioned at this year's Cryptographer's panel at RSA is that of software independence. A software independent eVoting solution is one that guarantees that an undetectable bug in the software cannot change the election outcome. Although this may sound impossible to some, it can be achieved by combining a real-world paper trail with the electronic voting software; see here for more details.

I strongly believe that this is the right direction. We can guarantee that even if the software is buggy, the election outcome will not be changed. This doesn't mean that other bad things won't happen (like a programmer inserting malicious code that will let it learn who voted for which candidate), but at least we can protect the most crucial element: the election outcome.

As part of my position at Aladdin, I reviewed the security of the Simple Pairing Protocol of the new Bluetooth specification, version 2.1. On the one hand, I found that there are significant improvements to the pairing protocol: standard cryptographic primitives are used, and the link key is well protected since it is derived from a Diffie-Hellman key exchange (carried out in an Elliptic curve group, for greater efficiency). However, I also found a huge vulnerability in the pairing mode that is based on passkey entry (i.e., the mode where a password is used in the pairing procedure).

There are actually two attacks. In the first, an eavesdropping attacker can learn the password in real time, irrespective of its length. This is not a problem if a different password is used every time. Note that this "should" be the case if the user types a password into two devices, like a laptop and cellphone. However, often a user will use the same password every time; in such a case, the pairing procedure becomes vulnerable. In addition to the above, devices without an interface for typing in a password have a fixed password (this password can be changed from the default, but in general is fixed). In such a case, an eavesdropper can learn the password and then pair itself with the device. Needless to say, this is a very serious vulnerability. In the second attack, an attacker who finds (or steals) a password-protected device (with a fixed password) can interact with the device a small number of times and fully learn the password, thereby enabling it to pair with it. Specifically, if the device has a 6 digit password, it suffices to attempt login approximately 10 times. In contrast, a secure password protocol would require the attacker to try approximately 500,000 times! Once again, this shows a serious vulnerability in the protocol.

I will be presenting these attacks at the Black Hat USA 2008 conference in Las Vegas this coming August; see more details here. In addition to describing the attacks, I will talk about what can be done until the protocols are fixed, and how to fix them. I look forward to seeing you there!

There are many reasons why an organization should take IT security seriously. The most superficial of these is the need to protect itself from a lawsuit in the case of a security breach. However, this narrow view misses the added value that good security policies and a strong security record can add to business.

Users are becoming more and more aware of security and are demanding it more as time goes on. For example, the perception that one social networking site is more secure than another is an important factor for many users choosing a specific site/service (and this is true whether or not that perception has any real basis). Consider also the huge campaign of Citibank regarding identity theft; they understood that the promise of identity-theft prevention is a factor in consumers choosing their bank.

I strongly believe that this trend will continue, and that the question of security will become more and more central. We are not too far away from the time that companies will be judged by their security just as they are judged by the quality of their products and their customer service.

I would also like to add an argument for security from an ethical standpoint. The damage to users when their private information is lost can go far beyond the realm of financial loss. If the information is medical, then this is clear. However, even the loss of financial data can result in damage that is personal in nature. Every organization has an ethical responsibility to protect their customer data, and this is independent of the market benefits. I compare this with corporate philanthropy and environmentally-friendly policies. Such policies have market benefits, but are also obviously important as standalone causes.