RE: [kmip] KMIP and banking-oriented key management

We need to be careful of trying to accommodate every example of every piece of financial crypto APIs we’ve ever seen in the field. Some people on the list will be familiar with the huge amount of regional customization associated with financial crypto and we’d have a vast amount of work to do.

On the key roles and attributes would it be a reasonable first step to look at what’s supported by the Interoperable Key Block TR-31 and make sure all of that is covered?

I agree that in addition to roles we need to add more security principals to this: decimalization tables and allowable input/output PIN block formats spring to mind as crucial security benefits that I have engineered in financial products. But let’s start with the Interoperable Key Block and see where it gets us.

I’ll try to put something out next week.

Regards,

Jon

Jon Geater

Director, Technical Strategy

THALES Information Systems Security

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

T: +44 (0) 1223 723604

T: +44 (0) 7786 622256

E: mailto:jon.geater@thales-esecurity.com

W: www.ncipher.com

From: Todd Arnold [mailto:arnoldt@us.ibm.com]
Sent: 10 June 2009 19:41
To: kmip@lists.oasis-open.org
Subject: [kmip] 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:

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

kmip message