Go Read A Paper — Part 1
Go Read A Paper — Part 1
When Your Main Cyber Risk is Releasing Your My Little Pony fan club Membership
If you are new to Cybersecurity, which published papers would you give to someone, in order for them to understand some of the great advancements in the field? And, as a teacher, which papers would you hand out to your students?
Preface
I love Cloudflare products, and in their drive for better standards for cryptography. And, one of my main tips to anyone who wants to innovate is to read at least one research paper a week. For me, I get a classic paper and a new paper and try and read them in some detail. This normally involves implementing the methods used and which allows me to understand the methods better, and (hopefully) feed this into my teaching and research.
And, so when the Head of R&D at Cloudflare (Nick Sullivan) posted his shortlist of papers of great papers in security engineering, it grabbed my interest:
Luckily, I had the privilege to interview Nick recently, here:
So gets go through them.
1. Diffie, W., & Hellman, M. (1976). New directions in cryptography. IEEE transactions on Information Theory, 22(6), 644–654.
While cryptography had existed before 1976, it was this paper that has laid down the foundation for cybersecurity over the past four decades. Within it, the authors outline the Diffie-Hellman (DH) key exchange method using discrete logarithms. It has used extensively within key exchange for secure communication, but now converted into elliptic curves. But, that’s not all, they outline the basics of how public-key encryption could be created, and it was up to Rivest, Shamir and Adleman (RSA) to propose their method in the following year.
Google citation count: 21,748. The impact of this paper cannot be properly measured, and it provides the core of privacy within tunnelled communications. While we have moved on since then, and implemented authenticated key exchange (AKE) and moved to elliptic curves, it is still the foundation that we build on for our secure communications. And, or the first time in human history, citizens could actually conduct their business without prying eyes watching. The paper is a MUST READ for anyone who does cybersecurity, and anyone who wants to get into the area. For cybersecurity, this paper is the equivalent to the work of Maxwell, Einsten and Newton in Maths and Physics.
2. Thompson, K. (1984). Reflections on trusting trust. Communications of the ACM, 27(8), 761–763.
Without Ken Thompson, we would probably live in a digital world that only contained Microsoft Windows. It was Thompson — at Bell Labs — who created the Unix, and the rest of history. He also invented the C programming language and has since co-developed the Go programming language. Within this paper, Ken outlines that it’s not enough to trust your software to run correctly — you also need to trust your compiler, and the compiler which builds the compiler:
Google citation count: 971. A strong citation count for quite a short paper, but it started a whole industry thinking about the tools that they used to create their systems, and the tools that created the tools, and so on. And so where would we be without Ken’s works? Possibly in a world which was stuck on desktops running Microsoft Windows, and no sign of the operating system that build the Internet?
3. Halderman, J. A., Schoen, S. D., Heninger, N., Clarkson, W., Paul, W., Calandrino, J. A., … & Felten, E. W. (2009). Lest we remember: cold-boot attacks on encryption keys. Communications of the ACM, 52(5), 91–98.
This is just a brilliant paper, which is great fun to read. Overall the writers started with the premise that memory is often locked by the operating system, but what happens when we take that lock off and examine the memory. This can involve a cold boot of a system, and where we can examine the contents of the memory, and see if there are any residues. The following shows the data left within the memory after given amount of time after a cold boot:
For this, they could find encryption keys and passwords that were still present in the memory, and even took it to the point of freezing the chips, as the memory tends to decay slower when the temperature is reduced:
Google citation count: 1,624. A highly recommended read for any student of cybersecurity, and a fun introduction to the wacky world of cybersecurity threats. If you want to get students interesting in cybersecurity and hardware, this is the paper that can open up so much debate about the risks that we face in using systems, especially in exposing our most sensitive of secrets. The imagination level of this works gains a perfect 10-out-of-10, and there’s even a video demonstrating the work:
4. Felt, A. P., Ainslie, A., Reeder, R. W., Consolvo, S., Thyagaraja, S., Bettes, A., … & Grimes, J. (2015, April). Improving SSL warnings: Comprehension and adherence. In Proceedings of the 33rd annual ACM conference on human factors in computing systems (pp. 2893–2902)
A great paper that covers the human side of interacting with the browser for SSL/TLS issues. They found that different browsers displayed different messages for the same problem related to the lack of a digital certificate:
A core focus of the authors was to simplify the messages presented to users. In the following the authors show a Chrome message on the right-hand side, and propose an alternative on the left-hand side:
Google count: 180. A lowish score for citations, possible because it actually provided complete solutions, and ended any other contributions. But, it did focus in on the poor methods that browser creators used to inform the general public about security threats. Since then, things have gotten much better.
5. Mickens, J. (2014). This world of ours. USENIX; login: logout, 8–11.
When an article starts with “Vertex-based Elliptic Cryptography on N-way Bojangle Spaces”, you know that the author’s tongue is firmly in their cheek. It has a serious focus though, and showcases the difference between the focus on advanced attacks, and those faced by the general public:
The only thing that I’ve ever wanted for Christmas is an automated way to generate strong yet memorable passwords. Unfortunately, large swaths of the security community are fixated on avant garde horrors such as the fact that, during solar eclipses, pacemakers can be remotely controlled with a garage door opener and a Pringles can.
And that your core threats are more likely an “Ex-girlfriend/boyfriend breaking into your email account and publicly releasing your correspondence with the My Little Pony fan club”, than “Organized criminals breaking into your email account and sending spam using your identity”.
Google citation count: 2. Cybersecurity is a serious business, but it shouldn’t take itself too seriously at times, and this paper pokes fun at those who continually scare us with the hacking of toys and kettle (oh … that me! Honest, I do know that the core threats are very simple ones, and my the hacking of toys is just to raise awareness ;-) ). It is not an academic paper, and was never going to gain any traction for citations, but still fun to read.
6. Roemer, R., Buchanan, E., Shacham, H., & Savage, S. (2012). Return-oriented programming: Systems, languages, and applications. ACM Transactions on Information and System Security (TISSEC), 15(1), 1–34.
This paper brought us a new way of looking at adversarial attack models using return-oriented programming, and where an attacker can divert code execution, without adding any new code.
Google citation count: 583. A practical paper that focuses (possibly) on those in industry, and building real-life systems. It’s a hands-on paper which was never going to score highly in peer-reviewed journals, but one that has changed our thinking about how malware can be created. In the early days, it was a method to breach licences on software, but soon become a method of choice for adding back doors into well-used programmes. These days, there are many tools which can turn a program such as Putty into an evil version of Putty. Possibly, the paper was a bit before its time, and it’s only now that we can see the full impact of code modification attacks, especially against trusted programs.
7. Newsham, T. (2000). Format string attacks.
The paper is written as a report rather than a research paper and outlines the threats related to formatting issues around strings and in buffer overflow problems. These problems still exist in modern software, especially in languages such as C. The paper is basically a cybersecurity reference guide for any C programmer, such as the way that code can display the stack memory:
The paper has also become a “go-to” reference for malware writers and for those who aim to detect malicious code, such as related to memory buffer overflows:
Overall, it’s a highly recommended paper for penetration testers, coders, malware writers (yikees!), and anyone who wants to do serious cybersecurity with software.
Google citation count: 114. While not highly cited in the academic press, it is definitely the paper that laid the foundations for code exploits, and which highlights the dangers held within programming languages which did not have strict checking on code operations. Buffer overflows are still one of the top exploited areas of software and are likely to be in the future. Languages such as Rust — and its improved memory management — will still always struggle against the widespread usage of C, but, hopefully, we will see a reduction in the scope of memory overflows in the future.
8. Ellison, C. (2007). Ceremony design and analysis. Cryptology EPrint Archive.
This is a paper that outlined how we could introduce humans into protocol design, and where we enact a ceremony, With this, we would secure systems against traditional network-based attacks, and more human-focused one (such as social engineering). For the first time, a network protocol could include human elements, and it moved away from the machine-based approach of most network protocols. A protocol could now include little stick people to represent the human elements of Bob, Alice and Carol:
Google citation count: 126. The paper was more of a starting point for protocol designers than something that could be added onto. Unfortunately, we have stuck with many of our existing protocols, and where the human is often seen as an after-thought.
10. Programming Satan’s Computer — Ross Anderson and Roger Needham (1995)
We spent too much of our time thinking defensively, but this paper tipped the scales the other way and asked system designers to think like an adversary and to act in a trusted way, until the worst possible moment. This is very much a human trait — to get someone's trust, and then breach it at the worst possible moment. And so, what if we designed protocols and systems to do the same, and look as if they were legitimate, and then for them to suddenly go bad. Many modern systems now introduce a consensus approach — or Bayzantian Fault Tolerance — to overcome this problem. But, it’s difficult to ever address properly.
Google citation count: 271. A paper that showed people to think differently, and not trust something, even though it has been seen to be trustworthy in the past. So could Facebook ever go bad, and end up using all our data for its own purposes? Oh, that already happens!