'The widely publicised and very serious "gotofail" bug in iOS7 took me back ...
Early in my career I spent seven years in a very special software development environment. I didn't know it at the time, but this experience set the scene for much of my understanding of information security two decades later. I was in a team with a rigorous software development lifecycle; we attained ISO 9001 certification way back in 1998. My company deployed 30 software engineers in product development, 10 of whom were dedicated to testing. Other programmers elsewhere independently wrote manufacture test systems. We spent a lot of time researching leading edge development methodologies, such as Cleanroom, and formal specification languages like Z.
We wrote our own real time multi-tasking operating system; we even wrote our own C compiler and device drivers! Literally every single bit of the executable code was under our control. "Anal" doesn't ever begin to describe our corporate culture.
Why all the fuss? Because at Telectronics Pacing Systems, over 1986-1990, we wrote the code for the world's first software controlled implantable defibrillator, the Guardian 4210.
The team spent relatively little time actually coding; we were mostly occupied writing and reviewing documents. And then there were the code inspections. We walked through pseudo-code during spec reviews, and source code during unit validation. And before finally shipping the product, we inspected the entire 40,000 lines of source code. That exercise took a five person team working five hours a day for two months.
For critical modules, like the kernel and error correction routines, we walked through the compiled assembly code. We took the time to simulate the step-by-step operation of the machine code using pen and paper, each team member role-playing parts of the microprocessor (Phil would pretend to be the accumulator, Lou the program counter, me the index register). By the end of it all, we had several people who knew the defib's software like the back of their hand.
And we had demonstrably the most reliable real time software ever written. After amassing several thousand implant-years, we measured a bug rate of less than one in 10,000 lines.
The implant software team had a deserved reputation as pedants. Over 25 person years, the average rate of production was one line of debugged C per team member per day. We were painstaking, perfectionist, purist. And argumentative! Some of our debates were excruciating to behold. We fought over definitions of “verification” and “validation”; we disputed algorithms and test tools, languages and coding standards. We were even precious about code layout, shich seems to some pretty silly at the time.
Yet 20 years later, purists are looking good.
Last week saw widespread attention to a bug in Apple's iOS operating system which rendered website security impotent. The problem arose from a single superfluous line of code – an extra goto statement – that nullified checking of SSL connections, leaving users totally vulnerable to fake websites. The Twitterverse nicknamed the flaw #gotofail.
There are all sorts of interesting quality control questions in the #gotofail experience.
- Was the code inspected? Do companies even do code inspections these days?
- The extra goto was said to be a recent change to the source; if that's the case, what regression testing was performed on the change?
- How are test cases selected?
- For something as important as SSL, are there not test rigs with simulated rogue websites stress test security systems before release?
There seems to have been egregious shortcomings at every level : code design, code inspection, and testing.
A lot of attention is being given to the code layout. The spurious goto is indented in such a way that it appears to be part of a branch, but it is not. If curly braces were used religiously, or if an automatic indenting tool was applied, then the bug would have been more obvious (assuming that the code gets inspected). I agree of course that layout and coding standards are important, but there is a much more robust way to make source code clearer.
Beyond the lax testing and quality control, there is also a software-theoretic question in all this that is getting hardly any attention: Why are programmers using ANY goto statements at all?
I was taught at college and later at Telectronics to avoid goto statements at all cost. Yes, on rare occasions a goto statement makes the code more compact, but with care, a program can almost always be structured to be compact in other ways. Don't programmers care anymore about elegance in logic design? Don't they make efforts to set out their code in a rigorous structured manner?
The conventional wisdom is that goto statements make source code harder to understand, harder to test and harder to maintain. Kernighan and Ritchie - UNIX pioneers and authors of the classic C programming textbook - said the goto statement is "infinitely abusable" and it "be used sparingly if at all." Before them, one of programming's giants, Edsger Djikstra, wrote in 1968 that "The go to statement ... is too much an invitation to make a mess of one's program"; see Go To Statement Considered Harmful. The goto creates spaghetti code. The landmark structured programming language PASCAL doesn't even have a goto statement! At Telectronics our coding standard prohibited without exception gotos in all implantable software.
Hard to understand, hard to test and hard to maintain is exactly what we see in the flawed iOS7 code. The critical bug never would have happened if Apple too banned the goto.
Now, I am hardly going to suggest that fanatical coding standards and intellectual rigor are sufficient to make software secure (see also "Security Isn’t Secure). It's unlikely that many commercial developers will be able to cost-justify exhaustive code walkthroughs when millions of lines are involved even in the humble mobile phone. It’s not as if lives depend on commercial software.
Or do they?!
Let’s leave aside that vexed question for now and return to fundamentals.
The #gotofail episode will become a text book example of not just poor attention to detail, but moreover, the importance of disciplined logic, rigor, elegance, and fundamental coding theory.
A still deeper lesson in all this is the fragility of software. Prof Arie van Deursen nicely describes the iOS7 routine as "brittle". I want to suggest that all software is tragically fragile. It takes just one line of silly code to bring security to its knees. The sheer non-linearity of software – the ability for one line of software anywhere in a hundred million lines to have unbounded impact on the rest of the system – is what separates development from conventional engineering practice. Software doesn’t obey the laws of physics. No non-trivial software can ever fully tested, and we have gone too far for the software we live with to be comprehensively proof read. We have yet to build the sorts of software tools and best practice and habits that would merit the title "engineering".
I’d like to close with a philosophical musing that might have appealed to my old mentors at Telectronics. We have reached a sort of pinnacle in post-modernism where the real world has come to pivot precariously on pure text. It is weird and wonderful that engineers are arguing about the layout of source code – as if they are poetry critics.
We have come to depend daily on great obscure texts, drafted not by people we can truthfully call "engineers" but by a largely anarchic community we would be better of calling playwrights.
With a bunch of exciting new members joining up on the eve of the RSA Conference, the FIDO Alliance is going from strength to strength. And they've just published the first public review drafts of their core "universal authentication" protocols.
An update to my Constellation Research report on FIDO is now available. Here's a preview.
The Go-To standards alliance in protocols for modern identity management
The FIDO Alliance – for Fast IDentity Online – is a fresh, fast growing consortium of security vendors and end users working out a new suite of protocols and standards to connect authentication endpoints to services. With an unusual degree of clarity in this field, FIDO envisages simply "doing for authentication what Ethernet did for networking".
Launched in early 2013, the FIDO Alliance has already grown to nearly 100 members, amongst which are heavyweights like Google, Lenovo, MasterCard, Microsoft and PayPal as well as a couple of dozen biometrics vendors, many of the leading Identity and Access Management solutions and service providers and several global players in the smartcard supply chain.
FIDO is different. The typical hackneyed elevator pitch in Identity and Access Management promises to "fix the password crisis" – usually by changing the way business is done. Most IDAM initiatives unwittingly convert clear-cut technology problems into open-ended business transformation problems. In contrast, FIDO's mission is refreshingly clear cut: it seeks to make strong authentication interoperable between devices and servers. When users have activated FIDO-compliant endpoints, reliable fine-grained information about their client environment becomes readily discoverable by any servers, which can then make access control decisions, each according to its own security policy.
With its focus, pragmatism and critical mass, FIDO is justifiably today's go-to authentication standards effort.
In February 2014, the FIDO Alliance announced the release of its first two protocol drafts, and a clutch of new members including powerful players in financial services, the cloud and e-commerce. Constellation notes in particular the addition to the board of security leader RSA and another major payments card, Discover. And FIDO continues to strengthen its vital “Relying Party” (service provider) representation with the appearance of Aetna, Goldman Sachs, Netflix and Salesforce.com.
It's time we fixed the Authentication plumbing
In my view, the best thing about FIDO is that it is not about federated identity but instead it operates one layer down in what we call the digital identity stack. This might seem to run against the IDAM tide, but it's refreshing, and it may help the FIDO Alliance sidestep the quagmire of identity policy mapping and legal complexities. FIDO is not really about the vexed general issue of "identity" at all! Instead, it's about low level authentication protocols; that is, the plumbing.
The FIDO Alliance sets out its mission as follows:
- Change the nature of online authentication by:
- Developing technical specifications that define an open, scalable, interoperable set of mechanisms that reduce the reliance on passwords to authenticate users.
- Operating industry programs to help ensure successful worldwide adoption of the Specifications.
- Submitting mature technical Specification(s) to recognized standards development organization(s) for formal standardization.
The engineering problem underlying Federated Identity is actually pretty simple: if we want to have a choice of high-grade physical, multi-factor "keys" used to access remote services, how do we convey reliable cues to those services about the type of key being used and the individual who's said to be using it? If we can solve that problem, then service providers and Relying Parties can sort out for themselves precisely what they need to know about the users, sufficient to identify and authenticate them.
All of these leaves the 'I' in the acronym "FIDO" a little contradictory. It's such a cute name (alluding of course to the Internet dog) that it's unlikely to change. Instead, I overheard that the acronym might go the way of "KFC" where eventually it is no longer spelled out and just becomes a word in and of itself.
FIDO Alliance Board Members
- CrucialTec (manufactures innovative user input devices for mobiles)
- Discover Card
- Nok Nok Labs (a specialist authentication server software company)
- NXP Semiconductors (a global supplier of card chips, SIMs and Secure Elements)
- Oberthur Technologies (a multinational smartcard and mobility solutions provider)
- Synaptics (fingerprint biometrics)
- Yubico (the developer of the YubiKey PKI enabled 2FA token).
FIDO Alliance Board Sponsor Level Members
- EyeLock Inc.
- Fingerprint Cards AB
- Goldman Sachs
- IDEX ASA
- Next Biometrics Group
- Oesterreichische Staatsdruckerei GmbH
- Ping Identity
- Wave Systems
Stay tuned for the updated Constellation Research report.
That is, information security is not intellectually secure. Almost every precept of orthodox information security is ready for a shake-up. Infosec practices are built on crumbling foundations.
UPDATE: I've been selected to speak on this topic at the 2014 AusCERT Conference - the biggest information security event in Australasia.
The recent tragic experience of data breaches -- at Target, Snapchat, Adobe Systems and RSA to name a very few -- shows that orthodox information security is simply not up to the task of securing serious digital assets. We have to face facts: no amount of today's conventional security is ever going to protect assets worth billions of dollars.
Our approach to infosec is based on old management process standards (which can be traced back to ISO 9000) and a ponderous technology neutrality that overly emphasises people and processes. The things we call "Information Security Management Systems" are actually not systems that any engineer would recognise but instead are flabby sets of documents and audit procedures.
"Continuous security improvement" in reality is continuous document engorgement.
Most ISMSs sit passively on shelves and share drives doing nothing for 12 months, until the next audit, when the papers become the centre of attention (not the actual security). Audit has become a sick joke. ISO 27000 and PCI assessors have the nerve to tell us their work only provides a snapshot, and if a breach occurs between visits, it's not their fault. In their words they admit therefore that audits do not predict performance between audits. While nobody is looking, our credit card numbers are about as secure as Schrodinger's Cat!
The deep problem is that computer systems have become so very complex and so very fragile that they are not manageable by traditional means. Our standard security tools, including Threat & Risk Assessment and hierarchical layered network design, are rooted in conventional engineering. Failure Modes & Criticality Analysis works well in linear systems, where small perturbations have small effects, but IT is utterly unlike this. The smallest most trivial omission in software or in a server configuration can have dire and unlimited consequences. It's like we're playing Jenga.
Update: Barely a month after I wrote this blog, we heard about the "goto fail" bug in the Apple iOS SSL routines, which resulted from one spurious line of code. It might have been more obvious to the programmer and/or any code reviewer had the code been indented differently or if curly braces were used rigorously.
Security needs to be re-thought from the ground up. We need some bigger ideas.
We need less rigid, less formulaic security management structures, to encourage people at the coal face to exercise their judgement and skill. We need straight talking CISOs with deep technical experience in how computers really work, and not 'suits' more focused on the C-suite than the dev teams. We have to stop writing impenetrable hierarchical security policies and SOPs (in the "waterfall" manner we recognised decades ago fails to do much good in software development). And we need to equate security with software quality and reliability, and demand that adequate time and resources be allowed for the detailed work to be done right.
If we can't protect credit card numbers today, we urgently need to do things differently, standing as we are on the brink of the Internet of Things.
Yesterday it was reported by The Verge that anonymous hackers have accessed Snapchat's user database and posted 4.6 million user names and phone numbers. In an apparent effort to soften the blow, two digits of the phone numbers were redacted. So we might assume this is a "white hat" exercise, designed to shame Snapchat into improving their security. Indeed, a few days ago Snapchat themselves said they had been warned of vulnerabilities in their APIs that would allow a mass upload of user records.
The response of many has been, well, so what? Some people have casually likened Snapchat's list to a public White Pages; others have played it down as "just email addresses".
Let's look more closely. The leaked list was not in fact public names and phone numbers; it was user names and phone numbers. User names might often be email addresses but these are typically aliases; people frequently choose email addresses that reveal little or nothing of their real world identity. We should assume there is intent in an obscure email address for the individual to remain secret.
Identity theft has become a highly organised criminal enterprise. Crime gangs patiently acquire multiple data sets over many months, sometimes years, gradually piecing together detailed personal profiles. It's been shown time and time again by privacy researchers (perhaps most notably Latanya Sweeney) that re-identification is enabled by linking diverse data sets. And for this purpose, email addresses and phone numbers are superbly valuable indices for correlating an individual's various records. Your email address is common across most of your social media registrations. And your phone number allows your real name and street address to be looked up from reverse White Pages. So the Snapchat breach could be used to join aliases or email addresses to real names and addresses via the phone numbers. For a social engineering attack on a call centre -- or even to open a new bank account -- an identity thief can go an awful long way with real name, street address, email address and phone number.
I was asked in an interview to compare the theft of stolen phone numbers with social security numbers. I surprised the interviewer when I said phone numbers are probably even more valuable to the highly organised ID thief, for they can be used to index names in public directories, and to link different data sets, in ways that SSNs (or credit card numbers for that matter) cannot.
So let us start to treat all personal inormation -- especially when aggregated in bulk -- more seriously! And let's be more cautious in the way we categorise personal or Personally Identifiable Information (PII).
Importantly, most regulatory definitions of PII already embody the proper degree of caution. Look carefully at the US government definition of Personally Identifiable Information:
- information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other personal or identifying information that is linked or linkable to a specific individual (underline added).
This means that items of data can constitute PII if other data can be combined to identify the person concerned. That is, the fragments are regarded as PII even if it is the whole that does the identifying.
And remember that the middle I in PII stands for Identifiable, and not, as many people presume, Identifying. To meet the definition of PII, data need not uniquely identify a person, it merely needs to be directly or indirectly identifiable with a person. And this is how it should be when we heed the way information technologies enable identification through linkages.
Almost anywhere else in the world, data stores like Snapchat's would automatically fall under data protection and information privacy laws; regulators would take a close look at whether the company had complied with the OECD Privacy Principles, and whether Snapchat's security measures were fit for purpose given the PII concerned. But in the USA, companies and commentators alike still have trouble working out how serious these breaches are. Each new breach is treated in an ad hoc manner, often with people finessing the difference between credit card numbers -- as in the recent Target breach -- and "mere" email addresses like those in the Snapchat and Epsilon episodes.
Surely the time has come to simply give proper regulatory protection to all PII.
An unhappy holiday for Target customers
A week before Christmas, Target in the US revealed it had suffered a massive payment card data breach, with some 40 million customers affected. Details of the breach are still emerging. No well-informed criticism has yet to emerge of Target's security; instead most observers say that Target has very serious security, and therefore this latest attack must have been very sophisticated, or else an inside job. It appears Target was deemed PCI-DSS compliant -- which only goes to prove yet again the futility of the PCI audit regime for deterring organized criminals.
Security analyst Brian Krebs has already seen evidence of a "fire sale" on carding sites. Cardholder records are worth several dollars each, up to $44 according to Krebs for "fresh" accounts. So the Return on Investment for really big attacks like this one on Target (and before that, on Adobe, Heartland Payments Systems, TJMaxx and Sony) can approach one billion dollars.
We have to face the fact that no amount of conventional IT security can protect a digital asset worth a billion dollars. Conventional security can repel amateur attacks and prevent accidental losses, but security policies, audits and firewalls are not up to the job when a determined thief knows what they're looking for.
It's high time that we rendered payment card data immune to criminal reuse. This is not a difficult technological problem; it's been solved before in Card Present transactions around the world, and with a little will power, the payments industry could do it again for Internet payments, nullifying the black market in stolen card data.
A history of strong standardisation
The credit card payments system is a paragon of standardisation. No other industry has such a strong history of driving and adopting uniform technologies, infrastructure and business processes. No matter where you keep a bank account, you can use a globally branded credit card to go shopping in almost every corner of the planet. This seamless interoperability is created by the universal Four Party settlement model, and a long-standing plastic card standard that works the same with ATMs and merchant terminals absolutely everywhere.
So with this determination to facilitate trustworthy and supremely convenient spending in worldwide, it's astonishing that the industry is still yet to standardise Internet payments! We have for the most part settled on the EMV chip card standard for in-store transactions, but online we use a wide range of confusing, piecemeal and largely ineffective security measures. As a result, Card Not Present (CNP) fraud has boomed. I argue that all card payments -- offline and online -- should be properly secured using standardised hardware. In particular, CNP transactions should either use the very same EMV chip and cryptography as do Card Present payments, or it should exploit the capability of mobile handsets and especially Secure Elements.
CNP Fraud trends
The Australian Payments Clearing Association (APCA) releases twice-yearly card fraud statistics, broken down by fraud type: skimming & carding, Card Not Present, stolen cards and so on. Lockstep Consulting monitors the APCA releases and compiles a longitudinal series. The latest Australian card fraud figures are shown below.
APCA like other regulators tend to varnish the rise in CNP fraud, saying it's smaller than the overall rise in e-commerce. There are several ways to interpret this contextualization. The population-wide systemic advantages of e-commerce can indeed be said to outweigh the fraud costs, yet this leaves the underlying vulnerability to payments fraud unaddressed, and ignores the qualitative problems suffered by the individual victims of fraud (as they say, history is written by the winners). It's pretty complacent to play down fraud as being small compared with the systemic benefit of shopping online; it would be like meekly attributing a high road toll to the popularity of motor cars. At some point, we have to do something about safety![And note very carefully that online fraud and online shopping are not in fact two sides of the same coin. Criminals obtain most of their stolen card data from offline retail and processing environments. It's a bit rude to argue CNP fraud is small as a proportion of e-commerce when some people who suffer from stolen card data might have never shopped online in their lives!]
Frankly it's a mystery why the payments industry seems so bamboozled by CNP fraud, because technically it's a very simple problem. And it's one we've already solved elsewhere. For Card Not Present fraud is simply online carding.
Skimming and Carding
In carding, criminals replicate stolen customer data on blank cards; with CNP fraud they replay stolen data on merchant servers.
A magstripe card stores the customer's details as a string of ones and zeroes, and presents them to a POS terminal or ATM in the clear. It's child's play for criminals to scan the bits and copy them to a blank card.
The payments industry responded to skimming and carding with EMV (aka Chip-and-PIN). EMV replaces the magnetic storage with an integrated circuit, but more importantly, it secures the data transmitted from card to terminal. EMV works by first digitally signing those ones and zeros in the chip, and then verifying the signature at the terminal. The signing uses a Private Key unique to the cardholder and held safely inside the chip where it cannot be tampered with by fraudsters. It is not feasible to replicate the digital signature without having access to the inner workings of the chip, and thus EMV cards resist carding.
Online card fraud
Conventional Card Not Present (CNP) transactions are vulnerable because, like the old magstripe cards themselves, they rest on cleartext cardholder data. On its own, a merchant server cannot tell the difference between the original card data and a copy, just as a terminal cannot tell an original magstripe card from a criminal's copy.
Despite the simplicity of the root problem, the past decade has seen a bewildering patchwork of flimsy and expensive online payments fixes. Various One Time Passwords have come and gone, from scratchy cards to electronic key fobs. Temporary SMS codes have been popular for two-step verification of transactions but were recently declared unfit for purpose by the Communications Alliance in Australia, a policy body representing the major mobile carriers.
Meanwhile, extraordinary resources have been squandered on the novel "3D Secure" scheme (MasterCard SecureCode and Verified by Visa). 3D Secure take-up is piecemeal; it's widely derided by merchants and customers alike. It upsets the underlying Four Party settlements architecture, slowing transactions to a crawl and introducing untold legal complexities.
A solution is at hand -- we've done it before
Why doesn't the card payments industry go back to its roots, preserve its global architecture and standards, and tackle the real issue? We could stop most online fraud by using the same chip technologies we deployed to kill off skimming.
It is technically simple to reproduce the familiar card-present user experience in a standard computer or in digital form on a smart phone. It would just take the will of the financial services industry to standardise digital signatures on payment messages sent from a card holder's device or browser to a merchant server.
And there is ample room for innovative payments modalities in online and mobile commerce settings:
All serious payments systems use hardware security. The classic examples include SIM cards, EMV, the Hardware Security Modules mandated by regulators in all ATMs, and the Secure Elements of NFC mobile devices. With well-designed hardware security, we gain a lasting upper hand in the cybercrime arms race.
The Internet and mobile channels will one day overtake the traditional physical payments medium. Indeed, commentators already like to say that the "digital economy" is simply the economy. Therefore, let us stop struggling with stopgap Internet security measures, and let us stop pretending that PCI-DSS audits will stop organised crime stealing card numbers by the million. Instead, we should kill two birds with one stone, and use chip technology to secure both Card Present and CNP transactions, to deliver the same high standards of usability and security in all channels.
Until we render stolen card data useless to criminals, the Return on Investment will remain high for even very sophisticated attacks (or simply bribing insiders), and spectacular data breaches like Target's will continue.
I've written a new Constellation Research "Quark" Report on the FIDO Alliance ("Fast Identity Online"), a fresh, fast growing consortium working out protocols and standards to connect authentication endpoints to services.
With a degree of clarity that is uncommon in Identity and Access Management (IDAM), FIDO envisages simply "doing for authentication what Ethernet did for networking".
Not quite one year old, 2013, the FIDO Alliance has already grown to nearly 70 members, amongst which are heavyweights like Google, Lenovo, MasterCard, Microsoft and PayPal as well as a dozen biometrics vendors and several global players in the smartcard supply chain.
STOP PRESS! Discover Card joined a few days ago at board level.
FIDO is different. The typical hackneyed IDAM elevator pitch in promises to "fix the password crisis" but usually with unintended impacts on how business is done. Most IDAM initiatives unwittingly convert clear-cut technology problems into open-ended business transformation problems.
In welcome contrast, FIDO’s mission is clear cut: it seeks to make strong authentication interoperable between devices and servers. When users have activated FIDO-compliant endpoints, reliable fine-grained information about the state of authentication becomes readily discoverable by any server, which can then make access control decisions according to its own security policy.
FIDO is not about federation; it's not even about "identity"!
With its focus, pragmatism and critical mass, FIDO is justifiably today’s go-to authentication industry standards effort.
For more detail, please have a look at The FIDO Alliance at the Constellation Research website.
The cover of Newsweek magazine on 27 July 1970 featured an innocent couple being menaced by cameras and microphones and new technologies like computer punch cards and paper tape. The headline hollered “IS PRIVACY DEAD?”.
The same question has been posed every few years ever since.
In 1999, Sun Microsystems boss Scott McNally urged us to “get over” the idea we have “zero privacy”; in 2008, Ed Giorgio from the Office of the US Director of National Intelligence chillingly asserted that “privacy and security are a zero-sum game”; Facebook’s Mark Zuckerberg proclaimed in 2010 that privacy was no longer a “social norm”. And now the scandal around secret surveillance programs like PRISM and the Five Eyes’ related activities looks like another fatal blow to privacy. But the fact that cynics, security zealots and information magnates have been asking the same rhetorical question for over 40 years suggests that the answer is No!
PRISM, as revealed by whistle blower Ed Snowden, is a Top Secret electronic surveillance program of the US National Security Agency (NSA) to monitor communications traversing most of the big Internet properties including, allegedly, Apple, Facebook, Google, Microsoft, Skype, Yahoo and YouTube. Relatedly, intelligence agencies have evidently also been obtaining comprehensive call records from major telephone companies, eavesdropping on international optic fibre cables, and breaking into the cryptography many take for granted online.
In response, forces lined up at tweet speed on both sides of the stereotypical security-privacy divide. The “hawks” say privacy is a luxury in these times of terror, if you've done nothing wrong you have nothing to fear from surveillance, and in any case, much of the citizenry evidently abrogates privacy in the way they take to social networking. On the other side, libertarians claim this indiscriminate surveillance is the stuff of the Stasi, and by destroying civil liberties, we let the terrorists win.
Governments of course are caught in the middle. President Obama defended PRISM on the basis that we cannot have 100% security and 100% privacy. Yet frankly that’s an almost trivial proposition. It's motherhood. And it doesn’t help to inform any measured response to the law enforcement challenge, for we don’t have any tools that would let us design a computer system to an agreed specification in the form of, say “98% Security + 93% Privacy”. It’s silly to us the language of “balance” when we cannot measure the competing interests objectively.
Politicians say we need a community debate over privacy and national security, and they’re right (if not fully conscientious in framing the debate themselves). Are we ready to engage with these issues in earnest? Will libertarians and hawks venture out of their respective corners in good faith, to explore this difficult space?
I suggest one of the difficulties is that all sides tend to confuse privacy for secrecy. They’re not the same thing.
Privacy is a state of affairs where those who have Personal Information (PII) about us are constrained in how they use it. In daily life, we have few absolute secrets, but plenty of personal details. Not many people wish to live their lives underground; on the contrary we actually want to be well known by others, so long as they respect what they know about us. Secrecy is a sufficient but not necessary condition for privacy. Robust privacy regulations mandate strict limits on what PII is collected, how it is used and re-used, and how it is shared.
Therefore I am a privacy optimist. Yes, obviously too much PII has broken the banks in cyberspace, yet it is not necessarily the case that any “genie” is “out of the bottle”.
If PII falls into someone’s hands, privacy and data protection legislation around the world provides strong protection against re-use. For instance, in Australia Google was found to have breached the Privacy Act when its StreetView cars recorded unencrypted Wi-Fi transmissions; the company cooperated in deleting the data concerned. In Europe, Facebook’s generation of tag suggestions without consent by biometric processes was ruled unlawful; regulators there forced Facebook to cease facial recognition and delete all old templates.
We might have a better national security debate if we more carefully distinguished privacy and secrecy.
I see no reason why Big Data should not be a legitimate tool for law enforcement. I have myself seen powerful analytical tools used soon after a terrorist attack to search out patterns in call records in the vicinity to reveal suspects. Until now, there has not been the technological capacity to use these tools pro-actively. But with sufficient smarts, raw data and computing power, it is surely a reasonable proposition that – with proper and transparent safeguards in place – population-wide communications metadata can be screened to reveal organised crimes in the making.
A more sophisticated and transparent government position might ask the public to give up a little secrecy in the interests of national security. The debate should not be polarised around the falsehood that security and privacy are at odds. Instead we should be debating and negotiating appropriate controls around selected metadata to enable effective intelligence gathering while precluding unexpected re-use. If (and only if) credible and verifiable safeguards can be maintained to contain the use and re-use of personal communications data, then so can our privacy.
For me the awful thing about PRISM is not that metadata is being mined; it’s that we weren’t told about it. Good governments should bring the citizenry into their confidence.
Are we prepared to honestly debate some awkward questions?
- Has the world really changed in the past 10 years such that surveillance is more necessary now? Should the traditional balances of societal security and individual liberties enshrined in our traditional legal structures be reviewed for a modern world?
- Has the Internet really changed the risk landscape, or is it just another communications mechanism. Is the Internet properly accommodated by centuries old constitutions?
- How can we have confidence in government authorities to contain their use of communications metadata? Is it possible for trustworthy new safeguards to be designed?
Many years ago, cryptographers adopted a policy of transparency. They have forsaken secret encryption algorithms, so that the maths behind these mission critical mechanisms is exposed to peer review and ongoing scrutiny. Secret algorithms are fragile in the long term because it’s only a matter of time before someone exposes them and weakens their effectiveness. Security professionals have a saying: “There is no security in obscurity”.
For precisely the same reason, we must not have secret government monitoring programs either. If the case is made that surveillance is a necessary evil, then it would actually be in everyone’s interests for governments to run their programs out in the open.
As we head towards 2014, de-identification of personal data sets is going to be a hot issue. I saw several things at last week's Constellation Connected Enterprise conference (CCE) that will make sure of this!
First, recall that in Australia a new definition of Personal Information (PI or "PII") means that anonymous data that can potentially be re-identified in future may have to be classified as PII today. I recently discussed how security and risk practitioners can deal with the uncertainty in re-identifiability.
And there's a barrage of new tracking, profiling and interior geo-location technologies (like Apple's iBeacon) which typically come with a promise of anonymity. See for example Tesco's announcement of face scanning for targeting adverts at their UK petrol stations.
The promise of anonymity is crucial, but it is increasingly hard to keep. Big Data techniques that join de-identified information to other data sets are able to ind correlations and reverse the anonymisation process. The science of re-identification started with the work of Dr Latanya Sweeny who famously identified a former governor and his medical records using zip codes and electoral roll data; more recently we've seen DNA "hackers" who can unmask anonymous DNA donors by joining genomic databases to public family tree information.
At CCE we saw many exciting Big Data developments, which I'll explore in more detail in coming weeks. Business Intelligence as-a-service is expanding rapidly, and is being flipped my innovative vendors to align (whether consciously or not) with customer centric Vendor Relationship Management models of doing business. And there are amazing new tools for enriching unstructured data, like newly launched Paxata's Adaptive Data Preparation Platform. More to come.
With the ability to re-identify data comes Big Responsibilities. I believe that to help businesses meet their privacy promises, we're going to need new tools to measure de-identification and hence gauge the risk of re-identification. It seems that some new generation data analytics products will allow us to run what-if scenarios to help understand the risks.
Just before CCE I also came across some excellent awareness raising materials from Voltage Security in Cupertino. Voltage CTO Terence Spies shared with me his "Deidentification Taxonomy" reproduced here with his kind permission. Voltage are leaders in Format Preserving Encryption and Tokenization -- typically used to hide credit card numbers from thieves in payment systems -- and they're showing how the tools may be used more broadly for de-identifying databases. I like the way Terence has characterised the reversibility (or not) of de-identification approaches, and further broken out various tokenization technologies.
Reference: Voltage Security. Reproduced with permission.
These are the foundations of the important new science of de-identification. Privacy engineers need to work hard at re-identification, so that consumers do not lose faith in the important promises made that so much data collected from their daily movements through cyber space are indeed anonymous.
This is a copy of an op-ed I wrote in IT News on 20 September.
It’s been suggested that with Apple’s introduction of biometric technology, the “i” in iPhone now stands for “identity”. Maybe “i” is for “ironic” because there is another long-awaited feature that would have had much more impact on the device’s identity credentials.
The fingerprint scanner has appeared in the new iPhone 5s, as predicted, and ahead of Near Field Communications capability. In my view, NFC is much more important for identity. NFC is usually thought of as a smartcard emulator, allowing mobile devices to appear to merchant terminals as payments instruments, but the technology has another lesser known mode: reader emulation.
NFC devices can be programmed to interface with any contactless card: smart driver licenses, health cards, employee ID and so on. The power to identify and authenticate to business and enterprise apps using real world credentials would be huge for identity management, but it seems we have to wait.
Meanwhile, what does the world’s instantly most famous fingerprint reader mean for privacy and security? As is the case with all things biometric, the answers are not immediately apparent.
Biometric authentication might appear to go with mobiles like strawberries and cream. Smartphones are an increasingly central fixture in daily life and yet something like 40% of users fail to protect this precious asset with a PIN. So automatic secure logon is an attractive idea.
There are plenty of options for biometrics in smartphones, thanks to the built in camera and other sensors. Android devices have had face unlock for a long time now, and iris authentication is also available. Start-up EyeVerify scans the vein pattern in the whites of the eye; gait recognition has been mooted; and voice recognition would seem an obvious alternative.
With its US$365M acquisition of Authentec in 2012, Apple made a conspicuous commitment to a biometric technology that was always going to involve significant new hardware in the handset. The iPhone 5s incorporates a capacitive fingerprint detector in a subtly modified Home button. Ostensibly the button operates as it always has, but it automatically scans the user’s finger in the time it takes to press and release. Self-enrolment is said to be quite painstaking, with the pad of the finger being comprehensively scanned and memorised. This allows the relatively small scanner to still do its job no matter what fraction of the fingertip happens to be presented. Up to five alternate fingers can be enrolled, which allows for a fall-back if the regular digit is damaged, as well as additional users like family members to be registered.
This much we know. What’s less clear is the security performance of the iPhone 5s.
Remember that all biometrics commit two types of error: False Rejects where an enrolled user is mistakenly blocked, and False Accepts where someone else is confused for the legitimate user. Both type of error are inevitable, because biometrics must be designed to tolerate a little variability. Each time a body part is presented, it will look a little different; fingers get dirty or scarred or old; sensors get scratched; angle and pressure vary. But in allowing for change, the biometric is liable to occasionally think similar people are the same.
The propensity to make either False Positive or False Negative errors must be traded off in every biometric application, to deliver reasonable security and convenience. Data centre biometrics for instance are skewed towards security and as a result can be quite tricky and time consuming to use. With consumer electronics, the biometric trade-off goes very much the other way. Consumers only ever directly experience one type of error – False Rejects – and they can be very frustrating. Most users don’t in fact ever lose their phone, so False Accepts are irrelevant.
Thus the iPhone 5s finger reader will be heavily biased towards convenience, but at what cost? Frustratingly, it is almost impossible to tell. Independent biometrics researchers like Jim Wayman have long warned that lab testing is a very poor predictor of biometric performance in the field. The FBI advises that field performance is always significantly worse than reported by vendors, especially in the face of determined attack.
All we have to go on is anecdotes. We’re assured that the Authentec technology has “liveness detection” to protect against fake fingers but it’s a hollow promise. There are no performance standards or test protocols for verifying the claim of liveness detection.
The other critical promise made by Apple is that the fingerprint templates stored securely with the handset will never made accessible to third party applications nor the cloud. This is a significant privacy measure, and is to be applauded. It’s vital that Apple stick to this policy.
But here’s the rub for identity: if the biometric matching is confined to the phone, then it’s nothing more than a high tech replacement for the PIN, with indeterminate effectiveness. Certainly smartphones have great potential for identity management, but the advantages are to be gained from digital wallets and NFC, not from biometrics.
Some have quipped that the “S” in iPhone 5S stands for “security” but to me it’s more like “speculation”.
IBM Zurich researcher Diego Ortiz-Yepes recently revealed a new Two Factor Authentication technique in which the bona fides of a user of a mobile app are demonstrated via a contactless smartcard waved over the mobile device. The technique leverages NFC -- but as a communications medium, not as a payments protocol. The method appears to be compatible with a variety of smartcards, capable of carrying a key specific to the user and performing some simple cryptographic operations.
This is actually really big.
I hope the significance is not lost in the relentless noise of new security gadget announcements, because it's the most important new approach to authentication we've seen for a long long time. The method can easily be adopted by the NFC and smartcard ecosystems with no hardware changes. And with mobile adoption at a tipping point, we need true advances in security like this to be adopted as widely and as quickly as possible. If we ignore it, future generations will look back on the dawn of m-business as another opportunity lost.
A golden opportunity to address an urgent problem
Mobile represents the first greenfield computing platform in thirty years. Not since the PC have we seen a whole new hardware/software/services/solutions environment emerge.
It's universally acknowledged that general purpose PCs and Internet Protocol for that matter were never engineered with security much in mind. The PC and the Internet were independently architected years before the advent of e-commerce, and without any real sense of the types of mission critical applications they would come to support.
I remember visiting Silicon Valley in 1998 when I was with KPMG's pioneering PKI team, working on, amongst other things, the American Bar Association e-signature guidelines. We were meeting with visionaries, asking Will anyone ever actually shop "online"?. Nobody really knew! But at startling speed, commodity PCs and the Internet were indeed being joined up for shopping and so much more: payments, and e-health, and the most sensitive corporate communications. Yet no mainstream computer manufacturer or standards body ever re-visited their designs with these uses in mind.
And so today, a decade and a half on (or a century in "Internet years") we have security boffins earnestly pronouncing "well you know, there is no identity layer in the Internet". No kidding! Identity theft and fraud are rife, with as yet no industry-wide coordinated response. Phishing and pharming continue at remarkable rates. "Advanced Persistent Threats" (APTs) have been industrialised, through malware exploit kits like Blackhole which even come with licensing deals and help desk support that rivals that of legitimate software companies. Even one of the world's very best security companies, RSA, fell victim to an APT attack that started with an trusted employee opening a piece of spam.
But in the nick of time, along comes the mobile platform, with all the right attributes to make safe the next generation of digital transactions. Most mobile devices come with built-in "Secure Elements": certifiably secure, tamper-resistant chips in which critical cryptographic operations take place. Historically the SIM card (Subscriber Identification Module) has been the main Secure Element; "NFC" technology (Near Field Communications) introduces a new generation of Secure Elements, with vastly more computing power and flexibility than SIMs, including the ability to run mission critical apps entirely within the safe chip.
The Secure Element should be a godsend. It is supported in the NFC architecture by Trusted Service Managers (TSMs) which securely transfer critical data and apps from verified participants (like banks) into the consumers' devices. Technically, the TSMs are a lot like the cell phone personalisation infrastructure that seamlessly governs SIM cards worldwide, and secures mobile billing and roaming. Admittedly, TSMs have been a bit hard to engage with; to date, they're monopolised by telcos that control access to the Secure Elements and have sought to lease memory at exorbitant rates. But if we collectively have the appetite at this time to solve cyberspace security then mobile devices and the NFC architecture in particular provide a once-in-a-generation opportunity. We could properly secure the platform of choice for the foreseeable future.
The IBM Two Factor Authentication demo
Before explaining what IBM's Ortiz-Yepes has done, let's briefly review NFC, because it is often misconstrued. NFC technology has a strong brand that identifies it with contactless payments, but there is much more to it.
"Near Field Communications" is a short range radio frequency comms protocol, suited to automatic device-to-device interfaces. To the layperson, NFC is much the same as Bluetooth or Wi-Fi, the main difference being the intended operating range: 10s of metres for Wi-Fi; metres for Bluetooth; and mere centimetres for NFC.
NFC has come to be most often used for carrying wireless payments instructions from a mobile phone to a merchant terminal. It's the technology underneath MasterCard PayPass and Visa payWave, in which your phone is loaded with an app and account information to make it behave like a contactless credit card.
The NFC system has a few modes of operation. The one used for PayPass and payWave is "Card Emulation Mode" which is pretty self explanatory. Here an NFC phone appears to a merchant terminal as though it (the phone) is a contactless payment card. As such, the terminal and phone exchange payments messages exactly as if a card was involved; cardholder details and payment amount are confirmed and send on to the merchant's bank for processing. NFC payments has turned out to be a contentious business, with disconcertingly few success stories, and a great deal of push-back from analysts. The jury is still out on whether NFC payments will ever be sustainable.
However, NFC technology has other tricks. Another mode is "Reader Emulation Mode" in which the mobile phone reads from (and writes to) a contactless smartcard. As an identity analyst, I find this by far the more interesting option, and it's the one that IBM researchers have exploited in their new 2FA method.
According to what's been reported at CNET and other news outlets, a mobile and a smartcard are used in what we call a "challenge-response" combo. The basic authentication problem is to get the user to prove who she is, to the app's satisfaction. In the demo, the user is invited to authenticate herself to an app using her smartcard. Under the covers, a random challenge number is generated at a server, passed over the Internet or phone network to the mobile device which in turn sends it over NFC to the smartcard. The card then 'transforms' the challenge code into a response using a key specific to the user, and returns it to the app, which passes it back to the server. The server then verifies that the response corresponds to the challenge, and if it does, we know that the right card and therefore the right user is present.
NOTE:Technically there are a number of ways the challenge can be transformed into a response code capable of being linked back to the original number. The most elegant way is to use asymmetric cryptography, aka digital signatures. The card would use a unique private key to encrypt the challenge into a response; the server subsequently uses a public key to try and decrypt the response. If the decrypted response matches the challenge, then we know the public key matches the private key. A PKI verifies that the expected user controls the given public-private key pair, thus authenticating that user to the card and the app.
Further, I'd suggest the challenge-response can be effected without a server, if a public key certificate binding the user to the key pair is made available to the app. The challenge could be created in the app, sent over NFC to the card, signed by the private key in the card, and returned by NFC to be verified in the app. Local processing in this way is faster and more private involving a central server.
Significance of the demo
The IBM demonstration is a terrific use of the native cryptographic powers now commonplace in smartcards and mobile apps. No hardware modifications are needed to deploy the 2FA solution; all that's required is that a private key specific to the user be loaded into their smartcard at the time the card is personalised. Almost all advanced payments, entitlements and government services cards today can be provisioned in such a manner. So we can envisage a wonderful range of authorization scenarios where existing smartcards would be used by their holders for strong access control. For example:
- Employee ID card (including US Govt PIV-I) presented to an enterprise mobile app, to access and control corporate applications, authorize purchase orders, sign company documents etc
- Government ID card presented to a services app, for G2C functions
- Patient ID or health insurance card presented to a health management app, for patient access to personal health records, prescriptions, claims etc.
- Health Provider ID card presented to a professional app, to launch e-health functions like dispensing, orders, admissions, insurance payments etc,
- Credit Card presented to a payment app, for online shopping.
I can't believe the security industry won't now turn to use smartcards and similar chipped devices for authenticating users to mobile devices for a whole range of applications. We now have a golden opportunity to build identity and authorization security into the mobile platform in its formative stages, avoiding the awful misadventures that continue to plague PCs. Let's not blow it!