Using openssl for AES encryption

[Doug Bailey]

I have a system where I have a microprocessor that has the ability to hold data
in PROM memory that is only accessible when the program running it has been
authenticated.  (This is done using ECDSA.)

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?

What is the best way to generate an AES key to use for this scenario?

Thanks for any help,
Doug Bailey
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Victor Duchovni]

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@...
Automated List Manager                           majordomo@...

[Doug Bailey]

----- "Victor Duchovni" <Victor.Duchovni@...> 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@...
Automated List Manager                           majordomo@...

[Victor Duchovni]

On Wed, Nov 04, 2009 at 02:26:47PM -0600, Doug Bailey wrote:

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

You don't "have to use" a public key algorithm, but that would be best
practice. Otherwise the systems that generate encrypted content need
all the device (symmetric) keys, which are presumably somewhat sensitive.

You can use symmetric KEKs, but then (just as you would with a
non-ephemeral symmetric DEK) you have to store these securely in a lot
more places, which is often difficult.

> Does anyone have suggestions for a small footprint, public-key
> decryption source code library?

I don't have any experience with small footprint devices, hopefully
someone else can recommend a suitable library.

I know that http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ is well
reputed as a high quality crypto library. If it supports your device
footprint, you may do well to consider it.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...