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

Todd -

 

Would it be possible to support these through the 
Application Specific Information object?  

 

Through the use of that object as a generic object with 
a type, lets the application recast it to what it wants/needs.  Then the 
content of the object can be anything you need.  This method can also let 
an application use multiple instances of an item within a single 
object.

 

- Peter

From: Jon Geater 
[mailto:] 
Sent: 2009-06-11 11:04 
AM
To: Todd Arnold; 
Subject: 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:

W:    
  www.ncipher.com

 

 

From: Todd Arnold 
[mailto:] 
Sent: 10 June 2009 19:41
To: 

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: 
  

nCipher Corporation Limited is incorporated 
in England and Wales with company registration number 3169278. Its registered 
office is located at Jupiter House, Station Road, Cambridge, Cambs, CB1 
2JD.

The information contained in this e-mail is confidential. It may 
also be privileged. It is only intended for the stated addressee(s) and access 
to it by any other person is unauthorised. If you are not an addressee or the 
intended addressee, you must not disclose, copy, circulate or in any other way 
use or rely on the information contained in this e-mail. Such unauthorised use 
may be unlawful. If you have received this e-mail in error please delete it (and 
all copies) from your system, please also inform us immediately on +44 (0)1223 
723600 or email . Commercial matters detailed or referred to in 
this e-mail are subject to a written contract signed for and on behalf of 
nCipher Corporation Limited.