New Authentication Scheme Proposed

jerel brings us a story about a prototype authentication system which approaches security from an atypical angle. It focuses on hiding identity challenges from attackers in addition to the responses. The system, Undercover [PDF], "uses a combination of visual and tactile signals in the authentication process." "The system displays a set of images to the user and asks if any belongs to the image portfolio that the user had previously selected. At the same time, the trackball sends the user a signal that maps each button on the case to a certain answer. The user's hand must cover the trackball for it to operate, so a sneaky observer wouldn't be able to see his or her selections, or answers. So a would-be attacker can't 'see' the tactile challenge presented by the trackball and therefore doesn't get the user's authentication data, even though he or she could see the image challenge on the display."

Comments

Keypad

[mpickut]

I've seen keypads with digital readout on the keys used in jails (my job takes me in and out of jails frequently). The keypad scrambles the digits each time and there is a prism-type covering over the keys so that unless you are looking directly at it you cannot see the numbers on each key. In order to see the numbers you need to stand in such a way that no one else can see them (your head blocks their view from the only angle the numbers are readable from).

I tried to get the code by watching as the guards let me in and out, just to see how effective it was, and can say that I never succeeded in even getting close. What was even better is that from talking to the offenders I learned that they thought they knew the codes by watching the patterns the keys were pressed by the guards -- I didn't have the heart to tell them that using the pattern they had watched would actually punch in a different code than the one the guards used. I did make sure one of the guards knew about it though.

Small sample size

[ssjx]

They seem to have big plans for this yet have only tested it with 38 users?

Re:The problem with authentication is authenticati

[naasking]

1) It would still seem that the decision to initially hand the capability to the user has to be made with knowledge of who the user is, and

You pose some good questions which I intend to address, but first there are a number of assumptions in this one statement which has lead people astray in the past, so I want to address those first.

The User: just about every single access control discussion, particularly informal ones like this thread, start by talking about "users". Talking about "users" quite naturally dovetails into discussions of identities, then authentication, and finally the natural access control abstractions end up looking identity-based like Unix/Windows. The problem with this approach is, users generally aren't a threat. The real threats are from programs.

Access control is mainly about maintaining the integrity of a system in the presence of malicious programs. When viewed this way, identity-based access control starts to look meaningless. The "identities" of programs is a much fuzzier concept than the identities of users, but this is the right way to view access control. You can deal with program identities ala Polaris, and the resulting system is usable, but it's far simpler to eschew identities entirely.

Once you eschew identities, dealing with authorizations as distinct entities looks more natural. The more fine-grained the authorization, the better. Since programs are the only entities handling these authorizations, it doesn't matter how fine-grained we make them. Most of the heavy-lifting is done behind the scenes, hidden from users. When accessing a resource, you have to name it, then provide the authorization token demonstrating you have permission access to it. Then you start to wonder why the designation and the authorization can't be combined into a single handle for convenience. They can! They're called capabilities. Some other designs maintain this separation, but I can't find the reference to the paper at the moment.

Now comes the question: where do these capabilities come from, and how do we get them? The simple answer is: initial conditions. Just like the Big Bang, the universe of objects inside a computer is constructed at installation time. The installer constructs the primordial storage manager, user manager, shell, etc. from which the primordial user can allocate more storage to create other users, and endow them with capabilities, and so on.

At this stage, I've only been talking about programs all contained within a single computer. Now we come full circle to your question: how does someone outside the computer get (re)connected to their session which exists inside the computer? Note first that this is only a problem for a computer shared amongst multiple users.

To maintain the security properties, you need: portable sessions, as you suggested, a portable authorization token, or some form of secure authentication. This is the only authentication step needed, and even then it's not necessarily required.

Your comment seems to imply that an authentication is needed for every interaction with a new object, when you only need to authenticate with one computer, your own, and if you can carry that computer with you (pda, cellphone, etc.), then no further authentication is ever needed. A portable authorization token can be a USB key or a secure card that holds a cryptographically-secure hash designating your session. I prefer the last option, as its the most user friendly, and the most secure.

2) I'm curious how you would go about restoring security were such a persisted capability stolen.

This is a long-standing fear of system administrators everywhere. "Capabilities grant you flexibility and POLA, but you lose control!" There is a thread going on right now on the cap-talk mailing list about this actually. There are many possible ways to address this concern actually, and the only answer t

Re:The problem with authentication is authenticati

[naasking]

I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion.

If by "multi-user networked systems" you mean systems which host multiple competing interests which are mutually suspicious, then I agree. The vast majority of systems are computer programs communicating with other computer programs, some at the behest of a single user or multiple users, some based on a schedule, etc. If you can solve the problem of safe collaboration among mutually suspicious programs, then any other interaction I can think of falls out as a special case.

Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.

Exactly, because there is no tangible distinction. Any "user" is communicating with you via some program, presumably under his control. It's programs all the way down.

I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time.

A good start is Mark Miller's thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.

I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators.

Obviously I can't comment on any specifics without researching further, so you could be right. I would be disappointed if such legislation mandated a specific strategy to track information, rather than simply mandate that certain information be available should it be needed.

However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.

Agreed! Delegation control and responsibility tracking are very important, which is why some capability folks designed Horton, which can be viewed as a sort of identity framework built on top of pure capabilities. Identities should only be used for reactive measures however, in case of abuse to identify the offending party and throttle or terminate abuse.

So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).

Whether the user/program intentionally or accidentally leaked his capability, you still have to revoke it to prevent abuse. I'm not sure what authentication gains you here. Identifying the capability is typically straightforward.

That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.

Yes, there are no doubt other categories of systems. For instance, the KeyKOS capability operating system was used in early ATM systems starting in the 80s. I'm sure it had something to say on the subject. I hope you have time to research the rich literature of capability access control. :-)