Security is an area of knowledge that provides endless fascinating problems for the logician in me to mull over. One of the ones that has struck most recently involves the effects of key compromise. As public key cryptosystems and their associated protocols begin to dominate the landscape, the impact of key compromise will become dramatic. This area of security has not been investigated as thoroughly as others, enhancing the risk further. If a compromise ever were to happen, the impact on internet based commerce could be significant. How can we mitigate this threat before the landscape is rife with opportunity for the criminal element?

Flashback: quite a while back, I designed a system which I called SecureComm. This system enhanced the security of modem connections through a variety of mechanisms, including callbacks and traffic analysis. The purpose of these enhancements was to verify the identity of the caller in such a way that mitigated the risk that they were not who they claimed to be. In the case of a phone connection, calling back to a known number was helpful, but not preventative, since an intercepted phone line could result in the same behavior. Traffic analysis, in the form of "is this call and content in line with our expectations, based on who the caller claims to be?", further helped ensure the authenticity of the claimed identity. Nothing here was capable of absolutely ensuring that a key compromise had not occurred; such a protocol might very well not exist. Still, anything that could improve the probability was helpful.

So, quite simply, I am proposing a SecureComm mechanism for today's internet commerce environment. Specifically, web service based requests. What does this mean specifically?

Callbacks are easily implemented, though their specification as a web service can be a bit tricky. Still, despite the fact that none of the extant models appear to completely cover the possibility, the concept is easy enough to understand. A service provider specifies their services, including initiation and execution interfaces. The initiation interface (called once when a requestor wants access to a callback web service) requires that the invoker specify an entry from a provided list that shows what web service they are standing up to respond to the service execution request. When the requestor makes a call to the execution service, they are only told that the request was understood-- no actual request result is provided, and the connection is broken. The provider then calls the service specified by the requestor during initiation, providing the result.

What have we achieved? Assuming all the messages are signed, the requestor cannot deny that they made the request-- it has their signature, after all. But if they did not actually make the request, a compromise event is indicated. To prevent this detection, the compromiser would have to intercept the response service call from the provider to the requestor. Not an impossible task, but a much more difficult one.

Once the compromise event is detected, the requestor can begin the process of key revocation. In order to maximize the effectiveness of such revocation, we can add parameters to the initiation process that specify how often the key's status should be checked against a trusted agent; this provides us something akin to SecureComm's traffic analysis function. As requests are received, if the parameters specified in the initiation request are triggered, the provider (prior to processing the request) checks with the trusted agent to verify the key's integrity.  Based on the relationship between the trusted agent and the assumed requestor, the agent may initiate another validation service with the requestor, and use the response, or they may just check the key's status in their data store.  In either case, if a compromised key is indicated, the provider can remove initiation information from their service for the requestor, and callback the requestor service to inform them of this result.

Well, I've certainly said a lot, some of which hopefully makes sense. There are lots of interesting interactions in here that I am continuing to reflect on. For instance, the ability to "stack" validation parameters can result in an escalated trust system. The ability to specify callbacks that are not web service based can enhance the security of the protocol by increasing the challenge of interception. Stay tuned, if you care: someday soon I might just move some of those ideas forward.  I might also more formally specify the information in this post (in fact, that work has already begun). If / when that becomes available, I will post that document as well.