----- "Victor Duchovni" <victor.ducho...@morganstanley.com> wrote:
> 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. > So this means that I need to decrypt a key using a public key encryption mechanism. I still only want to run in my microprocessor's authenticated mode which means I need to decrypt the key in a code space of around 32 KB. Does anyone have suggestions for a small footprint, public-key decryption source code library? ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
