Category: Uncategorized

Security ain’t simple, and it will never be

Every few months or so, we get a message from a customer that sounds like this:

I am looking to integrate JWT to my app. I found this tutorial and trying to follow it in my code. I am now trying to encrypt the signature with an RSA public key and decrypt it later with my private key to compare the hashes, but for some reasons my encryption results are always different.

If you don’t follow what’s happening, and I think most of my readers don’t, here’s what.

First, one guy publishes a tutorial that explains the townsfolk a general process of building a space rocket. Just take some titanium for the body, solder a guidance system (shouldn’t be that much harder than soldering that SatNav chip to your Arduino board), get some rocket fuel – just be careful, it is a bit super-deadly – and in a few months top you’ll be able to check for yourself whether the Great Wall can really be seen from space.

This makes Mick, an honest town lad, interested (he was a bit into rockets himself back in Y7), and he decides to launch a space travel business, using that tutorial as a guide for building his own space rocket. Mick decides to replace titanium with aluminum (as that is cheaper that way), but his aluminum doesn’t stay in shape as per the instructions because the feathering is too heavy for it. He feels frustrated and decides to get rid of some of the feathering.

Meanwhile, the town is getting interested in the project, and Mick’s bookings are growing steadily.

* * *

When my friend got her first car, her mum said to her: I’m super happy for you, darling. Could you please promise me that you will always bear in mind one important thing: it may not always look like that, but you are about to take care of a 3-tonne killing machine. Please be careful.

My friend recalls these words every time she turns the key.

We need to grow up. We need to understand that security is serious. We need to bear in mind that by integrating security into a product we are taking care, well, not of a killing machine, but of something of a very similar scale. Taking it lightly is extremely dangerous.

And I think Mick is as much of a victim here as his customers are. Tutorials like the one mentioned in the beginning of this post make complex things look simple. They make high-risk systems appear risk-free. They say, ah look at this funny thing here, it is called security and even you can do it. Go ahead!

I have actually been a Mick numerous times myself. I love doing things with my hands and consider myself a capable DIY’er – something of an orange or even green belt. And yet, dozens of times I have let YouTube DIY videos delude myself into thinking that a job is not as complex as I thought it was. Hey, just look how easy it was for that young couple to build a patio. Surely it can’t be that hard?

The outcome? I don’t want to talk about it.

And that’s why I stopped writing any manuals, guidance, todo’s, instructions, or whitepapers on security topics unless I am absolutely certain that the audience is capable of following them. Even when I do, I warn my readers that the job they are looking to embark on requires excellent technical competence, and I do so boldly and unambiguously. Security engineering is one of the largest surfaces for the dropped washers, and by directing irresponsibly you are playing your own part in creating the future chaos.

So, let’s re-iterate it for one last time:

WARNING:

Security is complex and can be dangerous if approached irresponsibly. Please, do not make it look simple.

Picture credit: FDA

That is no question

Back in 1854 a renowned mathematician George Boole was the first to describe the concepts of algebra and logic over a binary field, which were eventually named after him and are now regarded as one of the pillars of the information age.

The power and universality of foundations given to IT engineers and scholars by the works of Boole had one adverse effect though. Boolean had landed such a major role in software development tools and in developers’ minds, that the concept started to be abused and misused by being employed in scenarios for which it wasn’t exactly fit.

For as long as software programming was primarily a transcription of logical chains into English words and consisted largely of unequivocal instructions alike ‘is the value stored in CX greater than zero?’ everything worked well.

And then everything went out of sync. Since around 70’s, software programming started making its way up to higher, much higher abstraction layers. C has arrived, followed by OOP and C++, and then Java, Python, and Ruby. Complexity levels of programming tasks skyrocketed. No-one cared about contents of CX anymore. Questions answered by programmers in their code started resembling non-trivial day-to-day questions that we come across in real life. Yet the tools in the box, despite looking smart, shiny, and new, remained largely the same.

Let me ask you a simple question.

Can the outcome of a friend-or-foe identification – e.g. that of an aircraft – be represented with a Boolean type?

What could be easier, at first glance, – the aircraft is either friend or foe, right?

Wrong. There are at least two more possible outcomes: “the aircraft has not been positively identified (can be either friend or foe),” and “no aircraft has ultimately been found.” Those two outcomes are of no less importance than the ‘primary’ ones, and, being ignored, may lead to erroneous or even catastrophic decisions.

If you answered yes, don’t be too hard on yourself. The human brain is a skilful optimizer. Despite being often referred to as ‘intelligent’, when left to its own devices it actually does everything in its power to think less. It operates an impressive arsenal of corner cutting techniques, such as question substitution, simplification, framing, priming, and around a hundred of others to avoid the actual thinking in favour of pattern-based decisions.

And this doesn’t marry well with Boolean type. The problem of Boolean is that it offers an illusion of an obvious answer, suggesting a simple choice between two options where there is no actual choice, or where there might be something besides that choice.

Working hard on optimizing its decision making process, our brain celebrates the chance to substitute the whole set of outcomes with an easier choice between two opposites: yes-or-no, friend-or-foe, right-or-left, good-or-bad, a-boy-or-a-girl. Inspired by simplicity of the answer, the analytic part of our brain gives up and accepts the choice – even if the opposites together only comprise so much of the whole variety of the outcomes.

Development environments kindly assist the irrational part of our brain by providing the tools. I find it amusing that in line with the evolution of programming languages Boolean was given an increasingly significant presence: from none in assembly language, through int-emulated surrogate in C, to a dedicated type in C# and Java. That is, as software developers had to deal with questions more and more vague, the development frameworks kindly offered answers more and more simple.

“Wait,”, a smart programmer would say, “and what about exceptions? What about nullable types? Aren’t those supposed to deal with everything that goes beyond true and false?”

In some scenarios they do – and in the others they don’t. Exceptions may work well where there is clearly a yes-or-no choice that falls in, and a marginal alternative that falls out. The problem is that in many instances there is no yes-or-no choice at all, but our little grey cells would tells us there is. Apart from that, exceptions are an opt-in technique for our brain: something that needs to be considered proactively – and therefore they will be among the first to be ‘optimized’ and neglected. How many programmers do you personally know that do exception handling right? And how many do you know that don’t?

And so it goes. It’s Friday, well after 7pm. It’s only a programmer and a QA guy in the deserted office. Their deadline passed a few days ago. They are rushing to finish the system tonight. The programmer starts typing, ‘if…’ and stops for a moment. He quickly glances at the bottom-right corner of his screen: 7:53pm. He sighs, takes a sip of his cooled down tea, and completes the line:

if (!friend) { missile.launch(); }

His code is complete now. He commits the changes, writes a quick note to the client, and drives home to join his family at a late dinner. The QA chap runs a quick round of positive tests and follows his fellow.

You already know what happened next.

* * *

This story is not about negligent programmers. Rather, it is about the dangerous mix brought in by peculiarities of human mind and perks offered by modern development environments, which together give rise to serious logical errors in programs.

Most real-life questions that arise on the uneven ground under our feet have no black-or-white answers. Yet, for many of them, it is way too easy to get caught in the trap of narrowing the whole set of answers down to two mutually exclusive absolutes. The narrower becomes the gap between the programmer’s way of thinking and the human’s, the clearer this problem exposes itself in the software development profession.

So the next time you are tempted to think of some characteristic as a boolean, do make an effort to ask yourself: does this choice really have only two possible options? Didn’t I neglect any important outcomes? Isn’t my mind trying to cut short and take advantage on me?

Because it most certainly will.

Pic credit: mindfulyourownbusiness.com

Facepalm

Facebook, ever again, shows that it prefers to learn on its own mistakes rather than someone else’s. This time, it’s about storing passwords in plain text: a textbook security negligence, at different times stepped on by Equifax, Adobe, and Sony.

And this really doesn’t help in building confidence in the social network. We entrust them our most personal pieces of information, and they don’t give a damn about keeping it safe.

“We have found no evidence to date that anyone internally abused or improperly accessed them.”, said Pedro Canahuati, Facebook’s vice president of engineering, security, and privacy. Given all the recent breaches in this company’s security, I can’t help translating this to human language as “we didn’t bother so we didn’t put any access control audit mechanisms in place, so whoever saw your passwords, there is no (and can’t be) any real evidence to that.”

Just a couple of days ago I was asked to send money via Facebook payment service. In the middle of the payment process I realized it is not possible to make the payment – which would have been a one-off one for me – without having Facebook remember either my card or Paypal details. I stopped, closed the Facebook tab, and paid with a different method. Glad I did.

Picture credit: Alex E. Proimos

On Document Certification

Just like in many other countries, here in the UK there is a concept of document certification, a legal mechanism that allows residents to prove their identity by supplying certified photocopies of their identification documents (usually a driving licence and a recent utility bill) instead of the originals. This comes particularly handy if someone needs to prove their identity to a distant entity without going there physically or sending the originals by post. In most scenarios, certified documents have the same legal power as the corresponding originals.

Certification service is usually provided by public entities or persons ‘of good standing’, such as solicitors, local councils, notaries, and also the post office. An authorised official compares the photocopy to the original document, making sure they look exactly the same, and certifies the authenticity of the copy with their signature and/or seal.

A copy of a council tax bill certified by the post office

From the point of view of cryptography, document certification is a typical Trusted Third Party scheme. By certifying your documents, the official acts as an independent and verifiable third party with no conflict of interest with the originator and the recipient of the documents whatsoever.

Sadly, the scheme, as used in the UK and other European countries, is not entirely flawless. There are scenarios where a malicious individual or company can fraudulently use it to steal the document owner’s identity and use it for their own purposes. Imagine the following scenario:

1) Your new tax advisor asks you to prove your identity to her by sending certified copies of your ID and address to her (this is a genuine legal requirement imposed by Anti Money Laundering regulations).

2) She then remotely registers a limited company in Jersey. When asked for her ID by the company registrar (who follows the same AML ruling), she sends them the certified copies she’d received from you. The registrar has no reason not to trust certified documents, so they accept them.

3) Congratulations, now you are a rightful and fully accountable (with a stress on ‘fully accountable’) owner of that company in Jersey. Profit? Not for you, I’m afraid.

Cryptographers call this type of exploitation ‘a man in the middle.’ Being way more popular in electronic communication protocols, it can still be used to hack offline protocols, just like this one above. What you need for this attack to work, apart from the actors – a sender, a receiver, and, of course, that dark man in the middle who will be playing pass the parcel with both of you, – is an important factor called the absence of proof of origin.

The company registrar in Jersey has no means to verify that the documents they receive come from the real you. Really, what certification proves is that the photocopies are authentic. It doesn’t prove that you’ve made these copies willingly, knowingly, or with intent to set up an LTD. On the other hand, you have no means to ensure that the copies you sent to the tax advisor won’t go somewhere else. That’s how the concept of ‘proof of authenticity of a photocopy’ is mistakenly substituted for ‘proof of ID’.

So how to avoid getting your identity stolen by a disgraceful service?

Try to avoid employing photocopy certification at first place, if possible, even if such option is on the table. If there is a viable option to proof your identity in person, do it. A 30 mile journey is nothing comparing to dealing with the consequences of identity theft.

If you still have to do it remotely, perform due diligence on whoever is requesting the certification. Is it a reputable company? How long has it been around? Does it comply with the data protection act?

If possible, write a context-specific note on the certified copy. Let your note describe what this copy is intended for. For example,

Attn: Ms J Roberts, City Solicitors LLP, Re: Capital Gains Tax Affairs, in response to your letter Ref 30284-1 of 30/03/2018, 02/04/2018.

This will prevent the document from being re-used for a different purpose, as a writing of such kind will most certainly attract attention of an unintended recipient.

I believe that rules of document certification should change in a similar manner to actually provide for ‘proof of ID’ for the requester and ‘proof of use’ for the submitter, rather than a dubious ‘proof of authenticity of a photocopy’. What we need to do is extend the certifying writing with two pieces of information – ‘labels,’ – one from the requester, and another from the submitter.

The certifying official would then write both labels on the photocopy being certified, for example,

I certify these documents following a request from High Street Solicitors LLP Ref #311-235-1 (requester’s label), to be used in a civil case #213-1 ONLY (your label)

– thus unequivocally binding the certification to that specific context.

Having received a certified document created in such manner, the requester would know that it was created in response to their specific request. The document holder, on the other hand, could also be sure that the photocopy can only be used for the purpose they declared in their part of the certifying writing.

(A Belated) Christmas Story

Last Christmas, I came across a quite bizarre targeting experience.

Just a few days before Christmas, during my final gift hunt, I visited a large department store to buy a present to a member of my family. I am not very good at shopping, yet I had enough luck to find the ideal option that I immediately knew they would love, take it to the cash desk, and leave the store quickly.

Later on the day, I started observing new ads in my social network feeds. The strangest thing about them was that they were promoting the exact same brand that I had chosen for my family member a few hours ago.

It’s not a secret that we all are being tracked 24/7 by data aggregators, with every single step we make being monitored, recorded, and used later to sell us goods ‘carefully picked’ for us. Everyone of us have come across this annoying situation a thousand times, when our browsing experience all of a sudden became flooded with ads of goods and brands we searched a couple of days before (and some of us may even have ended up with a spoiled surprise if they shared their device with a girlfriend). And with voice assistants coming into play it is well enough just to mention a brand aloud while hanging around your phone to be caught.

But in this case everything was utterly different.

– It was quite unusual for me to buy a product of this particular kind and brand. To be exact, I have never bought anything similar in the past.

– It was a purely offline purchase, and a nearly random choice. No preliminary research. No shopping around for different brands. Saw it, liked it, bought it.

– The purchase being made at a large department store made tracking the chosen brand by location next to impossible. The location service on my phone was off anyway.

– Needless to say that my voice assistant was, and always is, off.

After spending quite a bit of time trying to figure out the source for the leak, I can say for sure that the only link between me and the purchase was my debit card that I used to pay for the gift. And this raises two uncomfortable questions: plainly, ‘who?’ and ‘how?’

The transaction involves the shop, which sells me the item, and the bank, which charges my card. These two business operations, per se, are not connected to each other – the shop has no access to my card details, and the bank has no access to the contents of the till receipt. Yet, the data aggregator needs both pieces of information to know about the purchase!

Obviously, the shop leaked my basket. But how did the aggregator manage to set it off against my identity?

There are only two possible mechanisms to do that without violating payment card industry legislation, and, frankly, I don’t know the use of which one is worse to admit.

The first is that the bank communicates all my transactions to the aggregator. This is easy to do technically, and by signing up with your bank you effectively allowed them to treat your account as they want (re-read your current account use policy, if you don’t believe me). It is easy for the aggregator to establish a correspondence between the basket and the card by the amount, time of purchase, and the merchant. An implication from this version is that your income, financial position, and spending habits are known to a much bigger crowd and at much greater level of detail than you supposed they are. And considering the recent leaks from Equifax, that crowd gains a really enormous size.

The second mechanism clears the bank and assumes that the aggregator uses a few pieces of intelligence they hold about us to establish the match. This is much, much harder, but not impossible. With each purchase you make, the shop gets hold of a tiny piece of your card details (as a general rule, the last four digits of the card number – you will often find them printed on your shop receipts). They can send this little piece to the aggregator together with the contents of your basket. The aggregator would then add this piece of evidence to a huge neural network which they use to store all sorts of information about us – our address, recent purchases, spending habits, and shopping routes, which they accumulate over the years. The network would then use all its knowledge about the persons whose card numbers end with the same four digits as provided by the shop, to assign probabilities to assumptions that the purchase in question was made by each particular person from that list. The person with the highest probability, or maybe a few of them, would then be selected as a target for the next campaign from that brand.

In either case, it’s not good. The main issue is that, one way or another, we don’t know the depth of the aggregators’ knowledge about us. And when you don’t know the rules of the game, you start suspecting the worst.

And who knows whether the worst you are suspecting – that is, the worst as you know or assume it – is the worst worst there is.

N. B. If I start seeing ads from that brand in the near future again, I will know for sure it has nothing to do with the bank.

Picture credit: pxhere.com

Undeniably smarter: a few more words on smart contracts

I believe a couple of statements from my last post need some clarifications, the most important being that it is most certainly too early for lawyers to start looking for new qualifications – if ever at all.

Self-enforcing contracts can’t replace human lawyers, and won’t do so in foreseeable future. There will always be a place for a well-drafted written contract, just as there will always be a place for professionals knowing how to compose it.

There are no contradictions here. Self-enforcing contracts have a very specific application area. They are perfectly suited for defining and enforcing relationships where the parties are subject to well-defined obligations, which can be formalized and verified in mathematical or logical way. Particular examples of those are cryptocurrencies, stock exchange, automated tellers and vending machines, and various kinds of automated non-repudiation and proof-of-identity check mechanisms. And yes, you will still need a lawyer for anything harder than that. Both traditional and self-enforcing contracts will therefore find their own place under the sun.

Even more, the evolution of self-enforcing contracts will give rise to a new legal specialty of a self-enforcing contract professional. This function will need to possess and combine typical skills of a lawyer with those of a mathematician/cryptographer, to be able to produce robust and provably secure self-enforcing contracts.

These changes, in fact, are no different to changes we are observing in nearly any other area being transformed by the computer-led innovation – let’s leave the creative stuff for us humans, and let the computer do the routine.

Picture credit: openclipart

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)

When the theft is inevitable

The hack of Equifax data centre followed by the Yahoo’s revelation of the exposure of its 3bn user accounts (in contrast to 1bn reported before) once again drew attention to the question of exposure of our private and personal data retained by global information aggregators. Due to enormous amounts of information they hold about you, me, and millions of others, they are quite a catch for cyber criminals. As the number of attacks similar to the one that targeted Equifax and their sophistication level will undoubtedly be increasing in near future, so will the chance of your personal data ending up in the hands of criminals.

While there is little we can do about Equifax and their security competencies, we certainly can do a lot more about platforms and services within our control. I am not talking social networks here; surprisingly, the fact that we understand the risks they pose to our privacy helps us perform some form of self-moderation when sharing our private details through them.

Such institution as banks, insurance companies, online retailers, payment processors, and major cross-industry service providers like BT, NHS, or DVLA, especially those under the obligation of KYC or AML compliance, hold enormous amounts of information about their customers, often without them realising this. The scope and value of this information expands far beyond payment card details. A hacker who gains access to a customer database held by any of those companies would almost certainly obtain an unconditional capability to impersonate any customer at any security checkpoint that does not require their physical presence (such as a telephone banking facility or a login form on a web site). For example, they could order a new credit card for themselves through your online banking account, or buy goods on Amazon in your name – but you’ll never see any of them.

This means that we may soon face an even steeper rise in the numbers of identity thefts and related fraud offences, and the Equifax precedent shows that we should take reasonable steps to protect us from those despite all the security assurances given to us by the information custodians. While in most cases we can’t influence online aggregators as to what details to keep and what security methods to employ, we can choose to strengthen the security checkpoints instead, and do this by tightening identity checks, limiting levels of access they grant us, and monitoring them for any suspicious activity.

Employing two-factor authentication is one of the best approaches to tightening the identity checks. If an online service offers it, use it. Even if the attacker manages to use your stolen identity to change your password through the legitimate password recovery procedure, they will be unable to sign in without having access to your second factor.

Limiting access levels is primarily about setting up artificial limits on the actions that you – or the impostor – can conduct with your account. These include any maximum amounts of money that can be spent in one day or month, hours of the day during which the account may be accessed, permitted locations and so on. Many online services offer support for such limitations, and it’s wise to use them. This is mainly a corrective facility that would help minimise your losses should your account get hacked.

Monitoring is about setting up e-mail or text notifications that would inform you about any usual and unusual activity around your account. Having a notification system in place is often the fastest way to identify that your account was hacked. Checking consistency of your account data manually from time to time may help much too.

Finally, it is always a good idea to follow the principle of the least disclosure. If the service doesn’t ask you for some details, or allows you not to answer – don’t give the details away just because. It inevitably turns out that the less a service knows about you, the better it is for you. Again, if you are offered a choice between providing less safe and more safe details, choose wisely. For example, setting up a recurring payment to be collected by direct debit is safer than have it charged monthly to a credit card.

To summarise the above,

1. Most online services suck at security; expect your details to be stolen one day.

2. Minimise the impact of the prospective theft by securing your sign-ins, limiting legitimate access, and setting up access monitoring.

3. Don’t give your personal information away unless required/forced to do so.

Autonomous collision attack on OCSP services

Finally finished my paper on issues in OCSP protocol and got it published on arXiv.org.

The most surprising outcome of the research was the fact that the majority of OCSP services are still using SHA-1 algorithm for calculating their signatures. Taking into account the importance of the role that OCSP responders play in trust environments, this might make them an attractive attack surface.