Capabilities in usermode

[oscoder]

Hi.

I am currently thinking about how I might implement security in my OS. My mind is pretty set on capabilites, but I would very much like to be able to implement authentication without the use of a central authority (ie in usermode). I plan to used shared memory for IPC, with the protocol used entirely up to the programmer, so it would be... consistent to implement security there. Of course, this raises certain problems:
- How does one process tell another that it has a key without revealing what that key is, and without performing any costly operations?
- How does might security privalledges be revoked from a process?

Of course, I may have to compromise a little. But I would like to be as decentralised as possible.

Thanks,
OScoder

[iammisc]

uhmm... well if the other process needs to know that the other process has a capability, then shouldn't that process know that the capability *is*?

For example(i'm assuming this is a microkernel), my console server has a capability for writing to the console, it knows the capability because it created it. In my microkernel, a program gets a capability from the auth server. It just passes this to the console server which checks it against its copy and if it matches, the call continues, else the call fails.

[Crazed123]

In most capability systems you can't actually verify that you have a capability without sending the capability itself to whomever to which you want to prove your possession. Something called "split capabilities" will allow such proofs.

Also, capability systems provide no real way to revoke a capability, especially if a random block of user-land data can be a capability. However, you can create an object which simply forwards all messages (or function calls, whatever you use) through a capability it holds until it receives a special call, upon which time it deletes its capability. You create this object and pass the capability to it (with whatever authorities you like) to your client. The client communicates through the forwarder object, and when you want to revoke access you tell the forwarder to delete its capability.

[oscoder]

Hi,
I've found a way of solving the problems (speed, revokableness and key-checking), but it relies on an idea I'm not sure of. It'd be great if someone could have a look at it and see if there is a way to break it! It goes as follows and is based off the Diffie-Hellman-Merkle key eschange scheme:

- Where process B wants to tell process A that it has key k, n and m are primes (not sure if this is nescessary) and O() is a one-way function
- Processes A and B create random numbers a and b respecively
- They then send the values m^a(mod n) and m^b(mod n) to each other (known respectivly as c and d)
- Process A stores the result of d^a(mod n), and B c^b(mod n) - the results should be the same (known as e)
- Process B then sends O(k+c+d+e)
- Process A can verify this, as it knows k, c, d and e

I'd appreciate your comments,
OScoder

[Combuster]

Since you're executing a diffie-hellman key exchange, so the problem is not with the algorithm. However, computing large exponents is most certainly not fast, and the problem of using small exponents is that these are unsafe. Having to compute the hash O(x) for each subsequent message isn't going to add to the solution.

Best thing is to look for a way to ensure messages will go only where you want them to go, after which you can just send the messages plainly (if someone can hijack the receiving end, there's no security measure to prevent information leakage as that process will have access to all keys as well)

[oscoder]

What about if I where to perform the authentication once per stream (ie when the connection is opened). It could be a kind of compromise - the process proves that it has access to a keyspace, and the recieving one can then check if that key space contains the keys required for whatever opperation. Of course, this might require a key server to manage key spaces but that would not be too bad!

Thanks,
OScoder