Genuine Crypto!

[Peter Fairbrother]

Ian G Batten wrote:

> 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?


Not really, as such - but read on.

 
> And is RSA viable using a small PowerPC embedded processor?

Yes, if you are using it sparingly, ie not to encrypt streams of data.

> 
> 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.

Store 1024 bits of randomness on the EPROM.

Then for instance you can use 256 bits of that randomness as a password
input to RSAKEYGEN to generate a RSA key-pair, and store just the public key
on your computer and the the original 256 bits of data on the EPROM

(the RSA key can be as long as you like, 4kbits seems good, it is not
limited to 256 bits of length - it is limited to 256 bits of entropy, but
that should be well plenty!).

You can store a keyed encryption of another random 512 bits on your machine,
with the 512 bits on the EPROM. Could be useful if quantum computers become
commonplace, although I can't recommend a 512-bit-block qc-proof cipher :(

I don't know what you mean by saying you don't want to store "compromising
data" on your system, but it might be worthwhile to simply store a copy of
the last 256 bits on your system, for eg low security work. Or for use as an
OTP or even a simple shared key - you should know if it has been
compromised.




-- 
Peter Fairbrother