Tales from the crypto: Whispers foretell of a new security app
The scariest thing about electronic security is that it doesn't exist. Sure, many agencies go to great lengths for it. But there just hasn't been any practical way to implement electronic security on a widespread basis within single, network-distributed or Internet applications. It's sad to think we can achieve electronic security only on a standalone machine in a screened room with no windows or doors.
The scariest thing about electronic security is that it doesn't exist. Sure, many
agencies go to great lengths for it. But there just hasn't been any practical way to
implement electronic security on a widespread basis within single, network-distributed or
Internet applications.
It's sad to think we can achieve electronic security only on a standalone machine in a
screened room with no windows or doors.
But that could be changing.
My sources say a leading software company is furiously at work on a cryptographic
application programming interface known as CAPI. CAPI probably isn't the final answer, but
it could build the momentum needed to develop a workable security solution.
CAPI would define the services required by an application for its cryptographic needs.
So far, about 25 basic cryptographic services have been defined--the easy ones like
"establish key" and "encrypt." Missing so far are things like support
for non-blocking calls to the crypto modules.
For that, the crypto details and crypto keys must be hidden from the applications.
Also, there has to be an easy way to switch from weak "export-approved" crypto
to strong "real" crypto by switching to another Dynamic Link Library at load
time.
Success therefore hinges on the crypto modules in use at run'20time.
To implement the scheme on popular desktop platforms, The CAPI would have to become
part of the operating system's programming interface to hide the crypto details. And the
operating system would have to support loading Cryptographic Service Provider (CSP) code
with crypto functions below the API.
We can expect to see this happen in coming upgrades to operating systems that support
the proposed standard.
I understand there soon will be a beta version of an application development kit for
writing code that uses CAPI, plus a beta version of the CSP development kit for writing
code to implement crypto functions. As kits become available, we will get a better idea of
its functionality and practicality.
According to agencies that deal with such matters, the scheme is called "crypto
with a hole" because the applications call a crypto API. Crypto with a hole always
has been export-controlled, as have the crypto functions themselves.
There are encouraging signs that the government will allow export of such applications
as long as buyers don't try to implement crypto on their own.
But the catch-22 is that the company that sells the operating system would have to sign
off on all the CSPs.
The operating system wouldn't load just any old CSP. The OS kernel would contain an RSA
Data Security Inc. public key to check the signature when a user tried to load a CSP. If
the signature check failed, the CSP wouldn't load.
You or I couldn't compile crypto code as a CSP, even for our own personal use, without
getting the OS company to sign off on it. And if that company made a business decision to
set charges once it owned the process or decided not to sign off on any CSPs written by
competitors, we'd be out of luck.
Maybe that's just my cynical view, but I think the only way this scheme stands a chance
of success is by remaining free and open to many CSPs. Charles S. Kelly is a computer
systems analyst at the National Science Foundation. You can e-mail him on the Internet at ckelly@cpcug.org. This column expresses his
personal views, not the official views of NSF.
NEXT STORY: EBT cards for food programs get smarter