HTTPS: (Sub)Standard Security pt.3

In the first post in this series on the deficiencies of standardized security systems I promised a post on "X.509 certificates". By this I intended to discuss the commonly used system for authenticating and securing communications with web sites, widely known as SSL. As SSL (or to be precise, TLS) is just one component of this system (and is also used for other purposes) I will use the term "HTTPS system", though in fact the same system is used for more than just the HTTPS protocol.

HDCP: (Sub)Standard Security pt.1

I owe the readers of this blog an explanation (or two).  I promised to explain "Why Security Systems Fail" and so far, after more than a month, there was only one such post (on RSA SecurID).

To make up for this I'll do a series of posts on a group of security systems describing how and why they were breached. What these systems have in common is that they were each defined as a "standard" - i.e. a specification for the security system was published and was implemented by multiple parties. The first post in the series is dedicated to HDCP. Subsequent posts will cover GSM, X.509 certificates and others.

GPRS hacked: Who cares?

In case you weren't paying attention last week - Karsten Nohl and friends cracked the GPRS encryption scheme.

In this Forbes interview with Karsten the interviewer tried to get an answer on why the encryption scheme for GPRS was made weaker than that of the earlier GSM voice encryption scheme (A5/1 - which demanded much more effort to crack).

One point I didn't see mentioned is that fact that data communicated over GPRS can easily be encrypted at the application level, while voice is generally only secured at the GSM level. No serious security engineer would rely on the unkown propriety GPRS encryption for securing sensitive data communications over GPRS when they can always add there own application level encryption. If you know of a system that does rely on the GPRS encryption for such data - please leave a note in the comments below.

Blackhat US 2011: Impressions

I attended my first BlackHat conference a couple of weeks ago in Las Vegas. It was an interesting experience and I thought I’d share some of my thoughts.

The RSA SecurID debacle: Why it happened

The RSA SecurID saga was one of the more interesting security stories of 2011. Analyzing the background of this story can give some insight as to how security decisions are taken and why security systems fail.

The seven laws of security engineering

There are a few laws in the field of security engineering that impact many aspects of the discipline. Most of these laws are self evident and well known, but the application of these laws to real world situations is difficult. In fact most security failures in the field can be traced to one or more of these laws.

Following is a list of seven such laws with a short description of each law. Future posts will elaborate on these laws (and others) as part of an analysis of specific cases.

Law #1: There are always assumptions

You might ask a security engineer if a certain system is secure. If they give you an answer which sounds evasive and noncommittal that’s good – otherwise they’re not telling you the whole truth.

Because the truth is that no system is 100% secure in and of itself. The most a security engineer can say is that under certain assumptions the system is secure.