privacy – Code Technology

Where you from?

Periodically I have a disconnect with a client or a consulting partner. You know, one of those moments when you realize you are on different pages than you thought you were when the conversation started.

I’ve realized that there are typically two types of people working in Identity and Access Management. The first group comes from a security background, while the second has access administration or maybe more general IT on their resume. I’m a graduate from the second school.

This really dawned on me about five years ago. I was talking to a consultant, who was relatively new to IT, about identity management and how my job was to give the right people access to the right resource, yadda, yadda, my normal spiel. He was listening but had a furrowed brow and I realized he was struggling with the ‘allow access’ part of the conversation.

I quickly learned that he was an ex-military police officer with experience in electronic security systems. He was much, much more interested in blocking access and ensuring maximum security. The idea that we could (and should) make access easier was hard for him to understand.

I have learned that there are some in this business that come from a position of wanting to over-secure everything. If that’s who you are working with, it is best to consider that viewpoint because they won’t be able to move forward with an IAM solution until their primary security needs are met.

But there are also those of us that want a really good user experience even if it means managing some additional security risk. We’ll always look for a design that allows access — while still being compliant with security and privacy — but is more aligned with client business needs.

Where you from?

[polldaddy poll=8306656]

Should government sites use social media login?

I’ve been thinking about how the public sector model for identity has changed in recent years from one where the government body controls the credential AND acts as an identity provider, to one where the credential management is delegated to a service provider. Social media login and, at the premium end, SecureKey’s briidge.net are examples of this model.

Social media credentials from Twitter, Facebook and Google are used everyday by millions of Canadians. Why not leverage these existing accounts to access government services?

The problem I have when talking to clients about these solutions is the assumption that any credential service provider (CSP) will do. That is, a public organization can (and should) readily accept any common credential, add a layer of identity proofing, create a link back to the credential (for future access) and start counting the costs saved. After all, it is all about citizen choice isn’t it?

This isn’t as simple issue. There are some fundamental problems with using low-end credentials, such as social media logins, that need to be carefully considered when delegating authentication to a third party:

Operational Disruptions — There was a great post from the Basecamp blog a few years ago (since deleted) that described how difficult it was to maintain the link between a credential provider and the site. This post talked specifically to OpenID and how changes to the credential may not be properly shared with relying parties, resulting in support calls and manual fixes. Users would also forget which OpenID account they used, and Basecamp had no automated way to reconnect them. In the end, disruptions were common for OpenID users, support costs spiked, and Basecamp discontinued its use.
Longevity — Which social media credential providers are going to be around for the long run? What consolidations of login services or outright mergers are coming? How might the protocols for social media login change? For a public-sector service wanting to provide stable, long-term services, picking the right credential service providers is extremely difficult.
Wrong Message — Social media companies (Google, Facebook, even LinkedIn) often misbehave when it comes to privacy. They routinely run afoul of privacy commissioners and even irritate their user bases when ever-invasive features are introduced. Given the poor privacy records, should a public-sector website be encouraging the use of social media login to access government services? What are the downstream risks?
Convenience — Social media login can certainly save time when it comes to authentication. I use my Twitter account to access Level 1 (low value) services frequently. I’ll admit it is convenient and I like that blogs, news websites and the like offer this option. But convenience is far less important to me when accessing my personal information on a government website. First of all, security and privacy protection matter a lot more. Further, I don’t access these sites all that often so if I have to login (or request an automated password reset) it isn’t that big of a deal to me. What would be more useful would be a common credential for all of a particular government’s services, so that I can experience single sign-on.

So what are the benefits of leveraging a social media credential for government websites? Well, for those more trusting than me, convenience and the benefit of having fewer passwords to remember is a definite plus. And cost savings can be significant for large websites, although keep in mind that a full IAM stack is still required — the public sector website will still need to provide their own login service as not all citizens will trust an alternate credential.

Ultimately, social media login for services won’t meet government privacy and security requirements for access to sensitive information. Existing in-house systems and credential solutions (like SecureKey) that specifically address the trust issue will likely prevail.

Mike

e-Voting and Identity

In my own city, Edmonton, they have been talking up e-voting for a while now. There was an announcement yesterday that a pilot project is being conducted to validate the process of running an online election. (More information can be found here and here.)

First of all, I think that this is exactly the type of pilot project that governments must run to be progressive and forward-thinking. These types of initiatives are high value, not just to validate a solution for this defined need, but for the organization’s other online initiatives. And the proposed e-voting identification process is an interesting one…

To be frank, I don’t have e-voting very high on my personal list of municipal problems to be solved, BUT I do have a keen interest in how people are identified online.

The City’s new project has an identity proofing process for this pilot project. It includes a unique method of collecting identity proofing documents that I haven’t seen before: citizens scan (or take a picture of) their real-world identification, then upload it to the City’s website. Allowed documents include drivers license, passport, Canadian military cards, etc. (see sidebar).

The image of the identification document is then reviewed manually by employees in the elections department and presumably compared to lists of eligible voters. Only when the document matches up with a previously registered voter will a credential be issued to the citizen for voting purposes.

This approach is convenient to citizens, or at least those that are savvy enough to scan a document and upload it to a website (which is probably a pretty high percentage of those that will consider online voting).

But whenever I see ‘convenience’ cited as a reason to do something online, I can’t help but look for the security and privacy compromises required to make that thing convenient. On first review (I haven’t done a deep dive s feel free to correct me!) here are a few things that might be compromised by such a process:

How does the process ensure that the citizen is in control of the document at the time e-voting registration takes place? For example, the passports for a household might be stored in a filing cabinet. Let’s say one member of the household is politically active and the rest don’t vote at all. How difficult would it be for the one family member to round up the passports and create multiple e-voting credentials?
There may be a privacy issue here. Scanned identification documents contain a payload of sensitive information. My passport has my legal name and birthdate — two attributes that are useful for the voter vetting process. But it also contains my passport number, my place of birth and my citizenship. None of these attributes are needed by this process, and should not be collected and stored as part of the process. (Update: The City’s 311 service has informed me that the data will be stored in Canada and destroyed no later than December 31, 2012. Also, only authorized personnel can view the data and they are subject to confidentiality agreements.)
Finally, how can one be sure that the scanned identity document has not been digitally tampered with? Paper and plastic documents have physical safeguards to increase reliability. For example, the Alberta drivers license has a hologram on it and ‘declined width text wave’ feature (and these are just two of a dozen security features). How do these features translate to the scanned image? Assuming many of these features do not translate well, how well does the scan of the document actually prove the citizen’s identity? As a comparison, would such a scan, subsequently printed, be acceptable as ID at the polling station?

It will be interesting to see how these and other challenges of e-voting will be overcome in the coming months.

Mike

SecureKey — The Interview

Andre Boysen is an Executive Vice President at SecureKey Technologies Inc., the Toronto-based technology company that is working with Canadian governments and business on next-generation identity management solutions. With the backing of Intel, Telus and Visa (among others) SecureKey looks to make a big splash in the world of secure payments and online identity.

SecureKey Concierge is a credential broker solution that allows government web sites to use banking credentials. With SecureKey Concierge, government sites can take advantage of existing banking credentials in a secure and privacy-protected way.

I had the chance to interview Andre last week.

Code Technology: Tell us a bit about what SecureKey Technologies is all about.

Andre Boysen: SecureKey is in the business of making online authentication easier, that’s basically what we are trying to do. We got started helping banks to solve ‘card not present problems’ — this type of fraud went to zero with the introduction of chip cards and PINs. But it still is an problem on the Internet – anyone finds your credit card number and billing address basically they can start ordering stuff. It’s hard for the banks to figure out who’s real and who’s not.

We noticed that banks were moving to contact-less chips (based on near-field communications or NFC) in order to speed up things. With NFC for quick purchases like papers and coffee, the customer just has to tap the card, no need to enter a PIN.

We saw the opportunity to use this technology to do payments on the Internet. We have built an NFC reader and the concept is that you can have this reader on your computer, at home, and when you want to buy something on the Internet, instead of typing in a card number you just tap your card on the reader and pay that way.

One of our strategies is to get our technology embedded into all consumer electronics. Intel is a significant investor in SecureKey and all the Ultrabooks coming out actually have our NFC reader built in. And we are working to get it embedded in cell phones.

Code: So how does this technology lend itself to the direction you have taken with SecureKey Concierge?

Andre: So, yes, that’s a good question… Part of this is that we noticed that we are all drowning in user IDs and passwords. And the problem for governments is that they know who I am on paper but they don’t know me in person, and when I show up on the Internet they have a hard time knowing it’s me. The solution in the past is for the government to roll out their own credential — the current incarnation is called Access Key. But (for higher-value transactions) that includes installing software on my computer and with all the support costs related to this, the government realized that serving me online is much more expensive that serving me in person…

The federal government’s idea was to delegate authentication. An RFP was issued looking for proposals with 10,000,000 subscribers and at least three credential service providers. SecureKey, partnering with three of the largest Canadian banks, was the only respondent.

Code: Why are the banks interested in this?

Andre: Their primary motivator is that they want to see identity move online. Banks want customer identities, today largely based on the provincial drivers license, to be verifiable. With SecureKey’s model four key players will participate: federal government, provincial government, banks and telcos. These four players have a critical role in the consumer’s life. The federal government can set standards and leverage its buying power in a way that individual provinces can’t. The provinces are the source of identity — birth certificates and the licenses we carry around in our wallets. But the problem is that we don’t deal with the province very often; it’s rare that we have to talk with them and this makes it hard to authenticate online.

This is where the banks come in. They have a very tight relationship with 98% of Canadians — they see their customers often and know them well. By participating in SecureKey, the banks will get better digital identities, which will help them when accounts are opened.

To take this further, BC is launching new services card and drivers license with an NFC chip inside. This is compatible with SecureKey technology and will make it easier to conduct secure transactions related to provincial programs.

What the telcos bring to this is something that Canadians always have in their pockets — their phones. We are working to get phones and carrier networks working with the system as well.

Code: What is the typical use case SKC is looking to solve?

Andre: Any Canadian who wants quick and convenient access to any federal government service can use their bank account to gain that access.

Code: Can you confirm for us the high-level architecture? Is it primarily an identity broker service that sits between the IdP and relying party?

Andre: No, it is better described as a ‘credential’ broker service because there is no identity information passed. The government never gets the unique MBUN (meaningless but unique number), only a service-specific number. There is no information about the user passed to the government other than they are an authenticated bank user. The government does its own enrolment and identity verification.

Code: Is SecureKey Concierge based on SAML?

Andre: The service is based on SAML 2.o and has support for older versions of SAML and Shibboleth. OAuth and WS-Trust are planned.

Code: How can the service support an investigation?

Andre: It is important to point out that SKC has a privacy-enhanced design — triple blind. No one participant has a complete picture of the transaction.

Each bank produces an anonymous MBUN for each customer. The banks will pass the MBUN to SKC during authentication. Our service will log any transactions completed in the session against the MBUN. To preserve anonymity between services SKC will further anonymize the MBUN for each relying party service and SKC will pass a unique number called the Persistent Anonymous Identifier to each RP.

Event tracking is supported. So let’s say CRA comes to us and says we have an event here and we need to do an investigation. Keep in mind that the ‘handle’ we give to the RP is the Persistent Anonymous Identifier (PAI). CRA can provide us with this number and we can provide the event logs that relate to that PAI. If this isn’t sufficient, we can use the MBUN to go to the banks and get the details of the authentication event from them. Of course, it depends on how serious the issue is — if it is a judicial enquiry there will be more disclosure, but for other investigations we will keep the ‘privacy veil’ on.

For a compromised account, the bank is going to shut it down and the government won’t see that account again. It is worth noting that banks have pretty sophisticated systems for detecting problems, so breaches are pretty rare events.

Code: Can you share with us the attributes that are passed between the bank and the government site? From my recent use of the service, I couldn’t tell if the bank asserted my name information.

Andre: Only PAI is passed. Name info is not passed. Note that each service (relying party) does own enrolment and may collect name.

We are all about consumer convenience, choice and privacy control. This service is very user-centric. Users are presented options to approve any information via on-screen prompts. To facilitate this, SecureKey Concierge will have a set of templates to allow RPs to collect pre-determined ‘bundles’ of information. The RP will use these templates to collect all the info consistently from a provincial card or bank record.

This broker concept becomes even more important as we move into sharing identity attributes. We want to make sure we continue to support minimal disclosure.

Code: I’ve worked on citizen identity for a while now, and there is always the challenge of keeping up with their preferences and ‘life-changes’. How does the SKC service manage changes to the citizen’s banking credentials? Let’s say I decide to switch banks, but want to keep my access to the Service Canada site in place. Is this possible?

Andre: Yes, a bank account change can be made via a the ‘Switch My Sign-In Partner’. The process requires that you have control of both bank accounts in order to make the switch.

Code: The SecureKey Concierge two-factor solution looks to be a bit of a game changer for high-value and/or high-risk transactions. Where do you see this technology being adopted in the online government-to-citizen space?

Andre: Enterprise authentication is something we can do. SecureKey is trying to make it easier for employees using their access badges. We see healthcare and government and finance are three verticals we are targeting, all with needs for strong authentication.

Code: How are things going? Has interest in SecureKey Concierge started to pick up? Have you seen interest in the service outside of the federal government, BC and Alberta?

Andre: We launched with the government of Canada in April, and have 15 agencies/departments online today. Two bigger departments, HRDC and CRA, are set to launch this fall. We expect that by the end of 2012 we’ll have the bulk of Canadian departments online with SecureKey Concierge.

As for other interest — there is nothing we can share just yet! But ‘wrapping up Canada’ (all remaining provinces) is the current goal. We also want more credential service providers including partners from outside of the banking sector.

Code: Thanks for your time today Andre.

Andre: You’re welcome!

Privacy at risk in Canada?

An important issue is being raised by our federal Privacy Commissioner around changes to legislation to combat online fraud and other crimes. These changes look to be more than cursory — they would potentially create a legal environment where law enforcement can implement excessive surveillance on Canadians.

To quote Jennifer Stoddart’s letter to Vic Toews, the Minister of Public Safety:

By expanding the legal tools of the state to conduct surveillance and access private information, and by reducing the depth of judicial scrutiny, the previous bills would have allowed government to subject more individuals to surveillance and scrutiny. In brief, these bills went far beyond simply maintaining investigative capacity or modernizing search powers. Rather, they added significant new capabilities for investigators to track, and search and seize digital information about individuals.

This is an important issue, one worth paying attention to over the coming months.

Mike

Update: See the Privacy Law blog’s post and an editorial from Ann Cavoukian, the privacy commissioner for Ontario.

Facebook’s latest privacy troubles

After years of controversy, Facebook may well end up in a Canadian Federal court this fall.

In August last year, Canada’s privacy watchdog, Jennifer Stoddart, announced that Facebook had agreed to improve its privacy protocols to be compliant with the Personal Information Protection and Electronic Documents Act (PIPEDA).

But instead of working to address the concerns, last December Facebook implemented changes that effectively further reduced user privacy. These changes effectively required users to manually modify settings to avoid friends, personal information and photos from being shared. According to the Wikipedia entry Critcism of Facebook:

… a user whose “Family and Relationships” information was set to be viewable by “Friends Only” would default to being viewable by “Everyone” (publicly viewable). That is, information such as the gender of partner you are interested in, relationship status, and family relations became viewable to those even without a Facebook account.

Facebook clearly have decided that the increased revenue possible from sharing personal information is worth battling government privacy commissioners and lawyers. And that’s fine — so long as our government continues to enforce our laws and bring violators to account, we can play that game too.

I’ve never had a Facebook account. I can be patient.

But those that still trust Facebook with personal information — and haven’t bothered to examine the minutia of the site’s privacy settings — will continue to have their personal information shared with 400 million users and thousands of advertisers, data aggregators and, well, pretty much anyone else on the Internet. At least until the wheels of justice grind to conclusion…

Mike

Google’s latest privacy troubles

Update 05/27: Kim Cameron has an excellent post on this issue (and a clarification here) that illustrates the identity impacts of Google’s wifi scanning.

It would appear that Google’s Street View cars were actively collecting data from unprotected home wifi networks over the past several years. According to the New York Times article:

After being pressed by European officials about the kind of data the company compiled in creating the archive — and what it did with that information — Google acknowledged on Friday that it had collected snippets of private data around the world. In a blog post on its Web site, the company said information had been recorded as it was sent over unencrypted residential wireless networks as Google’s Street View cars with mounted recording equipment passed by.

I’m not sure how to react to this but it sure raises some questions:

Why would the Street View cars be scanning for unprotected networks in the first place? The company has said it helps to improve geo-location but given the other tools at its disposal, I suspect they weren’t relying on home network MAC addresses to keep their location data accurate.
Why would they then record user data — web sites visited, emails sent, etc. — and subsequently store it on central servers? How can this be classified as a ‘programming error’? Perhaps that explanation could fool some of the less technical authorities, but let’s get real here — systematic recording of user generated data when only the MAC address is needed IS NOT a programming ‘error’. It is a ‘function’.
Why would this only come to light after four years and why did it take a demand from a German official to inspect the car’s missing hard drive for this to become public at all?
Are we getting the full goods from Google, a company known for its privacy transgressions?

Companies like Google (and Facebook, a company with privacy troubles of its own) are successful because of the goodwill and trust extended to them by us. There are other search engines and cloud services out there we can use.

Breaches like this are bad enough — the pithy excuses and blatant PR spin when caught are even worse.

Mike

Federated Identity project

I’ve been scoping a Federated Identity Management project for a few months now. The implementation will include public users and business partners, and will support tens of thousands of users.

We are looking at a number of use cases with this design, including:

a low level of assurance with minimal shared attributes, and
a higher level of assurance with sufficient shared attributes to support a split profile.

The challenges are going to be related to privacy (the client is in the public sector) and legal issues. My focus for the next month will be to try and tackles these issues — or at least get a start on them — before we get too involved with defining the technical solution.

Mike

Why invest in IAM?

I find myself being asked this question, indirectly or directly, by clients and prospective clients alike. With all the demands on IT infrastructure spending and business application development (and integration), and with all the information security risks out there waiting for solutions to be implemented, why should an investment in IAM be a priority?

From the well-respected Kuppinger Cole blog comes this view:

Part of IAM’s job is protecting data, either directly or by protecting the systems that use and store data. That is also the backdrop against which compliance regulation, both internal and external, must be viewed. That also means that it is much easier to talk with business people about “access” rather than about “identity”. The big question is how do we control and monitor access to information and systems? To do that, we need to know who is allowed to do what – and who isn’t. The only way to achieve that goal is through true digital Identity Management. Anyone who thinks he can do it by granting rights and approvals based on IP addresses or MAC numbers is seriously kidding himself.

It strikes me as odd that there are still IT and information security professionals that believe IP and MAC access controls are sufficient, but it appears that this myth persists in enterprises.

Worse, I believe, is the view that the home-spun access control that has been built into legacy applications is ‘good enough’. Why replumb our existing enterprise and customer-facing systems with a new-fangled IAM solution when we have the problem solved already?

This is a powerful myth that can be hard to overcome. But compared to application-specific controls, IAM has some significant advantages:

Compliance — Organizations today must comply with legislation and their own policies. The access control sub-systems built-in to many legacy applications are simply not compliant, and it may require significant rework and duplicated processes to remedy. Conversely, an enterprise IAM solution can be implemented to be compliant from the start, and a single set of processes can be created to maintain identity and access information.
- Example: Privacy Impact Assessments (required in Canada for all projects that deal with personal information) can be done once and shared across all applications.
Audit Support — ‘Siloed’ access control systems are very difficult to report on at audit time. With IAM, consolidating information is much easier and correlating a user’s access through multiple systems can be achieved.
- Example: A single reporting tool or sub-system can meet most (if not all) auditor reporting needs.
Help Desk Efficiency — With IAM, a single console for Help Desk agents can be implemented for end-user support purposes. Naturally, a single system will offer improved efficiency and better service to end-users than multiple, application-based systems.
- Example: Help Desk lookup tools can be standardized and easily learned by new staff. Password policies become consistent. Access to multiple systems can be suspended or revoked from a central point. Service to end-users improves.
Leverage and Speed — New applications, especially e-business and e-government systems that have to deal with privacy and security issues, can be readily designed around a common IAM solution. Deployments can be rapid due to standardized interfaces and re-use of common templates. Processes can be leveraged, not rewritten from scratch, making the transition to a production environment more seamless.
- Example: Strategic applications that need to be implemented ‘right now’ can be rolled-out quickly with high security, advanced features and appropriate user privacy protection. Decisions can be made with confidence that the common IAM solution will meet both enterprise and line-of-business requirements.

Real IAM solutions offer real value, making business case development easier and more compelling. However, widely-held myths about the effectiveness of network and application-specific controls need to be dealt with if broader IAM implementations are to be approved, funded and supported.

Mike

Identity in health services delivery

I came across this interesting headline a while back: Healthcare Identity Management Is Necessary First Step to Electronic Health Record Interchange. The article has a link to a briefing from the Smart Card Alliance. While this is an American organization, the context is similar enough to the Canadian identity management issues in health service delivery. The briefing has a fascinating statistic:

More than 195,000 deaths occur in the United States because of medical error, with 10 out of 17 medical error deaths due to “wrong patient errors.”

The implication is that a large number of lives could be saved by improving identity management, and the brief’s answer to this is, predictiably, to implement smart cards. The Smart Card Alliance feels that all citizens and health services professionals should be issued cards.

First of all, I think that smart card technology is very well suited to high-value transactions like those carried out in the health sector. The form factor is convenient, the technology is robust and there are some good solutions out there that make session switching on shared computers fast and easy.

But in health service delivery, particularly in Canada, the identity and access issues are not the real concerns for physicians — whether I am insured or not, whether my health information is online or not, the physician’s job is to diagnose and treat. This is particularly true in acute care situations such as emergency. My understanding is that doctors and nurses in those environments are reluctant to use systems if those systems get in the way of treating sick or injured people, even if those systems contain in-depth medical records. Implementations of smart cards — or any other technology — need to be slick and flexible to be adopted.

On the patient side, I agree that it makes sense for patients to access their own electronic health record over the Internet. Smart cards are touted by the Smart Card Alliance as being a secure solution for strong authentication over the web, and although I’m aware of some exploits, it is a proven technology. The issue then becomes how to provision all those millions of users. There are certainly some good processes out there for identifying individuals, but because most of them require in-person registration (or some other form of corroboration) there is the question of cost. I know in Alberta we have recently empowered our network of registry agents to perform eligibibility services (i.e. identification) for the health system and presumably this could be used to issue a smart card or other second-factor credential.

How would a fractured American system handle this provisioning? Who would be responsible for issuance, changes, revokation, ruling on eligibility, etc.? And who will pay for the smart cards and readers?

And what privacy issues would emerge from such a solution? Keep in mind that a strong credential such as a health services smart card would have the potential to become a national credential for Americans. Identity fraudsters would seek out weak links in the on-boarding process to obtain this valuable credential. And future governments would have the ability to link medical and other records to a host of other databases…

Clearly, users would need to have clear rights and remedies, something that may be difficult in a country that does not have national privacy legislation.

It is a complicated topic, one that the Smart Card Alliance’s brief does not properly address in its zeal to promote their specific technology.

Mike