Preventing Disaster from Potential Security Bugs like Heartbleed

April 8th, 2014 by Posted in Random Jabberings, Technology

Full Disclosure: I am NOT a security expert, I don’t even have a detailed understanding of the TLS protocol and x509 spec. This blog post is based only on my high level understanding of public key crypto.

TL;DR? Skip to the idea.

Today is a bad Day

Today sees the disclosure of what is probably one of the worst security vulnerabilities in recent times. The repercussions are significantly worse than Apple’s goto bug. In short, openssl, one of the most widely used SSL/TLS libraries for online servers, has a bug which allows attackers to read arbitrary memory locations from processes using the openssl library. These processes always include the private key of the server. In short, what this means is, among other things, Attackers can retrieve the private key of any server running the vulnerable versions of openssl, allowing for:

  • Attackers to Man-In-The-Middle any visitor to your site / user of your services from this point onward.
  • Decrypt any past sessions that were recorded and were not secured by perfect forward secrecy (of which there are a LOT). This will include sensitive information such as user passwords, confidential messages and files, basically anything the user sent or received from your servers.

In addition to collecting any other information in memory like webpage content and private user data without having to perform a MITM.

Worse still, an attack like this is almost completely undetectable, so you can’t tell whether your key has already been stolen, and this vulnerability has been present for the best part of 2 years. (More Details Here)

Am I affected?

You can check whether your servers are vulnerable by using this external service: (Don’t forget to test any services that use SSL/TLS, not just HTTPS. E.G: IMAP, SMTP…)

But as an example, Facebook was only patched at around 12PM GMT (8/4/2012), 15 hours after the post hit HN. And many many other large websites have had a huge window in which they were vulnerable to attack.

How can we stop this!?

This is bad eh? In short, if you are affected, all you can do is this:

  • Recompile openssl with -DOPENSSL_NO_HEARTBEATS flag or install the latest version (1.0.1g). If neither of these are an immediate option, and you can sacrifice https for a while (e.g. you are only running a blog), then you should disable ssl until you can get this fixed so your private keys are less likely to get stolen.
  • Generate a new keypair for your server.
  • Issue a revocation certificate and publish it to revocation lists.

This will help somewhat with preventing future Man-In-The-Middle attacks, but there is nothing you can do to stop attackers decrypting past messages.

Unfortunately… revoking certificates doesn’t really work… which means that you can’t really protect your users from MITM attacks either.

Revocation Doesn’t Work!?

Yes. It’s not scalable. SSL / TLS is a great system, it’s distributed, and very fast. Verification of certificate chains can all take place locally, and no ‘looking up’ is needed. Introducing certificate revocation takes this beautiful distributed system, and makes it centralised.

For certificate revocation to work correctly, browsers need to look up a site’s certificate in a CRL (Certificate Revocation List)… for EVERY connection. This is not scalable, so a lot of browsers cache validity of certificates for up to 6 months. Worse still, some don’t use revocation lists at all, they’re just too slow right?

Well what can we do?

I believe if you are relying on revocation infrastructure during a crisis like this, you’re doing PKI wrong…

This problem came about because of a missing bounds checking issue in the C source code for openssl. This is not the first time an issue like this has caused a serious security problem, and it is undoubtedly not going to be the last. Writing these kinds of libraries in a higher-level language will not fix the problem either. It may arguably make the problem somewhat less likely, but will by no means make it impossible.

We can do better than we currently do, and protect against issues where our ssl libraries may be missing one bounds check and allow arbitrary access to our process’s memory.

How? Subkeys! and More Certificates!

I am not sure if the current SSL/TLS and x509 specs allow this (as I said, I am unfamiliar with both specs). However, subkeys are a brilliant high level concept, and one which is frequently used in PKIs such as OpenPGP.


  • Generate a new keypair each day (or some other small interval).
  • Create a subkey certificate (a certificate from your primary key signing the subkey, valid only for the current day). (A subkey cert in this instance would probably just be an x509 cert with the same Common Name (CN)).
  • Only load the subkeys into the processes using openssl, so that if and when an attacker can gain access to the entire memory of this process, the worst that can happen is they can decrypt messages from that day, and MITM for the rest of the day.
  • When a new subkey is required, due to expiry, ask a child process to generate a new one, and don’t generate it in the same process as that using openssl.

Allowing these kinds of certificates would also come with other benefits, such as having a single place to store the primary private key, which can generate the certificate and distribute the subkey among all load balancers, rather than having the private key stored on each of them individually.

This sort of behaviour should be the default for crypto libraries like openssl.

Going one step further, and allowing subkey certificates that restrict the Common Name to a subset of the CN from the primary certificate would great too. We could then allow, for example, self-management of wildcard domains. E.g: an organisation running, with a wildcard certificate for CNs * and could sign their own subkey certificate for CNs * and and give that to the people running only that part of the organisation. These people could then set up openssl to create subkeys for this new certificate on a daily basis.

Why this kind of delegation is not possible with x509 certificates boggles me, and if I am mistaken and it is possible, then why it is not currently in use everywhere boggles me even more!

In Short

We shouldn’t need to rely on a broken, unscalable revocation model. We should use time-sensitive subkeys instead, and not have primary keys stored in a front-facing process’s memory. Beter yet, not even on the same machine.

About Me

I’m currently studying Computer Science at Oxford University in the UK, and am a past president of the Oxford University Computer Society. I have a passion for technology, in particular ubiquitous computing, communication and security.

If you would like to send me an email regarding this article or anything else, pop over to my contact page, or find me on Twitter: @samlanning.


  • 2014/04/08 – 5:20pm GMT: Added clarification that the processes affected are those using the openssl libraries and not “openssl processes”.

How Qualcomm and the AllSeen Alliance are Changing the World of Technology, TODAY!

February 11th, 2014 by Posted in AllSeen Alliance, Articles, Technology

This post is a follow up to an article I wrote less than a month ago called The Future of Tech: Interoperability, and AllJoyn Doesn’t Realise Its Potential.


A brief summary of my previous article:

  • Our ‘technology future’ has a current major hurdle hindering its growth. The scene at the moment is a collection of incompatible walled-gardens, isolated ‘cloud’ ecosystems preventing our many devices / applications interoperating with one another. (eg: Google, Facebook and Apple’s incompatible platforms, media systems like Sonos and Apple’s AirPlay etc…)
  • ‘Hub’ companies like IFTTT and Revolv are a step in the right direction, but don’t fix the problem.
  • To realise our visions of the future, we need a standard, open, peer-to-peer platform / protocol which allows our devices and software to control one another and share and manage our data, regardless of manufacturer.
  • A platform like this would need to have security and privacy issues addressed front-and-centre.
  • Qualcomm have already started something called AllJoyn, along with the AllSeen Alliance.

AllSeen Alliance?

A couple of years ago, Qualcomm began to realise the problems that I pointed out in my previous article. They started a project called AllJoyn which aimed to solve these problems by implementing an open platform / protocol (like mentioned we need above).

Recently, Qualcomm have teamed up with the Linux Foundation to create a new consortium called the AllSeen Alliance. This alliance aims to bring lots of companies together to achieve the same goal that Qualcomm initially began doing by itself with AllJoyn. Qualcomm have donated AllJoyn (all it’s source code and documentation) to this new organisation.

The Alliance is already gaining quite a bit of traction, with notable companies already involved, including Haier, LG, Panasonic, Sharp and Cisco. (A full list of members can be found here).

In Short:

  • AllSeen Alliance is a consortium of companies with a common goal.
  • AllJoyn is the main project of the AllSeen Alliance.

This article will be outlining the core design concepts behind AllJoyn. (Warning: it gets a little technical…)

Addressing my previous article:

I was wrong. Before going into the specifics of AllJoyn, I’d like to correct my comments regarding the Alliance, in my previous post I said “There are a few differences though between my ideas and the Alliance’s, and I feel as though they are missing a trick”, I have now discovered this is completely false! Since writing the article, myself and a fellow student at Oxford have had the pleasure of a conference call with Liat Ben-Zur (Chairwoman of the Alliance) and Greg Burns (Chief Software Architect of AllJoyn).

The conference call was a complete eye-opener; their articulation of the current problems we face and the potential of a platform like this, along with their ideas for tackling the problems I’ve talked about, were not only similar to mine, they were more or less identical. As my colleague (who independently manifested the same ideas as myself) said to Greg during the call: “It’s as if you’re taking the ideas directly from my head and handing them back to me on a silver platter”.

So with that cleared up, and any distinction between my own ideas and Qualcomm’s proved non-existent, lets begin talking about AllJoyn itself.

The Design of AllJoyn

An open protocol to solve the problems we have mentioned would need to have the following features:

  • Work peer-to-peer.
  • Work on numerous communication layers, including, for example: bluetooth, ethernet + Wi-Fi, Wi-Fi direct, NFC, etc…
  • Include device identification and discovery.
  • Include a security layer providing authenticity, confidentiality, and integrity (tied in with device identification).
  • A control layer, with authorization. (We want to be able to control our washing machine from any of our devices, but wouldn’t want a visitor to be able to do the same with their phone.)
  • A data layer, with peer-to-peer synchronization, and authorization.
  • Provide suitable abstractions to be built upon, to allow for further features and services in the future.

Qualcomm have made the sensible decision to abstract these features into different modules, and the most high level view of AllJoyn looks a little like this:

High Level Diagram of AllJoyn

They have divided the features we would need from an open protocol like this into to main categories, the AllJoyn Core, and Services.

AllJoyn’s Core

The core part of the platform manages device identification, and discovery, transparently works across multiple communication platforms, and allows proximal peer-to-peer networks to be built up, so you can have topologies that look like this:

AllJoyn Topology

(Image from here and licensed under Creative Commons Attribution 4.0)

The core provides abstractions up to the next layer to allow services to run over the AllJoyn framework. There will be one instance of the core part of AllJoyn running on any device, managing communication to all other devices, discovering new devices, and managing traffic for all of the different services.

An application on a device will then be able to connect to AllJoin by either listening for connection requests of, or trying to connect to, specific services. This will allow it to communicate with any other application that can also speak the same service.

The core part of AllJoyn will automatically select the best methods to direct traffic to other devices, (which may, as the image above shows, be via other devices running AllJoyn).


The rest of the features I mentioned would be implemented by designing services on top of AllJoyn’s Core. So you would have a number of devices that are all AllJoyn compatible, each able to use a different selection of services.

You would have individual services for:

  • Sending notifications from a device (for example, when your doorbell rings, or when your washing has finished, you could have a notification appear on each of the active screens around the house).
  • Controlling devices (opening curtains, unlocking a door, starting your coffee machine, turning on and of lights, etc etc…).
  • Synchronizing your data across all of your devices.
  • Playing music at the same time throughout multiple speakers in your home.
  • Sending files / sharing links from one device to another.

And developers could create their own services to perform a specific need, for example, if you created a multi-player game, you could make an AllJoyn Service which allowed you to very easily incorporate peer-to-peer multi-player functionality in your app, cross-vendor, over a mixture of communications mediums.

Here are a couple of main services that are being developed as part of the AllJoyn project.

Notification Service

Mentioned many times throughout this article already, this service allows devices to broadcast human-readable notifications to any device which may be interested in it. Like your TV, smartphone or tablet.

Here is an example of it in action:

AllPlay Service

An interesting service (not yet open sourced) that allows you to play music simultaneously out of numerous speakers, again, this will be completely dependent of device manufacturer, and there are no legal contracts involved either. Forget Sonos and AirPlay!

What’s Next for AllJoyn

AllJoyn is already a fantastic platform, and it is only going to improve and expand as interest increases and more companies get involved.

Not all the bases have yet been covered for us to really feel like we have freed ourselves completely from the many walled gardens tech offers us today. For example, that data component I mention so frequently has yet to be given a service on AllJoyn, whicch would allow us to completely decouple our data from the ‘cloud’ and manage it exactly as we would like.

In addition, AllJoyn’s core is currently focussed heavily on proximal networks, but of course as it evolves, we’ll be able to access, for example, devices in our own home from anywhere with an internet connection, safely and securely.

The future for AllJoyn is certainly bright, be sure to check out more videos on YouTube covering each of the existing services and the core in more detail. Also, if you’re a developer, do get involved! AllJoyn is an open source project and welcomes contributions from anyone.


About Me

I’m a Computer Scientist, currently studying at Oxford University in the UK, and am a past president of the Oxford University Computer Society. I have a passion for technology, in particular ubiquitous computing, communication and security.

If you would like to send me an email regarding this article or anything else, pop over to my contact page, or find me on Twitter: @samlanning.

The Future of Tech: Interoperability

January 19th, 2014 by Posted in AllSeen Alliance, Articles, Technology

Ubiquitous Computing is a very big passion of mine, in fact I have spent a number of sleepless nights, and many other free hours thinking about this, and the future of technology over the past half year or so. Largely inspired by watching future concept videos by Corning, Microsoft and a few others, and by examining our current technology climate, I started to develop a few thoughts.

Let me paint you a picture…

You arrive at a hotel in a big city ahead of your business meeting the next day, you have previously booked your room and the hotel has sent you your digital key. You enter the hotel and follow the signs to your room, upon arriving at your door, you place your phone to a pad on the wall and the door unlocks. After entering your room, a screen appears on your phone asking you if you would like to connect to the room, you select “yes” and another screen asks you what you would like to share with the room. You select “Calendar Events for Duration of Stay”, “Alarms”, “Notifications” and “TV”.

After dropping off your bags, you lie down on your bed and switch on the TV, it is immediately tuned in to the last channel you were watching at home, and has your favourite channels, and recently recorded shows available from a quick menu. You decide to watch a TV program that you had set to record using your phone while travelling to the hotel.

When you decide to go to sleep, you change and switch your phone to sleep mode. After placing the phone on your bedside table the curtains close and the lights slowly dim until off.

The next morning, leading up to the time you have your alarm set for, the curtains begin to open until, at the alarm time, your preferred wake-me-up jingle plays through the bed and TV speakers.

You jump in the shower, and while in the shower you receive a message on your phone from the organiser of the meeting explaining that it had to be moved forward an hour, it is displayed on your shower screen. You quickly hit reply and dictate a message while rushing to finish in the shower, and after providing your 4-digit protective pin, the message is sent off.

After finishing in the shower, you check your calendar in the bathroom mirror and see that your event has already been updated. It also provides details of the planned travel and the latest time you should leave.

You manage to shave or do your hair and make up, and get changed before leaving and arriving at your meeting on time.

What’s Wrong

This is a similar scenario to those portrayed in the aforementioned concept videos, except with a few more operational details. The major point of this picture is that these devices are communicating, and not at a low level at all!

They are communicating, interoperating, far beyond what is possible at the moment, and it is not the hardware, the physics that make this science-fiction story hard to foresee. Not at all, all of the hardware is already there, and inexpensive (save for maybe the waterproof capacitive shower screen, and mirror), what is not there is the software.

In today’s world, this sort of vision is not possible, not unless all of the devices come from a single company, or unless you write custom software to interop everything, and provide an app for your hotel customers. And lets face it, both of those options are not ideal, especially if you want to be able to observe this level of user experience outside of the hotel, seamlessly.

Technology at the moment is a large collection of walled gardens, you have numerous companies competing to be the sole provider for different aspects of your digital and physical life. And each different field has a different collection of competing companies, all of whom can’t connect with each other.

We currently have a problem that some describe as the “Basket of Remotes”. Numerous gadgets and appliances, each company of which has their own ecosystem, you need an app or remote for your thermostat and smoke detector, your dishwasher, fridge, stereo system, TV or even front door lock.

Now some of you might claim that you don’t care about automation, but we have the same problem with general purpose computing, just our smartphones and computers have an insane number of walled gardens! Google, Dropbox, Microsoft, Apple, Facebook and many more are competing to be your sole cloud provider for all of your data, and again none are interoperable.

The current solution

Now for the most part, companies behind all recent tech innovations, either physical or digital, release API’s that allow developers to easily control said appliance, or be able to access said data. They claim then that this makes their respective platforms open, however it does not fix the walled garden problem. You can’t get the API from two things, and push them together and have them instantly work together, instantly interoperable… you need glue, you need a developer to decide to make the two completely different things talk to each other first. This is not good enough for consumers!

What this has resulted in for the time being is a whole new collection of companies starting up. Companies designed to try and bring your collections of technology back together. Companies like If This Then That (IFTTT), tying your digital life together, allowing you to, for example, be able to copy a note from Evernote to Google Drive whenever you make one, or send a text to turn on your Philips Hue Light bulb. And more Appliance/Automation-Based companies like Revolv, who have brought out a “hub” that can control a number of appliances in the home.

Both of these solutions are far from Ideal. We should be able to purchase a brand new product and have it instantly integrated into our home. Or a brand new bit of software that does awesome things with time management, and let it have access to all of our calendars immediately, irrespective of whether we’re using Google, Apple, or just have our calendars stored locally. We should not have to wait until a particular hub company has decided to pick up all of the pieces of technology we want to communicate with one another.

What’s Needed

What we need is an open protocol, a platform, that allows everything I could possibly want to talk to one another, in a secure manner. Allow me to control any of my devices from any other, and have the data I want synced to the devices I want, and shared with whoever I want.

Something like this would need:

  • Device identification, discovery and authentication.
  • A Control layer, so we can, for example, open the curtains from our phones.
  • A Data layer, with synchronisation and access control capabilities onto which schemas / specifications for particular data types can be drawn out, like calendar or alarm data.
  • Sufficient security and privacy concerns addressed (access control for the data, encryption etc…).

Armed with a platform like this, we could make certain situations a reality…

  • The story above.
  • Going to a friends house, and instantly sharing a video you just watched by playing it on the TV.
  • Hosting a party where anyone can submit song requests, anything from a Spotify link to an mp3 or flac file hosted on their phone, to something stored on the host’s own music library.
  • Driving a car down the road, and if there is a problem on the road up ahead, having the details relayed to your car from which the Sat-Nav can plot a new route.
  • Arriving at home to find the oven pre-heated and the lights switched on to your favourite mood as you walk in.
  • Have your music play throughout your house in sync, over all the different devices you have, from all the different brands, not just within the walled gardens of Sonos or Apple AirPlay.
  • Anything else you can imagine…

All while your data is fully under your control, and not at the mercy of cloud providers and by extension the NSA.

What’s Happening Now

After formulating all of these Ideas, and talking about it to people, a friend found a project by Qualcomm called AllJoyn (now part of a Linux Foundation Collaborative Project called the AllSeen Alliance)

AllJoyn and the AllSeen Alliance is in essence, an exact realisation of the memory dump you have just read. And companies including LG, Panasonic, and Sharp are already members! The structure and ethos of the alliance I believe is spot on, instead of just designing a spec, companies will be coming together to actually design and implement the framework, and releasing all the code open source to allow anyone to get involved! This is how I would personally run the project myself.

There are a few differences though between my ideas and the Alliance’s, and I feel as though they are missing a trick. They are currently quite focussed on Home Automation (which is, don’t get me wrong, a very large part of this whole idea), however, although it would seem they have the “Device Discovery” and “Control” bases covered, they mention little on user data.

Do they foresee scenarios like the one mentioned at the start of this article, where I want to be able to share a subset of my data to the hotel so that I can easily access it during my stay, where access control is managed by my phone? Where my data is synced across all of my devices at home without even having to touch any cloud providers?

If they don’t, then there’s some potential in their project that they are not noticing or embracing, and in my personal opinion, they definitely should be! It is the last piece of the puzzle to reaching that sci-fi technology dream! Until that point, I will be keeping a watchful eye on the project, and I would encourage you to get involved any way you can. If you’re a company, become a member, if you’re an individual, sign up to the forums and mailing list and contribute to the open source code, or start writing some apps that use AllJoyn.

Since writing this article, I have discovered that AllJoyn actually does in fact realise its potential, and I have written a follow-up article: How Qualcomm and the AllSeen Alliance are Changing the World of Technology, TODAY!


About Me

I’m currently studying Computer Science at Oxford University in the UK, and am a past president of the Oxford University Computer Society. I have a passion for technology, in particular ubiquitous computing, communication and security.

If you would like to send me an email regarding this article or anything else, pop over to my contact page, or find me on Twitter: @samlanning.


  • 2014/01/19 – 4pm GMT: Added more information / opinions about AllSeen Alliance
  • 2014/01/19 – 10pm GMT: Added links
  • 2014/02/11 – 1am GMT: Updated information about new article, and corrections.
  • 2014/04/23 – 12am GMT: Changed title from “The Future of Tech: Interoperability, AllJoyn Doesn’t Realise It’s Potential” to just “The Future of Tech: Interoperability”.

Teaching Programming to Children (the current UK Status)

October 17th, 2013 by Posted in Education, Essays, Technology
Note: I actually originally wrote this article as an essay submission to my Tutor at Oxford, but I’m passionate enough about the subject, and just about happy enough with this article to post it online. It was originally titled “How should programming be taught to school children?” Also as an aside, I have actually had lunch with Simon Peyton-Jones previously, and he probably has a large part to play in my enthusiasm for this subject.

Teaching programming, and more generally computing, at the primary and secondary school level is something the UK is yet to get right. There is little doubt that the general consensus of the public is that more coding needs to be taught to students of all ages (a 2012 Poll by the guardian showed that 93% of those asked thought this). Other countries in Europe are making great strides with this; Estonia, for example, have reached a stage where 100% of publicly educated students will learn how to code.

The majority of secondary schools teach I.C.T. (Information and Communication Technology) as a compulsory subject, and nothing more; but I.C.T is not Computer Science, just the same as Numeracy is not Mathematics. Computer Science is a discipline, but is not thought of in that way at schools. Students and teachers are taught to be consumers, use existing software to perform tasks (e.g. Microsoft Office, Web Browsers, Mobile Phone Apps), and are not taught about the technology and mathematics that underpins the hardware and software that they take for granted each day.

As a result of this, and the fact that in our current society, these skills come naturally to children, they quickly find the course boring, and fewer and fewer are being attracted to going into the field of computer science / technology later on. Those who get as far as applying to university for a computer science degree tend to be those who were lucky enough to discover, of their own accord, the wider field that is computer science, and escaped the bounds of their limited I.C.T education. These students get to this stage in spite of not because of their school education.

Gone are the days of the BBC Micro where many children were given the right exposure to programming, and fell in love with the endless possibilities. Things need to change; Computer Science needs to be re-born, and needs new exposure in the UK education system right from the start, from primary school.

Fortunately, these thoughts are spreading: more and more important people and companies are getting involved, and not just in the UK, but in the USA, where the situation is much the same. Global innovations like and are pushing for this to change, and in the UK we have and a new grass roots organisation called Computing at School (CAS) which has had tremendous success. They have been heading the design of a brand new National Curriculum for Computer Science which will go ahead in September 2014.

“The new National Curriculum establishes computer science as a core discipline that every child will learn from primary school onwards. This is a huge change, and we need the help of professional software developers everywhere to support, encourage, and equip our Computing teachers with the confidence, knowledge and skills they need to deliver the new curriculum.” – Simon Peyton Jones

Like any discipline, teaching children needs to be radically different to teaching adults. Depending on their age, lessons may need to be fun and creative to ensure that the children remain engaged and do not become bored. However, possibly more so than other subjects, as you progress through learning, you can receive immediate feedback, and take advantage of your new knowledge instantly, particularly for small steps. For example, if a child is creating a game, and learns how to use a variable to move a sprite across the screen at a particular speed, they can instantly change that variable to a different value and see how it affects the sprite. It is this curiosity, experimentation and this want to create things that drives many of today’s people in the field to start in the first place.

A very successful project to try and introduce children to programming is Scratch, a software project and online community by researchers at MIT. The scratch software has a graphical interface with a “stage” area and a “scripts” area. The stage area is a virtual screen where you can place sprites and control them. When something in the stage area is selected, you can create scripts for it by dragging blocks into the scripts area and connecting these blocks together.

The blocks style of writing scripts is extremely intuitive, and as Scratch is designed for 8-16 year olds, kids are able to pick it up extremely well. It introduces ideas like loops, functions, variables and event listeners, without ever having to introduce code syntax, understand classes, or worry about compiler errors. It is an excellent abstraction to programming languages in general. Scratch also comes with an extensive library of sprites, images and sounds, so children are able to easily use their imagination, creativity and curiosity to challenge and extend their own logical abilities and programming skills. Keeping children entertained and engaged when teaching Scratch is not difficult.

Of course, Scratch is in a sand-boxed environment: the user only gets a small “stage” area to play around with, and naturally at some point, children will each want to explore different mediums and devices which they can program.

One medium that is suggested quite frequently is the Raspberry Pi, a budget credit-card sized computer designed specifically for computer science education (although granted, it has found its way into almost every corner of the Tech industry). It is designed to run Linux, and you can download a “New Out Of Box Software” (NOOBS) package which will be booted into on the Pi and includes various Pi-Optimised Linux distributions.

The Raspberry Pi is an exposed board, (i.e. doesn’t, by default, come in a case) and has exposed GPIO (General Purpose Input/Output) pins on the board that allow you to connect various peripherals or components to it, for example: motors, speakers, LCD displays, or another board with LEDs. The Raspberry Pi is not just a computer, it is a device that you can program to control an endless list of physical “things”. In addition, the fact that they are exposed, and that children can “see the inner workings” of the devices, or just inspect them, seems to help significantly with getting them excited about using them.

Like Scratch, the Raspberry Pi has had a lot of success in the education industry. In addition, some of the Linux distributions included with “NOOBS” have Scratch pre-installed, and even better, there is a scratch software plug-in that allows you to control the Pi’s GPIO Pins from within scratch programs, so within the comfort of scratch, you can control almost any physical device connected to the raspberry pi.

A language which seems to be quite popular among teachers, and among raspberry pi users is Python. It is frequently used as the next stepping stone after learning Scratch. Python is a particularly easy to learn programming language, with a clean syntax, and indentation used to indicate code blocks rather than curly braces (this somewhat forces the code to look cleaner). There are also a plethora of libraries, both in the standard library, and in Python’s Package Index (PyPi), that make most tasks significantly easier, including a large number exclusively for the Raspberry Pi, and even for specific GPIO accessories.

Scratch, the Raspberry Pi and Python certainly provide a solid set of tools to help introduce programming to anyone from age 8 right up until the end of 6th form, and indeed, python is not only an educational language, but is used extensively in industry as well. It is also quite easy to translate concepts, algorithms, control flow techniques and just programming skills in general from Scratch’s block “script” creator, to python as well; hence providing a natural progression from no coding experience to proficient python programmer.

There are a large number of resources online for teaching school children, in particular class plans and hand-outs, and a large number of them are tailored for Scratch, the Raspberry Pi, Python, or a combination of these (For examples, see the website or the CAS Resources). It would seem that with regards to the tools that have proved successful when it comes to teaching children, extensive research and trials have already been done; further, it appears there is a general consensus among teachers that have been involved in these first steps in educating the next generation, that these tools are more than appropriate to introduce and excite children with the field of computer science. In addition, the brand new 2014 curriculum should, for the most part, solve these problems we have.

The only major task that seems to be left is educating, supporting and encouraging existing I.C.T teachers to teach the new curriculum, and to encourage more people to go into teaching Computer Science at school. It is up to people currently in the I.T. industry, and in Academia, to do so.