Supposedly, it's easier to just ask someone nearby where you are rather or how to get someplace than using mobile navigation applications - at least until the phone interfaces make this less cumbersome.
Whoever believes this has never asked a random passerby how to get to Ueno Park from Shinjuku in Tokyo. 'Sumimasen, Ueno doko desu ka?' only gets you so far.
Thursday, November 24, 2005
Wednesday, November 23, 2005
Ummmmm Bacon
Andre Durand conjectures that the network is collapsing (in the sense that nodes, be they devices or people, are more easily connected than in the past). With the help of his mathematician father, he explores the rate of collapse, e.g. from year to year how much closer are the nodes. Interesting stuff.
As a starting point, they use what they call 'Kevin Bacon's 6 Degrees Theory'. Problem is, I don't think there is such a theory - this expression conflates two different ideas of small-world research.
The first is the well-known '6 degrees of separation' theory - the idea that anyone on the Earth can be connected to any other through a chain of at most 5 acquaitances. The second aspect is a game called 'Six Degrees of Kevin Bacon' in which Hollywood actors are labelled by their 'distance' from Kevin Bacon, this determined by how many links there are in the chain of co-actors between them and Bacon. So, different actors are said to have different 'Bacon numbers' (just as mathematicians can be labelled by their Erdos number)
But, as far as I know, there has never been a conjecture that the number 6 is in any way special for the Bacon number. A variety of actors will have this for a Bacon number, but many others will have Bacon numbers of 5 and 7.
It's meaningful to explore either the possibility that '6 degrees of separation' is becoming '5 degress of separation' (likely but by no means certain) or the possibility that a given actor's Bacon number decreases over time (it can't get larger) - but seems to me that Andre and his father are trying to combine the two.
Maybe we should define a Cameron Number, e.g. how distant people are from Microsoft's Kim Cameron - this distance defined with respect to blog roll membership (among other possible criteria like shared conference attendance). I don't personally know Kim but nonetheless have a Cameron Number of '2' (thank you Pat Patterson).
As a starting point, they use what they call 'Kevin Bacon's 6 Degrees Theory'. Problem is, I don't think there is such a theory - this expression conflates two different ideas of small-world research.
The first is the well-known '6 degrees of separation' theory - the idea that anyone on the Earth can be connected to any other through a chain of at most 5 acquaitances. The second aspect is a game called 'Six Degrees of Kevin Bacon' in which Hollywood actors are labelled by their 'distance' from Kevin Bacon, this determined by how many links there are in the chain of co-actors between them and Bacon. So, different actors are said to have different 'Bacon numbers' (just as mathematicians can be labelled by their Erdos number)
But, as far as I know, there has never been a conjecture that the number 6 is in any way special for the Bacon number. A variety of actors will have this for a Bacon number, but many others will have Bacon numbers of 5 and 7.
It's meaningful to explore either the possibility that '6 degrees of separation' is becoming '5 degress of separation' (likely but by no means certain) or the possibility that a given actor's Bacon number decreases over time (it can't get larger) - but seems to me that Andre and his father are trying to combine the two.
Maybe we should define a Cameron Number, e.g. how distant people are from Microsoft's Kim Cameron - this distance defined with respect to blog roll membership (among other possible criteria like shared conference attendance). I don't personally know Kim but nonetheless have a Cameron Number of '2' (thank you Pat Patterson).
Tuesday, November 22, 2005
QR codes for two-factor authentication
On a recent trip to Tokyo, I was able to see some of the work of my colleagues at the Tokyo NTT Information Platform Sharing Laboratories exploring the potential of two-channel authentication systems. Such systems generally depend on various permutations of secrets shared across both a PC channel and a separate device channel. In essence, the phone serves as a second authentication factor.
Existing two-channel systems rely on either:
1) the client providing a phone number at registration time to which the service provider sends a OTP over SMS when the user logs in. When received by the user on their phone, they then enter it on the PC interface. By verifying the presented OTP, the server can be confident that the user is indeed the owner of the phone and therefore the account holder.
2) the server creating a one time phone number and presenting it to the user through the PC-channel. The user then calls this number from a phone with a previously registered number. The server, by verifying that the call came from a registered number, can be confident that the user is the account holder.
Both systems require that the user's phone number be provided to the server, which presents both privacy and scaleability (the server has to store these numbers) issues. The first relies on the security of SMS.
My colleagues are working on alternatives that:
a) don't rely on a phone number being registered/stored
b) leverage the certificates on many Japanese phones for client-auth SSL
c) authenticate the server as well
In both models above, it is the user that acts as the conduit by which the PC and phone channels are connected (this necessary for them to be correlated and authenticated). In the first, the user takes the OTP from the phone and types it into some HTML form; in the second, the user takes the presented phone number and manually dials it.
The research is exploring the potential for a technology mostly unique to the Japanese market to provide this connection/interface between the two channels. QR codes are two-dimensional bar codes into which can be embedded significantly more information. Critically, over 77% of Japanese phones have support for QR code readers. The phones' cameras can thereby serve as the conduit through which the two channels can be connected and correlated.
The prototype system has the server generate a dynamic QR code and present it to the user when authentication is required. The user uses their phone to take a picture of the code from their PC screen - the phone QR software then extracts the corresponding server address to which a mutual SSL session is established. To authenticate the server, the user sends a short text string from their PC as a nonce that the server signs and presents to the phone.
Below are pictures of 1) a user taking a picture of an on-screen QR code with their phone and 2) the phone display by which the server is authenticated.
The system is attractive because it leverages a (ubiquitous) second factor that users already have and expect to use, requires no specialized client software, does away with the privacy/scaling issue of stored phone numbers, and doesn't rely on the questionable security of SMS.
As Bruce Schneier points out, such systems can't guard against MITM attacks:
An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can't do it himself.
Nevertheless, to say that a technology doesn't prevent one attack doesn't mean they provide no value in defending against others.
Monday, November 21, 2005
Separation of Powers
Separation of powers is the concept within democratic government in which powers are distributed amongst different government organs to prevent any one of them from abusing that power. Along with checks-and-balances (the ability and responsibility of each to monitor the activities of the others), separation of powers is intended to reduce opportunities for tyranny.
Federated identity is sometimes criticized for exacerbating the risk of identity theft through its connection of currently separate identity collections into a greater virtual whole. The argument goes something like:
'So, if I login to the identity provider, I can then access my resources at some other service provider? That sounds nice but what happens if my identity at the identity provider is stolen/phished/pharmed/hacked, can't the thief, because of the connection, immediately jump to the service provider and steal my identity there?'
The argument is based on the assumption that some rogue individual, on hacking the identity provider, can get everything they need in order to impersonate me so that they can access my multiple federated service provider accounts.
Here is the rub though. It does the hacker no good to impersonate me, they have to impersonate the identity provider. As they do not know my various service provider credentials, they have to convince the service provider that they are the identity provider asserting to my authentication status. And, the burden of authenticating one site to another site (not to a user as in phishing) is considerably more challenging for a hacker.
If a hacker is to fool a service provider into accepting a counterfeit assertion for me (and thereby assume my identity at that service provider) it needs to present two things:
1) whatever federated identifier had previously been agreed upon between the service provider and the identity provider for myself. Present a random string and the service provider will refuse access because it won't recognize it as one of its federated users. Even if the hacker were to by chance get lucky and pick a valid identifier, its only valid when presented by the corresponding identity provider. see 2) below
2) a signature over the message carrying the above identifier associated with a key trusted by that service provider. Not any key issued by Verisign will do, the service provider will certainly keep a list of 'trusted IDPs' and if the associated key is not on the list then you are not invited to the party.
If the identity provider does things "right", then it will ensure that it is very difficult for any one entity (internal or external) to steal both of the above (it will almost certainly make it difficult to steal either as well). A "good" identity provider will implement "separation of powers" to ensure that, were one of the above was stolen, the other wouldn't be.
You can fool such an IDP once, but likely not twice.
"There's an old saying in Tennessee — I know it's in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can't get fooled again." —President George W. Bush, Nashville, Tenn., Sept. 17, 2002
Federated identity is sometimes criticized for exacerbating the risk of identity theft through its connection of currently separate identity collections into a greater virtual whole. The argument goes something like:
'So, if I login to the identity provider, I can then access my resources at some other service provider? That sounds nice but what happens if my identity at the identity provider is stolen/phished/pharmed/hacked, can't the thief, because of the connection, immediately jump to the service provider and steal my identity there?'
The argument is based on the assumption that some rogue individual, on hacking the identity provider, can get everything they need in order to impersonate me so that they can access my multiple federated service provider accounts.
Here is the rub though. It does the hacker no good to impersonate me, they have to impersonate the identity provider. As they do not know my various service provider credentials, they have to convince the service provider that they are the identity provider asserting to my authentication status. And, the burden of authenticating one site to another site (not to a user as in phishing) is considerably more challenging for a hacker.
If a hacker is to fool a service provider into accepting a counterfeit assertion for me (and thereby assume my identity at that service provider) it needs to present two things:
1) whatever federated identifier had previously been agreed upon between the service provider and the identity provider for myself. Present a random string and the service provider will refuse access because it won't recognize it as one of its federated users. Even if the hacker were to by chance get lucky and pick a valid identifier, its only valid when presented by the corresponding identity provider. see 2) below
2) a signature over the message carrying the above identifier associated with a key trusted by that service provider. Not any key issued by Verisign will do, the service provider will certainly keep a list of 'trusted IDPs' and if the associated key is not on the list then you are not invited to the party.
If the identity provider does things "right", then it will ensure that it is very difficult for any one entity (internal or external) to steal both of the above (it will almost certainly make it difficult to steal either as well). A "good" identity provider will implement "separation of powers" to ensure that, were one of the above was stolen, the other wouldn't be.
You can fool such an IDP once, but likely not twice.
"There's an old saying in Tennessee — I know it's in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can't get fooled again." —President George W. Bush, Nashville, Tenn., Sept. 17, 2002
It's a Mad Mad World
In the Cold War, Washington advertised one policy for the use of its nuclear weapons while privately holding a very different strategy.
The visible & public policy was referred to as Assured Destruction (the 'mutual' was later added by a critic to create a more derisive acronym). AD was the idea that the only sane application of nuclear weapons was a non-application - if both sides were completely confident that they would be destoyed in any altercation they would be unwilling to strike first, and so nuclear weapons would never be used. The opposing counterforce strategy (which Qwynne Dwyer in his book War claims Washington actually held even whilst professing AD) saw such weapons providing value above and beyond their deterrent effect through their potential delivery in a controlled and constrained manner in a conventional war .
So, the "real" policy was much less restrictive in its criteria governing the 'release' of the ICBMs. While AD was based on the premise that one side's missiles would only be lanuched in retaliation to a first strike from the other side (stringent criteria) - the counterforce policy asserted that weapons could be deployed in a range of situations, e.g. in a tactical manner even as part of a convential non-nuclear altercation (relaxed criteria).
(This is the exact opposite of what I might have expected, e.g. a public bluff of aggressiveness but a more realistic and sane private plan. Of course, there were vested interests involved for which the status quo of maintaining weapon expenditure was desirable)
I wonder if the idea of different public/private policies is relevant for any policy governing release of identity information? Would a provider claim to be governed by one policy whilst actually listening to another?
If the visible policy were less stringent than the actual, the provider would receive attribute requests that would be immediately rejected - requests that would not have been sent if the advertised policy were accurate. Beyond the inefficiency, this is a privacy leak as the provider would unnecessarily learn at which requestor sites the principal had been visiting. If the advertised policy were more stringent, then the requestor might not even send requests that would be approved had they been - doesn't seem much risk (or sense) in this.
The visible & public policy was referred to as Assured Destruction (the 'mutual' was later added by a critic to create a more derisive acronym). AD was the idea that the only sane application of nuclear weapons was a non-application - if both sides were completely confident that they would be destoyed in any altercation they would be unwilling to strike first, and so nuclear weapons would never be used. The opposing counterforce strategy (which Qwynne Dwyer in his book War claims Washington actually held even whilst professing AD) saw such weapons providing value above and beyond their deterrent effect through their potential delivery in a controlled and constrained manner in a conventional war .
So, the "real" policy was much less restrictive in its criteria governing the 'release' of the ICBMs. While AD was based on the premise that one side's missiles would only be lanuched in retaliation to a first strike from the other side (stringent criteria) - the counterforce policy asserted that weapons could be deployed in a range of situations, e.g. in a tactical manner even as part of a convential non-nuclear altercation (relaxed criteria).
(This is the exact opposite of what I might have expected, e.g. a public bluff of aggressiveness but a more realistic and sane private plan. Of course, there were vested interests involved for which the status quo of maintaining weapon expenditure was desirable)
I wonder if the idea of different public/private policies is relevant for any policy governing release of identity information? Would a provider claim to be governed by one policy whilst actually listening to another?
If the visible policy were less stringent than the actual, the provider would receive attribute requests that would be immediately rejected - requests that would not have been sent if the advertised policy were accurate. Beyond the inefficiency, this is a privacy leak as the provider would unnecessarily learn at which requestor sites the principal had been visiting. If the advertised policy were more stringent, then the requestor might not even send requests that would be approved had they been - doesn't seem much risk (or sense) in this.
Friday, November 18, 2005
Bidirectional PII leakage
Motivated by a spate of fiascos and consequent legislation, enterprises are currently focussed on ensuring that any privacy sensitive data they may hold about individuals doesn't leak out.
Given the risks of damage to reputation and liability associated with storage of such data, how long is it before enterprises worry just as much about not allowing PII to leak in?
Ben Laurie suggests that one tenet of privacy-respecting identity management is minimalism, i.e. that only that identity information required for a particular application be shared and no more. He describes it as a principal for the protection of the individual - which it is of course.
But, it's also protection for the data requestor/recipient. Unless it has an immediate and (business)justifiable need for some piece if identity information, why ask for it, or even accept it if not requested but nonetheless offered? Or store it past any usage? Better let some identity provider, presumably with a business model and corresponding security technology and processes take the burden and risk.
Just remember to log that you didn't accept it.
Given the risks of damage to reputation and liability associated with storage of such data, how long is it before enterprises worry just as much about not allowing PII to leak in?
Ben Laurie suggests that one tenet of privacy-respecting identity management is minimalism, i.e. that only that identity information required for a particular application be shared and no more. He describes it as a principal for the protection of the individual - which it is of course.
But, it's also protection for the data requestor/recipient. Unless it has an immediate and (business)justifiable need for some piece if identity information, why ask for it, or even accept it if not requested but nonetheless offered? Or store it past any usage? Better let some identity provider, presumably with a business model and corresponding security technology and processes take the burden and risk.
Just remember to log that you didn't accept it.
SP Collusion
Dictionary.com defines 'collude' as
'To act together secretly to achieve a fraudulent, illegal, or deceitful purpose; conspire'.
In the context of identity management, the term is typically used to refer to multiple providers communicating together about some principal without that principal's consent.
If each provider stores some aspect of a given principal's digital identity - collusion between them is made possible if the nature of such identity information allows them to infer that it is the same individual with which they both have accounts.
Federated identity management, if done improperly, can enable collusion by simplifying the correlation burden for the rogue providers. This because, valid (e.g. based on informed consent) connections between the two providers and some other third provider can provide to the rogue providers the necessary correlation keys.
Federated single sign-on (SSO) can be used to explore the dangers. In SSO, a user authenticates to an IDP, and then the IDP creates claims to that effect for use at other SPs. Correlation and collusion is enabled if the claims are not created carefully. If the same user presents two different claims to two different SPs, the SPs might be able to correlate the claims as referring to the same principal through any of the following mechanisms:
A common identifier in both claims, e.g. if an email address or SSN is used to identity the subject for which the claim was generated. SAML 2 and Liberty address this by defining mechanisms by which identifiers unique to each IDP-SP pairing are established and used.
sufficiently identifying attributes, e.g. if both claims describe me as male, 41, working on identity management, living in Canada, tired father of 3, then the SPs would be able to infer that their different local acocunts referred to the same user, me.
small-community IDP, e.g. if both claims are issued by an IDP known to only issue claims for a small community of end users, then the SPs can narrow down their focus. If the IDP is associated with a single principal then its trivial.
temporally, e.g. if the two SPs somehow knew that the nature of some other application required real-time data from both of them, then perhaps they could use the timing of the requests to correlate. For instance, one SP is a calendar service, another a shipping service. If both SPs received a request for one of their user's data within some window of time from a home grocers site, then the two SPs could infer that their two users might be the same. If it happened again it would be confirmed.
keying material, e.g. if the keys used to ensure HOK subject binding were to be reused for the two SPs, then they could correlate based on that.
I'm sure there are others.
'To act together secretly to achieve a fraudulent, illegal, or deceitful purpose; conspire'.
In the context of identity management, the term is typically used to refer to multiple providers communicating together about some principal without that principal's consent.
If each provider stores some aspect of a given principal's digital identity - collusion between them is made possible if the nature of such identity information allows them to infer that it is the same individual with which they both have accounts.
Federated identity management, if done improperly, can enable collusion by simplifying the correlation burden for the rogue providers. This because, valid (e.g. based on informed consent) connections between the two providers and some other third provider can provide to the rogue providers the necessary correlation keys.
Federated single sign-on (SSO) can be used to explore the dangers. In SSO, a user authenticates to an IDP, and then the IDP creates claims to that effect for use at other SPs. Correlation and collusion is enabled if the claims are not created carefully. If the same user presents two different claims to two different SPs, the SPs might be able to correlate the claims as referring to the same principal through any of the following mechanisms:
I'm sure there are others.
Thursday, November 17, 2005
SSSO - Social Single Sign On
There is nothing social in default SSO. There is a single user and he/she, based on an authentication performed at some identity provider, is granted appropriate access for their own resources at some service provider. There would seem to be some unexplored social (i.e. more than a single user involved) aspects of SSO.
For instance, a user may be SSOing in to access resources belonging to another user. If I define the permissions at some online photo site such that certain friends can see my recent photos; if and when those friends log-in to that photo site they will be granted those privileges. If they log-in with an account local to the photo site then its very straightforward for me to define privileges against the corresponding identifier and for the site itself to enforce them. This is how sharing currently works at such sites.
However, if they don't have such an account nor desire to create one, they will want to access my photos based on an authentication performed elsewhere, e.g. SSO in to the photo site. The challenge now becomes how the photo site gets an identifier for the friend to which the privileges can be assigned and how users can track and manage the social relationships relevant to their online interactions. The Liberty Alliance People Service is designed to facilitate this.
Another social angle comes from the fact that, in many situations, the nature of the credential by which a user authenticates to an IDP is such that the IDP can't unambiguously identify them as individuals. For instance, when I access the Net from my home PC, my ISP knows only that I am one of the family members with access to that PC. Based on that shared credential I should be able to SSO to some SP and be granted permissions appropriate to mmy family, but not to any particular member. So, I might be able to see the family's calendar but not my personal one (at least not until I re-authenticated with a credential that did allow the IDP to unambiguously identify me and make an assertion to this effect to the SP).
For instance, a user may be SSOing in to access resources belonging to another user. If I define the permissions at some online photo site such that certain friends can see my recent photos; if and when those friends log-in to that photo site they will be granted those privileges. If they log-in with an account local to the photo site then its very straightforward for me to define privileges against the corresponding identifier and for the site itself to enforce them. This is how sharing currently works at such sites.
However, if they don't have such an account nor desire to create one, they will want to access my photos based on an authentication performed elsewhere, e.g. SSO in to the photo site. The challenge now becomes how the photo site gets an identifier for the friend to which the privileges can be assigned and how users can track and manage the social relationships relevant to their online interactions. The Liberty Alliance People Service is designed to facilitate this.
Another social angle comes from the fact that, in many situations, the nature of the credential by which a user authenticates to an IDP is such that the IDP can't unambiguously identify them as individuals. For instance, when I access the Net from my home PC, my ISP knows only that I am one of the family members with access to that PC. Based on that shared credential I should be able to SSO to some SP and be granted permissions appropriate to mmy family, but not to any particular member. So, I might be able to see the family's calendar but not my personal one (at least not until I re-authenticated with a credential that did allow the IDP to unambiguously identify me and make an assertion to this effect to the SP).
Wednesday, November 16, 2005
False claims?
Will an identity system allow me to lie?
I (and I expect most others) often provide false data to sites asking me for personal data. I'm more likely to do so if the site is asking me for specific identity information as opposed to some range. For instance, if the site asks for my birth date (or even age) it's very unlikely that I'll give the actual date (unless it will eventually serve as some credential). If instead, the site provides me a set of ranges of ages from which I can select I am far more inclined to be truthful.
Now, if an SP were to ask an IDP of mine for my age rather than me directly, what happens if the SP and request are such that I don't want the IDP to provide the real value. Does the IDP provide a value from a persona I've set up just for such requests? What is the meaning of such an assertion if there is another persona with my real age, i.e. is the IDP asserting to the truth of its claim or merely to the fact that its asserting a value previously supplied by me?
Seems to me that the problem with the current status quo of sites asking for my age is that there is no 'fall-back' option, e.g. if I want to proceed with setting up the account or purchasing whatever, the HTML form requires me to provide a value for the field. There is no negotiation possible, no leeway in the site's identity demands and consequently I respond with the only option that satisfies both this demand and my desire for privacy - I lie.
In the brave new world of identity, perhaps there is no need to lie. If an SP asks my IDP for my age, the IDP might respond with 'Why do you need it?', to which the SP would say 'Demographic study', so that the IDP would finish with 'Well then his age range of '35-45' will be sufficient'. Because there needn't be a binary yes/no for release of identity data, but a negotiated middle-ground, its more likely that both the SPs and mine can be satisfied.
I (and I expect most others) often provide false data to sites asking me for personal data. I'm more likely to do so if the site is asking me for specific identity information as opposed to some range. For instance, if the site asks for my birth date (or even age) it's very unlikely that I'll give the actual date (unless it will eventually serve as some credential). If instead, the site provides me a set of ranges of ages from which I can select I am far more inclined to be truthful.
Now, if an SP were to ask an IDP of mine for my age rather than me directly, what happens if the SP and request are such that I don't want the IDP to provide the real value. Does the IDP provide a value from a persona I've set up just for such requests? What is the meaning of such an assertion if there is another persona with my real age, i.e. is the IDP asserting to the truth of its claim or merely to the fact that its asserting a value previously supplied by me?
Seems to me that the problem with the current status quo of sites asking for my age is that there is no 'fall-back' option, e.g. if I want to proceed with setting up the account or purchasing whatever, the HTML form requires me to provide a value for the field. There is no negotiation possible, no leeway in the site's identity demands and consequently I respond with the only option that satisfies both this demand and my desire for privacy - I lie.
In the brave new world of identity, perhaps there is no need to lie. If an SP asks my IDP for my age, the IDP might respond with 'Why do you need it?', to which the SP would say 'Demographic study', so that the IDP would finish with 'Well then his age range of '35-45' will be sufficient'. Because there needn't be a binary yes/no for release of identity data, but a negotiated middle-ground, its more likely that both the SPs and mine can be satisfied.
Subscribe to:
Posts (Atom)