I had some quick questions about the secure storage area.
1.) This area will be flashed with the app deployment I assume?
2.) Is this area made read-only when the device is locked?
I am just trying to understand how you intend it to be used. If I create the ability to write it in the app code so I can configure it initially, then I’d need a way to make it read only, or I’d have to configure then remove/disable the code to write it. My initial use for it is to store the application key for in-field update, but there are a couple other things I can do with it.
So basically I should create a simple configuration app that has a command set to set up this region over TCP/IP or something, then deploy the actual application code prior to shipping that doesn’t have the tools to access this region.
I think the best would be to make it configurable. If I have to flash an app to set it up in the first place, you might as well let me define the space I need for it. Not sure how hard that would be on your end, but 128 kb is pretty generous for the types of things I would store there. Using 256 bit encryption is only a 16 byte key. I can’t imagine applications requiring 8,000 keys, but I suppose its possible. So, instead of a checkbox that turns it on and off during deployment, can you make it a textbox that takes an int?!
At the end of the day, I think that is the price of security. If the embedded loses the key, then you’ll just have to bite the bullet and replace the module. Good thing you make a socketed version so this is not a hugely expensive endeavor. The alternative, for me at least, is to create some commands that will flash an app using a provided key over a data line. Essentially, these commands just wouldnt be exposed to the outside world and held as secret internally. The likelihood of someone figuring out they exist, considering its all on-die ROM, is essentially non-existent. So, you can recover if the key gets lost.
Is there any way to access this area from PC?
I’ve tried this code:
using GHIElectronics.TinyCLR.Debugger.Management;
using System;
namespace ConsoleApp1
{
class Program
{
private static MFDeploy mfdep;
private static MFDevice mfdev;
static void Main(string[] args)
{
Program.mfdep = new MFDeploy();
var mfports = mfdep.EnumPorts(new TransportType[1] { TransportType.USB });
if (mfports.Count >= 1)
{
if (mfports[0].Name.Contains("G120") || mfports[0].Name.Contains("20100") || mfports[0].Name.Contains("20260"))
{
try
{
Program.mfdev = mfdep.Connect(mfports[0]);
MFConfigHelper cfg = new MFConfigHelper(mfdev);
var buf = cfg.FindConfig("test");
cfg.WriteConfig("test", new byte[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 });
buf = cfg.FindConfig("test");
}
catch (Exception e)
{
}
}
}
}
}
}
and i’ve got this error:
‘cfg.WriteConfig(“test”, new byte[] {1,2,3,4,5})’ threw an exception of type ‘GHIElectronics.TinyCLR.Debugger.Management.MFConfigurationSectorOutOfMemoryException’
Data: {System.Collections.ListDictionaryInternal}
HResult: -2146233088
HelpLink: null
InnerException: null
Message: “Configuration sector is out of memory”
Source: “GHIElectronics.TinyCLR.Debugger”
StackTrace: " at GHIElectronics.TinyCLR.Debugger.Management.MFConfigHelper.WriteConfig(String configName, Byte[] data, Boolean staticSize, Boolean updateConfigSector)\r\n at GHIElectronics.TinyCLR.Debugger.Management.MFConfigHelper.WriteConfig(String configName, Byte[] data)"
TargetSite: {Void WriteConfig(System.String, Byte[], Boolean, Boolean)}
I see. So old methods won’t work and I need to implement custom handler on the board? Can you please suggest me the right path to implement it over USB? USB CDC with mode selection or anything else which I don’t know? Thank you