OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: KMIP and banking-oriented key management



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:
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]