Month: December 2017

Undeniably smart: a word on self-executing contracts

One of the core and most fantastic features of blockchain infrastructures is the notion of smart contracts, also called self-executing contracts. This is what makes cryptocurrencies secure. Put simply, smart contracts do not need enforcement, or, in other words, they enforce themselves – exclusively due to the way they are drafted.

Every time that you use a cash machine, you are entering a contract with your bank. Your obligations are to provide a card and a pin. The bank’s obligations are to check the pin and give you money.

This contract has a number of enforcement flaws. You can use a stolen card. The ATM might have been skimmed. Or it can just eat your card, leaving you with no card and no cash. The bank’s software could be buggy and take more money from your account than it gave to you. In other words, there exist a number of situations where you or your bank may fail to fulfill its part of the contract, with the violation needed to be escalated to authorities outside the contract (e.g. a bank teller or the police force).

Smart contracts are not threatened by flaws like this. They just work, by their design. In Bitcoin, there is no way to forge a transaction, or to fool someone into the content of your wallet, because the environment provides a secure way to verify every single transaction via a so-called distributed ledger, which works in a mathematically proven way.

While commonly associated with blockchain technologies, smart contracts may actually come in a variety of forms and shapes. Most of Internet security protocols rely on them in one way or another. For example, Diffie-Hellman key exchange algorithm is a typical smart contract, even though the term itself was introduced much later than the algorithm. You can’t obtain the shared key without following the contract. If you violate the protocol, you’ll end up with a wrong key, so the need to get the correct key enforces you to implement and perform the protocol correctly.

Ironically, (or logically) Internet protocols suck heavily in the functions not covered by the self-enforcing logic. This is particularly annoying for protocols which are supposed to provide communication security. I think I won’t be mistaken if I say that a weakly implemented certificate validation routine in SSL/TLS is the weakest point of a huge number of the protocol deployments, having a potential of bringing in much bigger troubles than BEAST, POODLE and Heartbleed combined. Many, many times I watched developers neglecting this important compound of the protocol, by either bypassing the certificate validation entirely, or using simplified routines not providing adequate protection. Many times I pointed that out to them, and very few bothered to do anything to fix it.

This flaw continues into TLS 1.3*, with the certificate validation compound keeping its role as a standalone external module with the only purpose to tell ’yes’ or ‘no’ to the main protocol implementation when asked. Needless to say, it is very tempting to implement this module as a hard-coded ‘yes’ to avoid bothering with the validation altogether and have the project up-and-running right here, right now, especially if you are under time and budget pressure.

Designing the certificate validation routine into the protocol in the form of a self-enforcing contract would have done a great job in increasing its security. There would be no way for TLS implementers to cheat by avoiding the validation procedure or implementing it in a wrong/simplified way. The validation module would either work right, or cause the whole secure negotiation to fail.

To be fair, this is easier said than done. Designing a robust self-executing contract requires a deep knowledge of maths and formal logic, as well as cryptography. Decent level of knowledge of the application area of the contract is also quite essential. Ultimately, a proper self-executing contract is a high-grade cryptographic algorithm, and as such is subject to all the relevant strength implications. A good smart contract should be capable of proving its correctness and cryptographic strength formally, which is a good piece of challenge for inventors.

Still, despite the challenges, self-enforcing contracts are set to take a major part in our society. They do a great job by removing the whole surface for wrongdoing, fraud, and human error, and bringing in simplicity and convenience – and this is something that a lot of our typical everyday scenarios need.

Just to make you sure that the next generation ATM never eats your card.

(*) Strictly speaking, this is not a flaw of TLS as a protocol (as the standard thoughtfully transfers all responsibility for handling certificate validation properly to the implementers), but this fact doesn’t make TLS environments any more secure.

Picture credit: Pixabay

Skill vs Technology: a zero-sum game?

Last week I came across two peculiar stories dedicated to the role played by technology in the evolution of the civil aviation industry. While the stories were barely related to each other at first glance – and had I come across them at different points in time I probably would have never spot that huge connection between them – but luckily I was still thinking about the first story when I bumped into the second one, and immediate realisation of the scale of the apparent trend made quite an impression on me.

That first story was about the role of technology in the crash of Air France transatlantic flight 447 back in 2009. The primary conclusion from the investigation that the article elaborates on is that the pilots were so got used to flying with assistance of the autopilot that they became completely lost when they faced the need to fly the aircraft manually. They’ve just got no understanding of the situation whatsoever, as they’ve lacked the hands-on feel for flying the aircraft at cruise altitudes – something normally handled by the autopilot. In addition to that, the autopilot, designed with intelligence and pilot-friendliness in mind, didn’t warn the pilots that the aircraft was approaching a complete stall, after interpreting the way-too-sharply plummeting speed as an indicator of a probable false alarm.

Confused and lost, the pilots applied several corrective actions to get the aircraft back on its course. Unfortunately, due to the pilots’ lack of situational awareness, those actions had become fatal. The A330 lost its airspeed and crashed into the ocean, killing all 228 people on board. Ironically, the investigation had shown that should the pilots not intervene in the situation, AF447 would have continued at its cruise altitude as it should even with its autopilot switched off.

The second story I read was on a far more positive side, depicting prospective transition of the London City airport air traffic control tower from the airfield itself to a small place called Swanwick, Hampshire, some 80 miles away. Specifically, twelve HD screens and a thick communication channel are going to be used to replace the existing watch tower, and are claimed to provide far better insight into aircraft landings and take-offs performed at the airport, as well as a number of augmented reality perks. The experience of LCY is then expected to be picked up by other airports around the country, effectively making air traffic control tower operations an outsourced business.

The fact that impressed me the most about these two articles was that they both, despite being barely related per se, are essentially telling us the same story, the story of skills typically attributed to humans being taken over by technology. It’s just that the first article tells us about the end of the story, while the second one is rather at the very beginning of it.

Just like such advances in technology as the glass cockpit and way-too-smart autopilots led to pilots losing their grip in manual flying, switching to augmented HD view of the runway will inevitably lead to air traffic control operators losing their basic skills, like tuning binoculars or assessing meteorological conditions by a dozen of nearly subconscious cues. The trained sharpness of their eyes, now supported by HD zoom, will most certainly diminish. Sooner or later, the operators will be unable to manage the runway efficiently without being assisted by the technology.

And this is the challenge we are going to face in the near future. The more human activities typically referred to as ‘acquired skills’ are going to be taken over by technology and automation, the less able we are going to be about those skills ourselves. If a muscle isn’t constantly trained, it wears off. If a musician stops playing regularly, she eventually loses her skill to improvise. If a cook doesn’t dedicate as much time to cooking, his food loses its character, despite cooked from the same quality ingredients and using the same proportions.

And that’s not necessarily bad. As the technology is inevitably making its way to our lives, taking over those of our skills which it can perform better than we do, there is no reason not to embrace it – but embrace thoughtfully, realising the consequences of us losing grip on them. Remember that we had lost a big deal of our skills to the past already. Your great-grandfather is very likely to had been particularly good in fox hunting, your grandad probably performed much better than you in fly fishing, and certainly a much wider proportion of population were capable in horse riding two centuries ago than it is today. Those skills had been taken away from us by technology and general obsolescence, but do we really need them today?

What we need though is to have a clear understanding of the consequences of sharing activities we got used to do with technology, and be prepared to observe a steep decline in the quality of our own respective hand skills as technology gradually takes them over. Understanding that problem alone and taking our imperfect human nature as it is will most certainly help us manage the risks around technological advances more efficiently.

(pictured: a prototype of the digital control room at NATS in Swanwick, credit: NATS)