Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
An alternative access control system

By Stuart Ward in News
Thu Jul 06, 2000 at 02:35:54 PM EST
Tags: Security (all tags)
Security

Here I outline a system for providing continuous verification of users incorporating many systems of authentication, including biometric systems, into a structural whole and how this system is easier to use and improves security over the Entry Point access control system.


Entry Point Access control

Currently almost all computer systems work in this manner. The user is not permitted to perform any actions until they have presented a valid username and password to the system, performed an IKE authentication, or a Kerberos ticket exchange has successfully completed. After that point no further authentication activities are performed until the user logs out and attempts to re-enter. Some systems have a suspend function that is either operated by the user or on an inactivity timeout that then requires re-authentication before proceeding.

Continuous verification control

A continuos verification system will allow an anonymous user to execute a limited set of commands that are considered low risk. Commands that list the system identification, or list some help pages and the like. For each connection the system will maintain an Authentication Vector (AV) this vector will contain values as to how confident the system is to the identity of the user, what privilege level the user is allowed to access, and the time and level to which the user was last authenticated.

Each time a command or service is activated, the system will check the AV and compare this to a Required Authentication Level Vector (RALV) this function would look at the two vectors and determine if the current AV was sufficient to allow the execution of the command. If it was sufficient then the command is executed as normal.

Where the current AV is insufficient a mechanism is then invoked to increase the authentication of the user. I would envisage that the requested command fails and the error path then invokes a routine that is passed the RALV and the AV. This routine would examine the set of authentication mechanisms that are implemented on the terminal device that the user is using, the set of identification information registered, and the expected increase in the AV resulting from a successful authentication. It would then select an authentication method to check the user and execute it.

In the simplest case this may be the challenge for a valid user name and password pair, but it could incorporate many other systems. For example the system may have a set of challenge response questions for which the user has easily remembered answers, such as "what is your mothers maiden name?" or "What is your sisters date of birth?"

This system also allows for biometric identification systems, these generally return a confidence value as to how certain the system is that the real person is there, rather than a binary pass / fail value. The result of the biometric test is then weighted and added to the AV, if this then gives the user sufficient rights to execute the command the command could proceed as normal.

There are also continuos biometric systems that, for example, monitor the characteristics of keyboard use, looking at the time each key is pressed and the time interval between different key pairs. Or systems that look at the mouse movements and clicking. In tests these system have been found to give a high degree of accuracy especially if they accumulate their data over a reasonable period.

How would all this work?

Letís say you are a systems admin and you arrive at your desk in the morning. The first thing you will probably do is a bit of checking on how things are going, list a few log files and the like. For this level of access we have set just a fairly low level of RALV so you only need to give your username and answer two challenge questions chosen randomly form the ones stored in the system.

While you are doing this the keyboard use authentication system is monitoring you and the video camera mounted on your system is building up a picture of your characteristic head movements as you use the system. So after this when you come to kill of some processes that need to be restarted the system is sufficiently confident in your identity to let you do this.

Now you need some coffee and off you go to the coffee machine, and chat to some people in kitchen. An opportunist jumps on to your terminal and starts looking around. Immediately the continuous verification agents are reporting much lower confidence in your identity, as soon as the opportunist tries to do something critical the system challenges him with a question, even if they get the question right the keyboard use will reduce their overall AV score. The camera may have noticed your brief absence and reduced your AV score, if it genuinely you returning and you continue working with high level commands the system would require re-authentication.

All of these authentication systems running on the client system will need to be engineered in a tamper resistant manner, so that a hacker could not run a tampered demon that reported a false identity pattern to the system.

I have also talked about the "system" and a single amorphous blob. The actual implementation of the system I have described would probably be split into an Authentication Server from which the various systems that I was requesting access referred to verify my identity.

Easier to use

The more I use the system, the more confident the system is with my identity and hence lessens the reliance on authentication based on things that I know (passwords), and more on things that I am (biometrics).

There is no root level password in this scheme which removes a major line of attack for system hackers. There may be the need to have root level passwords on systems before they are incorporated into the authentication scheme but this would only be for new system being installed, as soon as they were networked and linked to the authentication server the root access could be disabled. Enabling it would require a very high level of identity authentication, if a hacker can achieve this he would have no need of root.

Links
BioAPI™ Consortium
The Biometric Consortium
The BioPassword System

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o BioAPI&tra de; Consortium
o The Biometric Consortium
o The BioPassword System
o Also by Stuart Ward


Display: Sort:
An alternative access control system | 15 comments (12 topical, 3 editorial, 0 hidden)
Sounds like Kerberos. (2.00 / 1) (#2)
by Inoshiro on Thu Jul 06, 2000 at 01:19:15 PM EST

IIRC, Kerberos times out and reissues tickets continously. Wouldnit it be easy to add an extra authentication step? Besides, I don't see a use for this, as most breakins happen not because of unattended terminals, but because of un-updated programs (such as BIND).



--
[ イノシロ ]
Overhead? (3.70 / 3) (#4)
by eann on Thu Jul 06, 2000 at 01:52:53 PM EST

It's an interesting idea. But there are a couple of places where I started to sweat:

For each connection the system will maintain an Authentication Vector...

Each time a command or service is activated, the system will check the AV and compare this to a Required Authentication Level Vector (RALV) this function would look at the two vectors and determine if the current AV was sufficient to allow the execution of the command.

So, at some point, every command and service on the system must be catalogued with a RALV in a sysadmin-configurable way (because some sysadmins want different commands enabled in different situations). And every command or program (or even potentially actions from within programs, like "do I have permission to write a file there?") has to check this list before it happens?

What a nightmare! On a system with hundreds of users connected (not unreasonable), this sounds like a tremendous memory hog. Sure, memory's not expensive these days, but this would play havoc with trying to tune for performance. If it's on a separate machine, then you still have the overhead of SSL connections for every action. Dunno about keeping those alive between commands. It seems like it'd save some processing power, but would that leave them open to attack? Network congestion, anyone?

Then, you throw in things like continuous biometric monitoring, feedback from a mounted camera (recognition software? retinal scan?), and it has to be extremely sensitive (head movements and typing speed), but not thwarted by the effects of a crummy dialup connection from my laptop in a hotel room in Florida?

It's an interesting idea. But I think it has a long way to go before I'd be willing to install it without a "traditional" override.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.


Re: Overhead? (none / 0) (#7)
by Stevie_G on Thu Jul 06, 2000 at 07:28:37 PM EST

So, at some point, every command and service on the system must be catalogued with a RALV in a sysadmin-configurable way (because some sysadmins want different commands enabled in different situations). And every command or program (or even potentially actions from within programs, like "do I have permission to write a file there?") has to check this list before it happens?

To a degree your right, but a large portion of common commands can be grouped together, thus eleminating this task. As far as permissions, interface this with the operating system.. *nix has a great permission system.. :)

What a nightmare! On a system with hundreds of users connected (not unreasonable), this sounds like a tremendous memory hog.

Not really.. If you have the required Required Vector, set uid to 0, if not, find a way to get to the required vector...

Network congestion, anyone?
[Y]ou throw in things like continuous biometric monitoring, feedback from a mounted camera (recognition software? retinal scan?), and it has to be extremely sensitive (head movements and typing speed) but not thwarted by the effects of a crummy dialup connection from my laptop in a hotel room in Florida?


Perhaps with the current state of biometric devices, this isn't possible. However, if we had devices that we could load a pattern into, and let the device (biometric, keyboard, mouce, whatever) determine how close the user is coming to this pattern.. then we could really get a lot closer.

The thing that would be interesting would be how we make sure that the pattern is right.

It's an interesting idea. But I think it has a long way to go before I'd be willing to install it without a "traditional" override.

True enough.. this would probally be better for Project Oxygen than anything else.

[ Parent ]
Re: Overhead? (3.00 / 1) (#9)
by eann on Thu Jul 06, 2000 at 09:26:31 PM EST

To a degree your right, but a large portion of common commands can be grouped together, thus eleminating this task.

I guarantee that no sysadmin will ever be happy with someone else's default grouping. I've worked on a system that had quotas enabled, but the quota command disabled. I had to use du to figure out how much disk space I was using. And one time, when my write failed despite not being near my quota, I discovered that df was off limits, too.

It still doesn't make a bleedin' bit of sense to me. I see quota, du, and df as very closely related. But that's the way this particular ISP ran their systems, so it's my first-shot counterexample. We can debate any point about any arbitrary set of commands, the solution is to allow the trusted administrator to modify the list at his or her whim.

As far as permissions, interface this with the operating system.. *nix has a great permission system.

Not if the OS doesn't believe the person trying to overwrite one of my files is actually me. The *n?x permissions could only apply *after* the other verification. And it's even believable that certain files should be allowed to require an extra challenge. Like, don't allow anyone to overwrite the kernel without running them through a gauntlet.

What a nightmare! On a system with hundreds of users connected (not unreasonable), this sounds like a tremendous memory hog.
Not really.. If you have the required Required Vector, set uid to 0, if not, find a way to get to the required vector...

What I imagined was a big table of "this command requires at least this vector", and a smaller table of "to get to this vector, use one of these confidence algorithms". For some reason (could be 'cos it was near 5:00), I was thinking this would have to exist for every user. Obviously it doesn't. It's a centralized operation, and a fairly simple SQL join to get all the info in one query. But, the number of entries in the table would still be quite large for most systems, and under heavy use it would have to stay cached.

That, of course, reminds me of the chip-makers' fondness for larger and larger L1 and L2 caches. You could do something like this really effectively by using special hardware with an authorization cache. :)

The thing that would be interesting would be how we make sure that the pattern is right.

Undoubtedly. My principal argument is that on heavy-load or finely-tuned systems, there just aren't enough processor cycles (or, in some cases, RAM or bandwidth) to get everything done. Yet.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.


[ Parent ]
Nope... (none / 0) (#15)
by Alhazred on Fri Jul 07, 2000 at 05:37:30 PM EST

Don't you think that checking file permissions on every file and in fact the kernel has to check every device, mount point, sym link, and directory all the way to the root already for each and every action you take at the command line as it is. The overhead is no more a problem than it is now. In fact on ACL based systems today like NT an entire set of ACL's has to be checked. You would be surprised how fast all that stuff is.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
MAC (none / 0) (#6)
by Anonymous Hero on Thu Jul 06, 2000 at 05:45:12 PM EST

Sounds like you are describing

1) Mandatory Access Control (MAC), where every operation has to pass a check to see if the user has sufficient permission to execute that operation

2) Some sort of neural network "learning" scheme



Time-lapse authentication has some drawbacks (none / 0) (#8)
by Anonymous Hero on Thu Jul 06, 2000 at 08:11:44 PM EST

The time-lapse authentication suggested has some serious drawbacks that, unless addressed, in my eye are serious show-stoppers. The nature of such a system requires time to build up confidence in the user. Such time is not always available. When systems crash or there is another urgent matter of business, the last thing the user wants to do it wait around for the system to gain sufficient confidence in them.

Re: Time-lapse authentication has some drawbacks (none / 0) (#10)
by adamsc on Thu Jul 06, 2000 at 11:13:19 PM EST

When systems crash or there is another urgent matter of business, the last thing the user wants to do it wait around for the system to gain sufficient confidence in them.
The whole idea is that it will prompt you if the computed confidence level isn't high enough. If you've been working away for awhile, the confidence level would be high and commands would be executed directly. If you just logged in, you'd be prompted for additional confirmation for privileged commands until the computed confidence level was high enough for those commands to be executed without confirmation. Presumably knowing secret passwords would rapidly raise that confidence level.

[ Parent ]
Interesting addition (none / 0) (#11)
by adamsc on Thu Jul 06, 2000 at 11:43:33 PM EST

In addition to requiring additional confirmation to execute privileged applications (or make privileged API calls), one interesting addition here would be some sort of interface with a biometric system to determine the user's alertness. Something that measures the eyes' blink rate might work. This could be used for additional confirmation for dangerous commands, possibly at the application level. It could be as simple as automatically turning on -i when using rm -r.

one for all funtions.. (none / 0) (#12)
by martin on Fri Jul 07, 2000 at 05:00:35 AM EST

A system I've seen that works quite well is one smart card for ALL functions, building access, coffee machines, restaurant services and computer authentication.

This means that if you leave your desk you'll take the access card with you and lock the computer.

Admin nightmare (none / 0) (#13)
by jabber on Fri Jul 07, 2000 at 09:44:59 AM EST

It's a nice idea, especially as ubiquitous/pervasive computing spreads into the general public. But it sounds like an absolute nightmare to administrate.

Every command, operation and type of interaction needs to be validated. Each one needs to be configured in advance. Every one may need to be set differently on different systems, even on the same network, depending on the level of exposure of that system to the 'cruel world'. The degree of authentication needed for anything could vary dramatically depending on which side of the door you are on, or whether you have your thumb on the scanner or not.

It sounds incredibly complex to realize, and I don't quite see how it offers a significant advantage over the current scheme. You could just have different levels of point-of-entry identification, which layer user ability within the system. What does dynamic adjustment buy you on the way down the capability ladder? Going up is pretty clear, you want to su -root and you have to provide some identification as collateral - fine. Making it transparent is nice. But if I understand correctly, your scale slides both ways.

Ultimatelly, what's this buy you besides user convenience, to make it worth the hefty cost of implementation. (Oh gawd! I sound like my manager...)

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Backwards compatible? (none / 0) (#14)
by 3than on Fri Jul 07, 2000 at 11:56:34 AM EST

This seems like a LOT of overhead, and the only things that it really helps with are the sort of slips that shouldn't be made. Why would your fictional sysadmin get up from his computer and leave himself logged in as root? Why wouldn't he leave a user account with only normal privileges open, and if it's that sensitive, then a password-protected screensaver.
The other problem is that it seems like it would open many points of entry. All of these services are going to have to have intense, root-level access. If they're not totally secure, they're going to be opening up holes. And although these biometric methods are "highly accurate," it seems like they could be easily fooled. What if your keystrokes got sniffed, and then they get simulated by a remote user? That user would start off with a higher level of access than under a current system, even if your passwords hadn't been compromised. It just seems problematic in many ways, although ambitious. Although it would be cool for security to be transparent, that takes away your ability to choose your current security level. I'm not going to want to be able to do root-level stuff without deciding to be root, in addition to proving myself root. I like the ability to keep myself at user-level, so I can't mess important configs up when I'm just looking at them. I'm sure systems like this will exist sometime, but let's face the fact that they're a long way off, for a number of reasons.

An alternative access control system | 15 comments (12 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!