KMIP and Banking-Oriented Key Management

By: Todd Arnold (IBM)

Robert Haas asked me to write this up before tomorrow's KMIP call [2009-06-11].

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 management for banking applications has some special issues that are somewhat different from other more generic key management. 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 management 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
Tel: +1 704 594-8253
FAX: +1 704 594-8336
Email: arnoldt@us.ibm.com

Memo Source

URI:        KMIP TC List Archive
Date:       Wed, 10 Jun 2009 14:40:30 -0400
From:       Todd Arnold <arnoldt@us.ibm.com>
To:         kmip@lists.oasis-open.org
Subject:    KMIP and Banking-Oriented Key Management
Message-ID: OFD2BAB659.4D4F24B8-ON852575D1.005DA44D-852575D1.0066910C@us.ibm.com

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	KMIP and Banking-Oriented Key Management KMIP and Banking-Oriented Key Management By: Todd Arnold (IBM) Robert Haas asked me to write this up before tomorrow's KMIP call [2009-06-11]. 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 management for banking applications has some special issues that are somewhat different from other more generic key management. 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 management 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 Tel: +1 704 594-8253 FAX: +1 704 594-8336 Email: arnoldt@us.ibm.com Memo Source URI: KMIP TC List Archive Date: Wed, 10 Jun 2009 14:40:30 -0400 From: Todd Arnold <arnoldt@us.ibm.com> To: kmip@lists.oasis-open.org Subject: KMIP and Banking-Oriented Key Management Message-ID: OFD2BAB659.4D4F24B8-ON852575D1.005DA44D-852575D1.0066910C@us.ibm.com Prepared by Robin Cover for The XML Cover Pages archive.