On Wed, Nov 04, 2009 at 10:33:02AM -0600, Doug Bailey wrote:
> I would like to use this capability so that an authenticated program on the
> microprocessor is used to decrypt an image that is downloaded to my system.
> Due
> to code space and size limitations, my first thought is to use an AES
> symmetric
> cipher where the key for the cipher is held in the space where only the
> authenticated program has access.
>
> The scenario would be as follows:
>
> The AES key is programmed into the secure PROM during factory configuration
> When operating in the field, an authenticated program would download an
> encrypted module to the unit
> The authenticated program would then decrypt the download using the key stored
> in the secure PROM.
>
> Are there any glaring flaws in this approach?
Generally it is a bad idea to hard-wire data-encryption keys. Standard
practice is burn-in a "key-encryption-key" (KEK), and each encrypted
object uses a random unique key, with that key encrypted under one or
more KEKs. Each party that needs to access the data, decrypts the
random key via its KEK, and then decrypts the data object.
The KEK need not be symmetric, with smime(1) for example, the KEK is
typically an RSA key-pair, which makes it much easier to publish the
keys necessary to generate content for a particular recipient.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
