Hello, I’m John Kerr, and like the sidebar says, I’ve been programming computers since high school circa 1972. Back then, “writing a program” meant transcribing my BASIC or Fortran on to the special fixed-pitch stationery, prior to snail-mailing it to the local university to be typed in manually at a terminal, the output from an ICL mainframe being returned to my school in time for the next week’s lesson. The debug cycle was a bitch!
Today, several things have improved: including the languages, and more generally, the software development environment, as well as almost every aspect of the performance of our computing machines. At the same time, the universal adoption of automation, and particularly of the internet as a means of conducting commerce, education, social activity, and the provision of goods and services in countless additional domains, has led to the creation of new problems, new challenges, in totally new areas of investigation and research.
Many of these areas come under the umbrella of “Security”, and it is with this single word, in all of its nuances and connected subtopics, that I will be concerned in this first series of articles.
It is customary to open proceedings by drawing attention to one invariant fact. Namely, that the size of your subject - its breadth and depth of scope, as well as its height, width, length, thickness, and any other dimension – far exceeds anything in the minds or recent experience of your audience. No matter the nature of your subject, this one thing must be true about it.
Luckily, this does happen to be true of my subject, as will become clear in the course of succeeding articles. Security, Is, Big.
Another obligatory ingredient is humour. This should preferably be supplied either by Scott Adams via Dilbert, or perhaps even better, by Randall Munroe via XKCD:
One further convention should be adhered to by anyone presuming to talk authoritatively about security. The speaker should be a criminal. And not just that: one whose crimes relate to some aspect of the subject. Almost any crime will do. A housebreaking, a car theft, or even a mugging can highlight some aspect of security in need of improvement. But for our purposes, the ideal candidate is someone who has reverse-engineered security systems in order to obtain access to protected information. In short, we need: The Hacker.
Some Of These Numbers Mean Something
At this point, I should probably admit my unsuitability for this role. After all, I was recently vetted by our boys and girls in blue, and confirmed as suitable for handling police confidential data. So, clearly there’s nothing in my personal past which…
Hmm. Ah, yes. Of course. That one time…
It was in the early 80s, I can’t be any more specific than that. My friend had a £3,000 Automatic Computer Aided Drawing package, which he wanted to be able to use on two machines, but the damned thing came with a dongle – a small device that plugged in to one of the serial communications ports on the PC – and so he had to remember to carry this device to and from work every day, and go through the laborious process of gaining access to the back of the main unit each time to unplug or insert it.
This was a pain. Of course, the dongle was a so-called “potted module”, encased in resin to ensure that any attempt to take it apart for investigation would destroy it, and he didn’t have a spare £3,000 for a replacement one.
Being more hardware-oriented that I, he had established that the software was using a couple of handshake pins on the serial port to clock and read in a binary code from the device. With the help of a storage oscilloscope, we determined the sequence of that code, which was some 250 or so bits long. As a proof of concept, we built a programmable ROM device to simulate it, and that worked – but clearly, this simulation was too large to fit inside the module. A working simulation solution wasn’t enough, we wanted to reverse-engineer it completely!
Then I remembered a particular type of digital feedback circuit design from university, wrote a program to simulate that, and ran it until it discovered a circuit producing the observed code. Presto. One visit to that nice Mr Bridges at Marshalls Electronics in West Regent Street, and 14p worth of logic chips later, we were set to enter the lucrative dongle mass-manufacturing market.Which of course we didn’t. Rather than be seduced by the dark side of the force, we just celebrated and congratulated each other with a single working prototype and a beer at The Howff.
My friend was of course perfectly entitled to use his CAD package on his two PCs, and as for what we did – well, back then there were no anti-circumvention laws, not even in America, never mind the Land of the Barras! What we did would today be classed as Security Research. This is currently an area of extremely hot contention and debate, and later in this series, I will be looking at the kind of experimental activities that are sanctioned in various countries, and which ones require special permissions or exceptions to the overriding legislation.
We conspirators performed our research in the pre-web vacuum. Although bulletin boards existed and were subscribed to by specialists using 300 baud, acoustically-coupled modems, there was no means of connecting instantly to all the dongle-breaking intelligence in the world, as there is today for this or indeed any other subject. That very connectivity is of course one of the main driving forces behind much current legislation, in addition to being – as previously noted – the source of many of the problems that it addresses.
My example also illustrates a number of other subjects which will be covered in more detail in later articles. One relates to the visibility of the wires connecting the dongle to the PC: these are a vivid case of a “security hole”, and there are of course countless others. Consider for example the people who typed in my school program to the mainframe; clearly they could read all of my top secret information! Recently popularised security holes include the pattern of wear on a keypad used to enter a single access code, and a proposal to discontinue masking of password entry (which caused internationally renowned security expert Bruce Schneier to make what many regard as an uncharacteristic error).
How It All Ends
All of that is coming up later. Meanwhile, I want to finish this introductory article by spoiling the entire series for you and giving away the ending.
The answer is: have a Security Strategy!
Every article will refer back to this mantra, and hopefully prove that it is the single most important facet of any security system or context.
In the case of the XKCD cartoon: well, one visible component of the security strategy is probably Microsoft's security model for Windows, which is based on identity. The owner of the laptop establishes this by providing a password. Therefore, the security strategy relies upon the presumed fact that nobody else can know this password. Soon we might expect this to be extended to biometric data such as fingerprints, iris scans, etc., but with the model, and its place in the security strategy, remaining the same.
Until next time ... have a Security Strategy!
No comments:
Post a Comment