Application and Firmware Signatures in the .NET Micro Framework

To make life easier for you we have changed the way we deal with firmware signatures on Meridian/Tahoe.  All 3.0 releases (including beta releases) will NOT be signed.   Keep reading for an explanation, but first lets look at how you prepare a Tahoe board with existing firmware for updating.

1. Download MeridianFirmwareKeys.zip and unzip this file

2. Start MFDeploy (provided as part of the tools with the Microsoft SDK) and connect to your Tahoe board using USB 

3. Select Target->Manage Device Keys->Update Device Keys from the main menu

4. Select Firmware Key from the Public Key Index list

5. Enter the path for the MeridianFirmware.key file as the Old Key

6. Enter the path for the Empty.key file as the New Key

7. Click OK.  The Tahoe will reboot.  Close MFDeploy and run the update application.

If you need to put an old version of firmware back onto the board, you use the same procedure as above, but set MeridianFirmware.key as the new key.  (When you do this, you don’t need to specify an old key) 

 

And now for the reason why we are doing this…  It turns out that signatures in the .NET Micro Framework don’t work quite as you would expect!

There are two signatures that you can set in a Micro Framework device:

1. Firmware signature

2. Application signature

With a firmware signature in place, you cannot update any of the firmware files unless they are signed by a matching key.   Previous releases were signed with a the MeridianFirmware key.

Application signatures work in a similar way, and protect application code.  HOwever this is a catch…   Because Visual Studio does not support signatures during application download/debug, the type of build we do for Tahoe does not actually check an application signature that you put into your board.  You need to get an RTM build from us in order to enable this protection.  

Having to change between the development build and RTM build becomes a problem when you don’t have control over the signatures, which is why we have decided to remove them from the firmware we release.   It will be up to you to set both the firmware and application signatures.   We hope this will give you the best of both worlds – flexibility during development and security once your product has been released!

Leave a Reply

3 Comments on "Application and Firmware Signatures in the .NET Micro Framework"

Notify of
Sort by:   newest | oldest | most voted

Paul,

It sounds like you may have a pre-2.5 version of firmware. This will need to be updated using the Boot-Recovery version from this page: http://devicesolutions.net/Support/Downloads.aspx.
Once you have 2.5 in the Tahoe, you can change the keys and load in the 3.0 beta.

You should also make sure you have the Tahoe plugged directly into your PC, and not through a hub as this can mess with the communications during download.

Please post on the support forum (http://devicesolutions.net/Support/Forum.aspx) if you have any more problems.

I have a board that worked wiht MF 2.0,but had not used it in a while. I’m trying on a new mahcine wiht the 3.0 beta. some qustions: The Tahoe 3.0 SKD did not have a USB driver ( did i miss it?) so I used the one that is part of the 2.0 SDK Once USB driver was installed it showed up in MFDeploy just fine but the Update Device keys borught up an error dialg thath said “device has old or unsupported configuration” other patches needed? when the board powers up is says “Loader 2.0” before starting the… Read more »

[…] the explanation at their blog. The first firmware updates for the Tahoe board are expected for mid-August. Published Tuesday, […]

wpDiscuz