Subject: [ietf-tls] Last call: AES ciphersuites for TLS

From: "Todd Arnold" <[email-masked]>
Date: Mon, 23 Jul 2001 10:11:55 -0400

I was just made aware of the discussion going on here, so I'm catching 
up.  I have a number of comments on some of the recent issues people 
have posted.  For background, let me state that I am a designer of IBM 
cryptographic hardware products, like the 4758 card (see 
http://www.ibm.com/security/cryptocards) which is used in all of IBM's 
server platforms from the largest (mainframes) to the smallest 
(PC-based). 

I see that Peter Gutmann, who has worked with the 4758 in IBM 
Research, has also provided some information about this. 

> I have an additional issue. Crypto hardware with some form of private
> key protection will have varying degrees of difficulty with OAEP. How
> bad this is depends on the hardware in use and I don't claim to be
> familiar with all variants. 
> 
> However typical issues might be:
> 
> 1. The firmware cannot be upgraded and it only supports PKCS#1 v1.5
> internally. 
> 
> 2. Upgrading the firmware can only be done if the existing hardware
> protected keys are destroyed.

Neither of these is true with the IBM 4758.  The firmware can be 
securely upgraded (in fact, the mechanisms are part of what received 
FIPS 140 Level 4 validation by NIST).  Furthermore, you can upgrade 
the firmware in a way that destroys all secret data in the card (if 
you are paranoid), or you can upgrade it in a way that preserves all 
the secret data (which is what most customers choose to do). 

> There's also the possibility of the manufacturer being forced to extract
> keys from boxes via legal sanction. In this scenario the "attacker"
> would be the manufacturer.

We have always designed our products with a firm principle that it 
will be IMPOSSIBLE for us, as the designers and manufacturers, to get 
to any secret data the customer puts in our hardware crypto units.  No 
matter how much the government, or even the customer insists on it, 
there is no way we can get secrets out if you intended for them to be 
protected.  That is a requirement for any of our crypto design. 

> Interesting security policy.  However, it is quite difficult to repair a 

> bug in this situation.  If I had a root key stored in such a device I 
would 
> be quite upset if there was no way to repair a bug in the firmware 
without 
> destroying the root key.

This is precisely the point that drives the requirements for the 
design.  There are standards that REQUIRE root keys to reside in the 
hardware, in such a way that they can never be extracted, backed up, 
or cloned.  People running large businesses with CAs do not want their 
CA root keys to be destroyed because they installed a firmware upgrade 
in order to get some desirable new feature.  (Maybe they want to add 
OAEP support...  :-) ) 

> How upset would you be if your root key became available to an attacker
> because the "upgraded" the firmware?

This is why you need secure code validation and loading procedures. 
If you trusted your vendor not to have a Trojan horse or other 
security hole in the original firmware, and if the code delivery and 
installation process guarantees that the code originated with that 
vendor, has not been tampered, and is reliably loaded into the 
hardware, then you should not have any concern with the update that 
you did not also have with the code it replaces. 

> Right, but imagine that the manufacturer makes two different kinds 
> of firmware, one of which permits key export and one of which does 
> not.  Clearly you wouldn't want the "key export" firmware loaded 
> onto your previously secure box. 
> 
>
> So, now we need some way of differentiating various kinds of
> firmware, which means that you need different hardware, some of 
> which can only run certain firmware. 

It doesn't have to be that complicated.  A single firmware load can 
have all the functions - "secure" and "less-secure".  A highly secure 
integrated access control system (which the 4758 has in its CCA API) 
can then be used by a system administrator to selectively enable and 
disable functions, as desired.  Don't want to allow private keys to 
exist outside the hardware?  OK, just disable the related functions. 
The CCA API on the 4758 supports RSA keys that can never leave the 
secure module, but it also supports RSA keys that can be stored 
outside the module, triple-DES protected under a key inside the 
module.  You can enable either of these, or both, as you desire. 

> You also have downgrade attacks where I replace the current (signed) 
> firmware with the previous (signed, buggy) firmware... 

The 4758 architecture allows you to place all kinds of restrictions on 
where code can be loaded.  Among those are restrictions on what 
versions it will load on top of - so you can prevent loading old code 
on top of newer versions.  (In fact, you can even do things like 
targeting the code to specific cards, by serial number.) 

As an aside...  The ANSI standards committees are discussing future 
key management standards, and are heading to a conclusion that OAEP 
formatting should be used with AES keys.  That is not final yet, but 
it seems to be the feeling of most of the experts who participate.  I 
happen to agree. 

Let me say that I am not familiar with the IETF TLS discussion that is 
the source of this thread, so I appologize if specifics related to 
that standard reduce the relevance of my comments. 

-------------------------------------------------------------------
Todd W. Arnold
IBM Cryptographic Technology Development
(704) 594-8253   FAX 594-1790
-------------------------------------------------------------------
email:  [email-masked]

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]