OASIS Key Management Interoperability Protocol (KMIP) TC

Robert Haas asked me to write this up
before tomorrow's KMIP call.

As I have discussed with a few people,
I have concerns about KMIP and its ability to provide the features needed
in banking-oriented key management.  Others in ANSI X9 are also concerned,
and they have asked me to act as a liaison between the two groups.  Key
mgmt. for banking applications has some special issues that are somewhat
different from other more generic key mgmt.  For example:


Requirements are governed by standards
such as those from ANSI X9.  These standards have very stringent and
precise requirements, and they are very difficult to change because of
the standards themselves and because of the large set of equipment and
software that is in use and must operate together.  In many cases,
key mgmt. techniques and hardware-related security requirements that are
acceptable elsewhere are prohibited in the banking applications world.
The key types required in banking applications
are much more specific than in generic applications, and in many cases
they have no analog in non-banking applications.
Each hardware HSM vendor has their own
proprietary API and cryptographic architecture for their own way of meeting
the security requirements in this area.  In particular, the key typing
and key usage approaches are quite varied, and some are much more complex
and granular than others.  It is difficult to allow all of these to
use KMIP with the very simple and limited set of financial key types that
are currently defined.

In the KMIP spec, this is the
only information I saw that is related to management of banking-oriented
keys.



First of all, I have a serious problem
with the lack of detail in the description of uses for these keys.  They
are defined in terms that may be clear to some people, but certainly are
not clear enough.  I work in this field, and could not tell you exactly
what some of these roles mean in terms of the functions the key can really
be used for, or the standards they apply to.  This is especially true
of the "Master key for..." roles.  The term "master
key" has vastly different meanings in different implementations, and
it's not clear what the term really means here.  I would like to see
very clear and precise definitions on exactly what each of these key types
can be used for, in generic terms and not using words related to any particular
implementation or product.

Secondly, this is a very small set of
key types for these applications, and it certainly does not allow all vendors
to support the types or granularity of keys that they have in their crypto
architectures.  I realize that these roles are used in conjunction
with the Usage Mask which can further restrict, for example encrypt only
vs. encrypt/decrypt.  

Let me cite some concrete and fairly
simple examples.  Let's just consider keys used in PIN operations,
which are one of the major financial operations.  In the roles above,
the only PIN-related roles I see are these:
ZPK - to encrypt a PIN block.
PVKIBM - to derive PINs checked
with the IBM offset method
PVKPVV - to verify PINs using
the PVV method

This is too limited a set.  To
cite a concrete example I am familiar with, our IBM CCA crypto architecture
currently has types for PIN generation/verification keys for five different
methods, not just the two (IBM offset and PVV) available in the KMIP roles
- plus CCA also has a type that can be used with any PIN method.
 It does not seem reasonable to make vendors use "extensions"
for so many things.  There are further restrictions for keys that
allow PIN translation where the PIN block is simply reenciphered with a
different key, and separate options for keys that will also allow you to
change the format while you are reenciphering.

There are many, many other examples
of key types that exist in current HSMs but cannot be represented with
the key types and usage currently in KMIP.

I noticed one other thing that is very
important, but which I don't think you can do under KMIP.  Symmetric
keys often come in matched pairs, where the two keys have the same value
but have different attributes.  An examples would be MAC keys where
one can be used for generation or verification, but the other can only
be used for verification.  Another would be key-encrypting keys where
one copy can only be used to export (wrap) and the other copy can only
be used to import (unwrap).  Symmetric key pairs like this are critical
to security in systems like banking, but I see no secure way to create
them under KMIP.  It only seems to have a function to generate a single
copy of the key with whatever attributes are specified.  What is needed
is an atomic function that generates two copies of a symmetric key, each
having different attributes (with reasonable controls so they are matching
pairs).  It is not sufficiently secure to try and accomplish this
by creating a key, then creating a copy and modifying the attributes -
that lacks the necessary security controls.

Finally, the banking standards have
strong requirements that keys be protected at all times by an SCD (Secure
Cryptographic Device, often called a TRSM).  This means something
like an HSM or a secure POS terminal.  The keys cannot ever be in
plaintext or in any form where plaintext could be recovered, unless they
are protected within secure hardware.  I think it would be very useful
in KMIP to have an attribute that says "this key must be protected
by hardware".  (Although you would still be in trouble if someone
could modify a software-based system to ignore that attribute.)

- Todd


-------------------------------------------------------------------

Todd W. Arnold
Senior Technical Staff Member  (STSM)

IBM Cryptographic Technology Development

(704) 594-8253   FAX 594-8336

-------------------------------------------------------------------

email:  arnoldt@us.ibm.com