Crypto APIs

[Matt Blaze <mab@crypto.com>]

A couple of weeks ago I attended a meeting at the NATO SHAPE Technical
Center in the Hague to discuss international cryptographic APIs.  Several
high-ranking NSA types were there, as well as their counterparts from
various NATO countries plus a handful of industry crypto people (like
me).  The idea of the meeting was to find a way to separate
cryptographic function from cryptographic interfaces, in a way that
allows the applications that call the cryptographic functions to be
more freely exported.  That is, I can write and export an application
that calls the crypto API but that doesn't actually implement the
cryptography, and then, when it reaches its destination, the
locally-preferred cryptosystem can be plugged right in.  Crypto might
be implemented in hardware (e.g., Fortezza) or software (e.g., with a
shared library or pseudo-device driver).

Obviously, this idea is somewhat (completely?) at odds with the
criteria presented at last month's NIST workshops for exportable
software key escrow systems.  One of the requirements given for such
systems is that it be difficult to replace the crypto with something
that doesn't implement key escrow.  But who ever said the government
was consistent?  Interestingly, it was clear that many people in NSA
believe that applications that call an API are controlled under ITAR,
but there is some recognition that this may be wishful thinking or may
change soon.  So while some (maybe most) of NSA wants to prevent
development of standard APIs and prevent the export of applications
that use them, others recognize that these will evolve by themselves
anyway and will be very hard to control once they do.  Anyway, the
situation is far from clear.  It seems best to encourage the realistic
side of NSA as much as possible...

I learned a few interesting things at the meeting.  First of all,
overwhelmingly, there is recognition, especially on the part of the
non-US government security agencies, that there is enormous value in
being able to buy off-the-shelf applications like Microsoft Word or
Netscape Navigator and just plugging in the local military cryptosystem
and using it for classified traffic.  Everyone seemed to agree that
there is a growing need for this and that it's too expensive to rely
on custom software.  There is also movement away from the traditional
military ``link encryption'' approach that involves centrally-
controlled secure networks in favor of a ``risk management'' approach
that favors end-to-end security with off-the-shelf products.  In other
words, the parts of the military that are concerned with actually
securing communications want exactly what we want, and are just
starting to realize it.  While lots of us have always known this, I
had never heard it articulated as quite clearly (or as loudly) by
actual comsec/infosec people before.

Second, the senior NSA guy mentioned a few things I hadn't heard
before.  Fortezza is now approved for classified traffic through the
SECRET level.  Also, the ``type 1'' (classified) through ``type 4''
(unevaluated) cryptography standard is being scrapped in favor of a
three ``tier'' system, as follows (these are approximate quotes, from
my rough notes):

Tier 1 traffic is stuff related to ``national command authority''.
(Seems to be secret and top secret and up).  It will require NSA
cryptosystems, hardware implementation, and will NOT employ key escrow
(because of the ``obvious risks''!).

Tier 2 traffic is information that, if disclosed, would have
``national implications'' if revealed.  Examples given include things
like the national power grid, the banking system, etc.  It was
unclear whether any classified traffic would be included in tier 2.
Clearly, some of what is now called ``sensitive but unclassified''
(SBU) will be in tier 2.  Anyway, tier 2 systems will be approved by
NIST (not NSA, although there will obviously be NSA input into the
standards) and will require hardware implementation.  Tier 2 traffic
will be escrowed, and the government will escrow its own keys.
Fortezza is an example tier 2 device (but read on...)

Tier 3 traffic will be that which would have ``private implications''
if disclosed.  Examples given included personal financial and medical
records, etc.  Current SBU traffic not in tier 2.  Tier 3 would also
be handled by NIST, employ commercial or government key escrow (like
tier 2) and would be permitted to be implemented in software.

Here's the surprise: Tiers 2 and 3 will be interoperable.  So there
will be published algorithms for tier 3.  It is possible that tiers 2
and 3 will have the same algorithms, and that the government will
suggest them.  It was unclear with interoperability will require that
all tier 2 algorithms will be published and implementable in tier 3
software or whether this means that tier 2 devices will also have to
implement the tier 3 algorithms.  There is an obvious choice of a tier
2/3 algorithm: Skipjack (although there were concerns that this is
``too slow'').  So we may eventually find out whether ``S1'' was
really Skipjack after all....

-matt