Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

9/23/2008
01:44 AM
Sara Peters
Sara Peters
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Information Cards Are Awesome; But Are Identifying Parties Really Ready To Do This Right?

Perhaps the greatest thing about information cards is that they might finally free us from the purpose-defeating and idiotic practice of using Social Security numbers as a nigh-universal identifier. But it won't work unless the Identifying Parties find a way to balance security with portability, and can smartly manage distribution, expiration, and destruction.

Perhaps the greatest thing about information cards is that they might finally free us from the purpose-defeating and idiotic practice of using Social Security numbers as a nigh-universal identifier. But it won't work unless the Identifying Parties find a way to balance security with portability, and can smartly manage distribution, expiration, and destruction.As InformationWeek reported, Microsoft released a white paper calling for all hands on deck to support an "Information Card system that uses an interoperable vendor-neutral framework for identity management and provides end users with direct control of their digital identities."

Here, freakin, here! Nevertheless, there's still a ways to go before information cards are really a viable solution -- most of the barriers are merely administrative peccadilloes that need to be sorted out by the parties providing and verifying identity data.

A few words about Social Security numbers... As I've griped about before, the big problem with using SSNs in identity management is that we tend to use them as though they're a "something-you-are like" -- like your fingerprint or your retina, valued for being individual, unchangeable and nigh-impossible to copy -- but in actuality an SSN is just a "something-you-know," like a password....

...Except that an SSN is worse than a password, even worse than useless as an identifier. First of all, it's easy to brute force: always nine characters (unless it's truncated, and then you may only need four) and only 10 possibilities for each character. Second of all, unlike a fingerprint, (or a driver's license number, or a bank account number, or really just about any piece of personal data) there is no way to verify that the Social Security Number you've provided is actually yours.

Why is it impossible to verify? Because the Social Security Administration will not tell anyone what SSN belongs to whom, apparently because it would jeopardize individuals' privacy and the security of the numbers.

The administration won't even tell Fair Isaac, the company that maintains all those records that TransUnion and Equifax use when calculating your credit score. This is at the root of the whole financial fraud conundrum. Right now, Fair Isaac might very well have credit report data for three different people, with three different names, all using the same Social Security number. Fair Isaac knows that at least two of those are fraudulent, but there's no way of knowing which one, because the Social Security Administration will not tell them. The only really legitimate way of proving that SSN is yours is by providing, in person, a hard-copy Social Security card -- which, by the way, never expires, carries none of the anti-spoofing technology now in driver's licenses or passports, and isn't even considered a valid proof of U.S. citizenship when you're applying for a passport.

The beautiful thing about information cards is that they make this SSN nonsense disappear, by using an entirely different logic (translation: they use logic, period) than that used by the Social Security Administration and those parties that accept/require SSNs as proof of identity. With an information card, the information itself isn't very important -- in some instances it might actually be entirely unnecessary. The important part is that the information has been verified by a trusted identifying party. "An information card from a bank may not need to contain the user's account number. All it needs to do is provide a digitally signed confirmation from the bank that says "yes, I really am the bank, and yes, this user really is who he says he is, and yes, indeed, he does have an account with us [and maybe even] yes, he's got the money to pay for whatever it is he's purchasing through your Web service." An information card from the Department of Motor Vehicles might not need to give a gambling Web site your birthdate; it simply needs to say "I'm the DMV and I confirm that this person is at least 18 years old."

In this way it's better than the hard-copy IDs in your wallet. The relying party gets the information it wants, without forcing the user to toss around personal data willy-nilly.

However, the trouble with information cards is that they're simply digital files, which means they can be copied by someone other than the identifying party, stored on several devices, and transmitted over insecure channels.

InfoCards, like encryption keys, must be both transmitted and stored securely. (Can one never escape the slings and arrows of key management?) If an attacker gets hold of those InfoCards, then the identifying (verifying) party will, unknowingly, attest to the fraudulent claims of the attacker without the attacker needing to know a single piece of the victim's personal information.

So, first off, the user and the relying party must exchange InfoCards over a secure connection to avoid a nefarious man in the middle from snatching a copy of that card. Hopefully, encrypted communication of keys is something relying parties are doing already.

Second, those InfoCards must be locked up tight while they're simply at rest. The "InfoCard" folder residing on a user's desktop could be encrypted, or the InfoCards could be stored and encrypted in the client machine's TPM chip (Trusted Platform Module).

The trouble there is that -- unlike the cards in your wallet -- you're not willing to strap your machine to your back and carry it with you everywhere you go. (Though some of us -- and I'm not naming names -- kind of do lug our machines everywhere, even to that concert I went to last week.)

The infocards must be portable, so it's likely they'll be stored on a smartcard or an encrypted USB stick.

Yet they must also be secure -- so that portable device containing the issued information card should be obtained in-person, directly from the identifying party. (If you lose it you have to go back in person, just like if you lose your driver's license or your birth certificate.) Further, privileges to create, copy, or edit that information card should be exclusive to the identifying party

However, you don't really want to loop a zillion USB sticks alongside your house keys. So it would be great if you could put them all on one stick. However, if you're not permitted to copy all of those information cards onto one handy USB stick, then you must hope that the identifying parties will agree to place the data onto the USB stick you provide.

It sounds like all this calls for interoperable standards. Hopefully the collaborative work being done by Microsoft and the Information Card Foundation will help us move in that direction.

InfoCards are awesome, far better than the current options and entirely worth the effort. But, like many of our most promising security technologies, administrative hurdles must be overcome before the technology can really take off.

(More on this stuff in our Identity 2.0 Summit at CSI 2008: Security Reconsidered.)

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/13/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-14300
PUBLISHED: 2020-07-13
The docker packages version docker-1.13.1-108.git4ef4b30.el7 as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 (https://access.redhat.com/errata/RHBA-2020:0053) included an incorrect version of runc that was missing multiple bug and security fixes. One of the fixes regressed in th...
CVE-2020-14298
PUBLISHED: 2020-07-13
The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously fixed via RHSA-2019:0304. This issue could allow a malicious or compromised container to compromise the co...
CVE-2020-15050
PUBLISHED: 2020-07-13
An issue was discovered in the Video Extension in Suprema BioStar 2 before 2.8.2. Remote attackers can read arbitrary files from the server via Directory Traversal.
CVE-2020-10987
PUBLISHED: 2020-07-13
The goform/setUsbUnload endpoint of Tenda AC15 AC1900 version 15.03.05.19 allows remote attackers to execute arbitrary system commands via the deviceName POST parameter.
CVE-2020-10988
PUBLISHED: 2020-07-13
A hard-coded telnet credential in the tenda_login binary of Tenda AC15 AC1900 version 15.03.05.19 allows unauthenticated remote attackers to start a telnetd service on the device.