The Connection Between Software Design and Software Security

Wired reported in early June of this year that there has been a bug in the popular OpenSSL for over a decade that could allow bad guys to eavesdrop on connections, including VPN connections. According to the article, the bug is mostly found in Android phones and VPN software. I hope my Android phone is updated soon…

Back in July, Roger Grimes in a Security Central post on came out with 5 reasons why software bugs still plague us. His second reason (read the article for all five, it’s well done) is “Increasing software complexity”. I think it is much more than that.

I remember in college in the 1970s and 1980s we often discussed the issue of software correctness. We learned how to prove that software was correct and in fact it worked for small, simple programs. My faculty advisor for my Master’s Thesis, Harold Knudsen, worked on proving network and bus software design correct using Petri Nets – it was a lot of work for complex systems. Today’s software is large and not only is the software complex, but the algorithms being implemented are complex. And they may not be correct or secure. If that is the case, no matter how well the software implements the design, if the design isn’t correct, the software may not be secure or may not work correctly in other areas.

There are three phases of the implementation of software I want to look at here. One can use many models, paradigms and so forth to talk about software design, but for now I just want to look at three parts as they relate to SSL design:

  1. Protocol design. This is done and well analyzed. I don’t think the bug falls into this category.
  2. Protocol implementation design. In this case that might include how to manage certificates, among other things.
  3. Protocol implementation. That’s converting the implementation design into code (Java, C, F#, whatever).

I suspect the error in OpenSSL code was in one of the latter two. The second of the three can prove challenging. It is easy to make mistakes when the team doing that design part is often small. I’ve generally worked on teams of two or three or done it alone. Normal review processes can miss errors here, too. In many cases, that design is used to create the testing software, so the design itself is assumed to be correct.

Unfortunately, I don’t have an answer to guaranteed correct implementation for security or any other software for that matter. If I did – or if someone else did – and that answer were practical, it would be common practice in our industry. Right now we rely on good design, lots of testing, and the work of researchers like those that discovered the SSL bugs to keep looking for and reporting bugs. Of course, the bugs need to be fixed and used as tools to help us learn where and how programmers and designers err.

John McDermott

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.