Star Trek v0.001
Dilbert author Scott Adams' admonition that engineers are easily distinguished by, among other signs, their affinity for Star Trek is the result of flawless analysis and observation. While the world of Star Trek, in which even engineers can occasionally make out with aliens, is hardly around the corner, there is an interesting step in that direction: specifically, the invention of a form of teleportation.
Based on Bell's Theorum / EPR (Einstein Podolsky Rosen) "entangled photons", researchers at the University of Geneva have achieved quantum teleportation.
The value of this achievement is evident, as it avoids the issues of duplicating photons for lengthy transmissions, making quantum cryptography a more practical approach. Remember that the value of QC involves the fact that observing the data contained in the QC stream is a detectable event that destroys the content. The destruction is the problem, because "classical" fiber optic repeaters act as observers. This approach bypasses the issue, allowing a new type of repeater to be designed.
At first blush, it might appear that the repeater would provide an interception point, in which more than one copy could be created (using the article's "fax machine" analogy) but such is not the case, since the originating bit is destroyed after the first duplication. A more complete, if not practical, analogy might be a fax machine with a shredder on the document feed output.
Now, we get to the limitation. The process is only capable of transmitting over "short" distances of several hundred kilometers-- insufficient for our global economy. To overcome this issue, these teleporters would have to be strung together. In order to make this technology practical, quantum memory would be required. Trouble is, nobody knows how to make that yet.
So, for now, Star Trek is still in the early prototype phases. Teleportation, v.001, joins Warp Drive (think Alcubierre) v.002. Still, the future is quite rife with possibility. Who knows? Maybe my engineer progeny WILL one day be able to make out with aliens.
Nothing New, Again
In my first "Nothing New" post, I mentioned several areas of continuing development. Two of them, which I will refer to as "alternate contact" and "service specification", might just have a common solution.
The weakness of asynchronous specification appears to be managed quite well by BPEL4WS. Further, bringing BPEL into the picture also allows the specification of alternate contact means, such as telephone. By expanding the number of contact points available, the reliability of the protocol is improved; for a successful compromise to continue, the interceptor would have to have access to each available access point.
As mentioned earlier, it is entirely possible to have more than one set of parameters in the initiation request allowing for the possibility of such specifications as "for any transaction over $250, verify key with trust agent", "every 7th request, use the alternate method...", "every day inform me of the number of requests received by alternate method...", etc. Such rich semantics allows for arbitrarily complex protocols to be developed based on agreement.
Placing the BPEL specifications inside of a larger business process could be used to provide a context in which the service provides value, in effect describing a "suggested use" that could be used by tools such as Microsoft's BizTalk Server to quickly build a prototypical implementation.
Well, that's enough for now. This is interesting stuff, at least to me. I'm sure I will have something more to say in the future. 'Til then....
Patently Unclear
I have brewed, in wetware, a design for a physical device that behaves similarly to certain critical aspects of public key cryptography. "Why on earth," one might ask, "would you waste time on such a thing!?" It does seem perplexing, even to me, though it has something to do, unavoidably, with how my brain works.
The problem, you see, is that I was curious about the impact of a patent that physically realized what was previously considered a software concept. Since I could, barring a catastrophic bus fault, realize this wetware model in the more concrete form of a patent, it seemed like a good place to start. Despite having achieved the subgoal, the machine has not settled into a final state.
There are a lot of interesting issues at work. The most obvious is that "software patents" are not internationally recognized, whereas physical mechanism patents are. Therefore, internationally speaking, my "invention" would be valid. But what effect would their validation have on the related "software patents"?
It would be easy to avoid reference to those patents in mine, since mine is physical in nature. I would simply define what it achieved, and how it achieved it. An interesting, if not practical, physical security device. Pretty "original", that, possibly with no "prior art". Further, it could be used as a component of higher level "inventions", built on similar physical realizations of their concepts, which would also be valid. Could this resolve the international dispute, at least for this area of work? Could this lead to a whole practice involved in the physical realization of software concepts in order to legitimize international patent claims? Could this dramatically expand the number of patents issued, effectively requiring two realizations in order to protect the actual property?
The only sure answer I have to these questions is that it could undoubtedly lead to an increase in the number of patents. Hazarding a foray into concepts best discussed in my other blogs, I will provide as evidence of this fact that, by implication, this would increase the income of patent attorneys.
With that, for now, I leave the concept behind. Intellectually interesting, but of no real value to me. Hmm. Perhaps the machine has settled, after all.
Nothing New Under the Sun
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.
