Genuine Crypto!

[Ian G Batten]

I'm involved in manufacturing some network hardware.  Today, there is  
no requirement to encrypt the management links or provide a means of  
proving that the equipment claiming to be serial number 1234 really  
_is_ serial number 1234.

We have some memory spare in an area of EPROM which is programmed at  
manufacturing time.  Assume for the purposes at hand that it is as  
tamper resistant as is required for the application.  The equipment  
will typically be installed into locked cabinets, and the EPROM  
cannot be written to from the on-board processor, but can be written  
to from an edge connector.

Our thinking is that we should put `some' keymat into that spare  
space, and record it against the serial number.   If then, once the  
equipment is deployed in the field, there is a desire to communicate  
securely, we can download a new firmware image into the program  
flash, and use the unique keymat each board will have in order to  
prove that it's the right board.   The purposes are ill-defined: it's  
just that if we've got tens of thousands of items out in the field  
with no keymat on board, going around and applying it by hand is a  
major cost.

Obviously, we don't need to supply any keymat in advance if all we  
need is confidentiality.  We just download firmware which contains  
the base and modulus for diffie hellman, and off we all go.  Our  
worry is that at that point, if the communications path is already  
compromised, we never find out that we're talking to a fake network  
element.  If we have something unique on each board, we can hopefully  
use that to prove that we're talking to the board we think we are  
(modulo the security of the keymat).

If you had 1024 or so bits available to store `something' that would  
be useful for a rainy day, what would you store?

My first thought was to store just an AES key, either 128 or 256  
bits.  Then once we've downloaded the new firmware, we send a nonce  
value in clear and check that the NE can send us back the nonce and  
its serial number encrypted with that key.   Or we can use it to  
encrypt some initial configuration session.

But the problem with that is that I end up with a huge pile of  
compromising data in our manufacturing system.  So my next thought  
was that I could put an RSA private key in there, and record the  
public key in my database.  In the future I send a nonce, and expect  
to get it back signed.

But if I've only got 1024 bits, is that enough?   And is RSA viable  
using a small PowerPC embedded processor?

The alternative I thought of is Feige-Fiat-Shamir, but I suspect the  
same arguments apply and implementations aren't as widely available.

Any suggestions?  In the absence of anything better, I'm going to put  
1024 bit RSA keys on the boards and record the public keys locally.

ian