Standards Corner: Preventing Pervasive Monitoring

On Wednesday night, I watched NBC’s interview of Edward Snowden. The past year has been tumultuous one in the IT security industry. There has been some amazing revelations about the activities of governments around the world; and, we have had several instances of major security bugs in key security libraries: Apple's ‘gotofail’ bug  the OpenSSL Heartbleed bug, not to mention Java’s zero day bug, and others. Snowden’s information showed the IT industry has been underestimating the need for security, and highlighted a general trend of lax use of TLS and poorly implemented security on the Internet. This did not go unnoticed in the standards community and in particular the IETF.
Last November, the IETF (Internet Engineering Task Force) met in Vancouver Canada, where the issue of “Internet Hardening” was discussed in a plenary session. Presentations were given by Bruce Schneier, Brian Carpenter,  and Stephen Farrell describing the problem, the work done so far, and potential IETF activities to address the problem pervasive monitoring. At the end of the presentation, the IETF called for consensus on the issue. If you know engineers, you know that it takes a while for a large group to arrive at a consensus and this group numbered approximately 3000. When asked if the IETF should respond to pervasive surveillance attacks? There was an overwhelming response for ‘Yes'. When it came to 'No', the room echoed in silence. This was just the first of several consensus questions that were each overwhelmingly in favour of response. This is the equivalent of a unanimous opinion for the IETF.

Since the meeting, the IETF has followed through with the recent publication of a new “best practices” document on Pervasive Monitoring (RFC 7258). This document is extremely sensitive in its approach and separates the politics of monitoring from the technical ones.

Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise.

The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community's consensus and establishes the technical nature of PM.

The draft goes on to further qualify what it means by “attack”, clarifying that

The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. It may also have other effects that similarly subvert the intent of a communicator.

The past year has shown that Internet specification authors need to put more emphasis into information security and integrity. The year also showed that specifications are not good enough. The implementations of security and protocol specifications have to be of high quality and superior testing. I’m proud to say Oracle has been a strong proponent of this, having already established its own secure coding practices.

Cross-posted from Oracle Fusion Blog.

Double-blind Identity

Note: Cross-posted from the Oracle Fusion Blog.

On November 13 and 14, the Government of British Columbia, Canada, launched the first in a series of public consultations on identity and digital services. For several years now, BC has been working on a new identity services project that would enable citizens to securely access government services online. For BC, there is clear motivation: reducing identity management and fraud costs in everything from drivers licenses to health insurance. BC's hope is that this can play a role in helping provide better services down the road as well as improving the overall privacy of residents.


For background to the challenges and motivations for BC, check out former BC CIO Dave Nikolejsin's talk on the importance of identity management in 2012 and the principles behind BC's identity project:

Incidentally my favourite quote from this video is: "Government will never be downstream from your Facebook account".

This first public consultation was focused as technical level-set meeting including standards community members from companies like Microsoft and Oracle and other vendors, as well as some members US Govt's NSTIC program, New Zealand Gov't, and British Columbia including its privacy commissioner, Elizabeth Denham. Most importantly, the meeting included several members of the general BC public picked at random from over 15,000 applicants. The day was spent educating and putting participants on a more equal footing on the basics of identity theory as well the challenges and objectives BC has for this program.

As part of this level-set, Collin Wallis, Identity Architect for the New Zealand Gov't, gave a great talk on how NZ and BC are similar in size and have many of the same overall cultural values and privacy concerns. He spoke about NZ's current "RealMe" deployments and their immediate focus on the "authentication". A similar presentation is available here.

The BC Gov't showed an overall architecture based on issuing new driver's licenses and Government Services Cards with near field chips (NFCs) supplied by SecureKey. The architecture depends mainly on OAuth2 authorization and SAML federation techniques that provide a "directed" identifier approach creating an infrastructure that has privacy qualities that could be said to be "double-blind".

You may recall that the term "double-blind" comes from medical research where both the tester and subject are blinded.  In the case of identity, the term implies the authenticator and relying party are blinded in a way that ensures privacy for the subject (the citizen).  The authenticator is not able to observe what personal information is shared or how the identifier is used assuring the citizen of freedom of use without monitoring. The relying party receives a directed identifier for the citizen unique to the relying party's use (see Kim Cameron's Law of Identity #4). What this stuff means is that two relying parties cannot share information directly based on a common identifier (as would happen if one used an omni-directional identifier like a SSN/SIN or Driver's License number). The same individual authenticating to two different parties appears to have separate identities. Hence the architecture could be said to be a double-blind system with strong privacy enabling qualities in its core design.

If successful, NZ and BC citizens may soon use their New Zealand RealMe or BC Government Services Id as a common authenticator to login and/or obtain services, while at the same time, avoid the privacy problems that occur when using a common identity such as offered by social networks, using personal email addresses. Their biggest challenge: BC and NZ need to avoid the fears of other national identity programs such as the US's "REAL ID" or the UK's "National ID" programs by building public confidence in its privacy-centred architecture.

For me personally, the most inspirational aspect of the consultation process was the leadership that Minister Andrew Wilkinson and his CTO, Ian Bailey, showed by adopting an "unconference" format that those of us in the IAM industry have come to know well at our regular meeting Internet Identity Workshop meetings. Following the first day's level-set session, an unconference session was led by Kaliya Hamlin (aka IdentityWoman) as well as Aron and Mike of IdentityNorth on the second day. This format was so successful that the group acknowledged highlights of the day were the members of the general public who chose not only to participate in deep theoretical discussion, but lead 3 of the most insightful sessions of the day!

To be clear, double-blind identity is not necessarily that new--we may have just put a term to it. After-all, there have been many systems with pseudononymous authentication. However, as technologists, we've been too accustomed to centralized architectures where both authentication and personal information in the form of claims come from a common provider (an Identity Provider). In these traditional enterprise architectures privacy has taken a back seat since employees don't often need to expect privacy in regards to performing their jobs. In contrast, these two governments are showing that privacy-enabled identity systems require separation of personal information from authentication services. I wonder what this means for cloud services architectures of the future and whether the current all-knowing social networks can survive the privacy problems they are running into by amassing so much information. It certainly suggests that the social network big data approach where all personal information is in one place is not the right way to go if governments really care about privacy.

Disclosure:  I am a resident of British Columbia. While my employer is a supplier to the government of British Columbia, I am not currently directly involved in this or any other projects with BC. My participation and comments are based as both resident and a member of the identity standards community. The views expressed are my own and do not necessarily reflect those of my employer.