Before wrapping up this series of posts on why standardized security systems fail let's do a quick run on a few more systems.
Showing posts with label Substandard security. Show all posts
Showing posts with label Substandard security. Show all posts
Friday, November 4, 2011
Tuesday, October 18, 2011
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.
Tuesday, October 4, 2011
GSM A5/1: (Sub)Standard Security pt.2
GSM is a widely deployed standard for cellular communications, including security aspects. This post will describe one aspect of the
GSM security architecture, how GSM security has been hacked and why.
The GSM standard deals with two main security concerns - payment and privacy. The first goal is to ensure that the person making a call pays for it. The second goal is to prevent unauthorized parties from accessing communications over the GSM network. This post will concentrate on the second area - privacy.
The initial GSM standard, published in 1990, stipulates the usage of an
algorithm called A5/1 for scrambling GSM voice communications. A5/1 has two
important characteristics: it uses a 64-bit key and was intended to be kept
secret.
Keeping an algorithm implemented by dozens of device manufacturers secret is good for as long as it lasts - which isn't very long. A5/1 remained secret for a few years, but was fairly quickly reverse engineered and was published on the Internet in 1999.
Cryptanalysts found several weaknesses in the A5/1 algorithm - but none as significant as the fact that the algorithm uses a 64-bit key.
Using a 64-bit key to encrypt data is fine as long as one of the following conditions is true:
The GSM standard deals with two main security concerns - payment and privacy. The first goal is to ensure that the person making a call pays for it. The second goal is to prevent unauthorized parties from accessing communications over the GSM network. This post will concentrate on the second area - privacy.
Cell phone bug? |
Keeping an algorithm implemented by dozens of device manufacturers secret is good for as long as it lasts - which isn't very long. A5/1 remained secret for a few years, but was fairly quickly reverse engineered and was published on the Internet in 1999.
Cryptanalysts found several weaknesses in the A5/1 algorithm - but none as significant as the fact that the algorithm uses a 64-bit key.
Using a 64-bit key to encrypt data is fine as long as one of the following conditions is true:
- You're living in the 20th century.
- You're living in the early 21st century and the data secured by any specific key is not very valuable and there is no single known plain-text encrypted with each key
Thursday, September 15, 2011
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.
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.
Subscribe to:
Posts (Atom)