Permissions on the edge

Managing digital rights is one of the nastiest problems bedeviling any security architecture. Multiply the number of secured objects by the number of ACL (access control list) entries and you get a number you'd rather not contemplate. Big matrices of objects and permissions are so unwieldy that some say we should avoid creating them in the first place.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

In a speech he gave last year to the Security Industries Middleware Council, Dan Geer, CTO of @Stake, famously remarked that ACLs don't scale and then proposed accountability as an alternative that does. "The only reason a free society works," said Geer, "is that you can pretty much do anything, though if you screw up badly, we will find you and make you pay." Given that our ability to comprehend big matrices holds constant while storage capacity and CPU power keep growing, Geer suggests that passive surveillance and data mining can achieve what active policy cannot.

Even if you buy that argument, though, you're not off the rights-management hook. Some acts must always be prevented, not just punished; and some people must always be exempt from those prohibitions. It's hard to state these rules and harder still to update them as secured objects and roles vary from day to day. PKI (public key infrastructure) offers some solutions, but not very good ones.

Consider, for example, the mechanisms for revoking a digital ID. As an experiment recently, I revoked one of my own just to see how the e-mail clients that check it would react. Results were mixed. Outlook didn't complain, but Mozilla correctly did. That doesn't bode well for a hypothetical antispam measure that would reject messages based on invalid signatures.

My test only exercised the most basic mechanism, the CRL (certificate revocation list). Even had it worked flawlessly, it wouldn't be a solution. No application could be expected to haul in a million-entry CRL. Thus was born the OCSP (Online Certificate Status Protocol), which enables a client to ask a server to validate a certificate in real time. Great, except now the OCSP server has to be always accessible and do lots of heavy crypto on the fly.

The inevitable next step was to distribute the work, and CoreSteet's D-OCSP (Distributed OCSP) does just that. Its system periodically computes "proofs" — small, time-limited validity tokens — and pushes them to OCSP responders at the edge of the network. The tokens contain no secrets, they merely assert facts about an identity that's established by password, PIN, or some other means.

Other applications of the same technique push beyond the edge of the network. CoreStreet has just signed a deal with Swedish locksmith Assa Abloy that will enable doors to enforce highly granular card access policies without wired (or wireless) connections. When an employee swipes a card at the main entrance, it's refreshed with a daily set of proofs. The door need only check that the proof binds a resource (itself) to an identity (the employee) at a certain time (today).

CoreStreet's president, Phil Libin, sketches another interesting scenario. Suppose an employee needs a proof to access her own laptop but can't contact the network. Since proofs are minimally just 20 bytes, it's feasible to convey one in a phone call.

We'll always have to manage permissions centrally. But CoreStreet's method of distributing them to the edge of the network — and beyond — strikes me as an excellent way to tackle a thorny logistical problem.