mf4.3 legacy crypto lib

[SytechDesigns]

In mf4.3 in addition to the pk msi there was a legacy crypto msi. If you install the crypto msi, then you get the addition of a lib folder with the various platform crypto libs. If you run the mf4.3pk without installing the crypto libs, what would be the effect? In the normal port the crypto project is just stubs - so does not do anything. In other words what is the crypto lib doing and what would be the effect of it not being installed ( for instance would it affect the mfdeploy ability to read a managed app binary and then deploy that binary to another ( same type) device - would the key authorisation pass? In MF4.4 the crypto lib is not an option - the libs are installed anyway. Thanks

[smaillet-ms]

The crypto libs are optional. Without them TinyBooter and MFDeploy cannot perform secure firmware updates. Nothing else should depend on those libs. The goal is to completely eliminate the closed source binaries in the next major release of NETMF.

[SytechDesigns]

In MF4.3 the dotnetmf.proj in the crypto lib builds the crypto stubs - all functions are as the name implies stubbed and just return success etc. - so these don't actually process any thing. In the TinyBooter application, the only thing that seems to reference crypto is cryptointerface.cpp - which will now just call the stub functions - so doesn't actually do any crypto related things. Also in mf4.3 the crypto project file basically has a conditional include for the crypto.lib - and it checks for 'ARM' and also GCC ( it checks others but only these two are relevant here) -we are using MDK - so neither condition is true, and it looks like it defaults to if libsource !exist then use crypto_stub - so the end result is even if the crypto.lib is there, when you build with mdk you get the crypto stub.lib, which can be seen in the tinybooter.map file as it is only 24 bytes. On mf4.4 the crypto project is modified so it now checks for 'GCC' or 'MDK'. When you compile with this project file, you get the crypto.lib in the image - which is about 11000 bytes. So I am assuming that the binary crypto.lib implements the functions in crypto.h ( hard to tell by inspecting the binary file) - so the implementation for crypto.h is ether the stub project or the compiled third party version binary. The importance of this is the size. With stubs it is 24 bytes, with the actually lib it is 11000 bytes. And this makes keeping tinybooter to less than 48K almost impossible ( if you have some other things in tinybooter) - meaning you cant keep the 16K sector free ( after the 48k sector) for TINYCLR config. You have to assign the 48K and 16K sectors for tinybooter, meaning in tinyclr you need to assing the next 64K sector as config - wasting 48K+ of flash ( important if you are not using a 2M flash chip)

In SM's previous answer -' cypto is only used in tinybooter for secure firmware updates with mfdeploy. Nothing else should depend on these libs'

On testing this out I have found the following ( using mf4.3) With the crypto.lib included - if I create 2 simple managed apps, and deploy each in turn, to a test device using VS, then when each is deployed use MFDeploy to create an application deployment hex. If I create a key with mfdeploy, any combination of trying to install one of the apps, with mfdeploy and this key fails on key validation - however the simple app is still deployed and works after a device reset. If I use the 'blank.key' file in the porting code ( or create an empty key), same happens. If I try and manage the device keys and change it using mfdeploy, this fails - which I cant see how this would work, as the key has to either be in the tinybooter image ( so tiny booter segment would be erased to enable writing the key) or in a config sector, which tinybooter does not have. However, if when you use mfdeploy to deploy the managed app, you just leave the key window blank - don't touch it, then deploy all works as it should!

I repeated all the above tests with a build that used the crypto stub library ( so tinybooter was 10K smaller) and it is the same.

In the MCBSTM32F400 (mf4.4) solution, the only references to any of the crypto.h functions I could find were in open_ssl - So does this mean we do not need the 'real' crypto.lib in the tinybooter/tinyclr image unless we are using open_ssl? ( unless we needed secure deployment of signed files - which I have not been able to get working!) Or have I managed to confuse myself in my testing?

[smaillet-ms]

You don't need the real Crypto lib in any solution (you can use the stubs if you want) The only time you NEED the Crypto lib is if you are using the secured boot and signature check capabilities of TinyBooter. That is the only thing left that uses the CryptoLibs, if you don't need that support you can just use the stub libs.