Hi everyone, we build a data recorder based on netmf and ghi devices. This can be used in case of crash analysis, performance enhancement…
We want to ensure, data integrity and non deletion by users unless with password or an hidden process. Do you have any clue about about such a feature using .netmf?
The data on the SD should be encrypted as a minimum and only read by some software you provide.
Another option, which is more preferred for such a solution, is to use one of the FLASH devices you solder to your board and access it the same as you would with SD. This way you don’t risk the card being disconnected, unless of course your device is designed so that the card can be removed. Not a good idea though if he device is being used to monitor performance. Drivers here who know about the onboard GPS have figured out how to disable it so we have to come up with solutions to prevent this.
There is no feature in netmf for that; even though the hardware actually does support it.
Hi guys and thanks for your interest in this topic.
Of course without a way to lock physically the sd on the board it can be put on a PC in order to attempt files deletion. We do not use a push pull socket but a socket hinge and we paste it with silicon glue. If the µsd is removed then we would know it unless customer clean the glue and reuse the same one. In the past we were using a push pull socket and a hole at the limit of the sdcard in whose a pop rivet was inserted… this was also a good way to lock sd.
Now in the software point of view:
We have MSC feature so a PC can access SD (and I think the vulnerability is here)
An FTP server. I believe that I can avoid file deletion for anonymous connection.
Encryption will ensure data integrity but it can’t avoid file deletion.
The dream would be a µSD with a password protection layer (no password: read only)
I will try to see if something exists in military products…
[url]https://www.sdcard.org/developers/overview/copyright_protection/[/url]
It’s in the specs but I have no understanding of how to start it up. Since GHI gives us the Register class, it may even be theoretically possible to enable it now… but no one knows.
Interesting !!! 
It seems that encryption and decryption is restriceted to licences and I am not sure that our company will have enough ressources for the licence fees…
Then I guess it comes down to a license cost issue. What is the solution worth to you and if the license cost is ok then your set. If not then you may have to weld the sd card to the pcb using that black epoxy.
Edit: Which NETMF device are you using? Depending on what it is, you could implement your own PGP encryption. Give the device the public key and keep the private key to your self. They may be able to tamper and delete the data, but they sure can’t modify it. This will meet your temper protection concerns, however the amount of data you can cypher at a type will be limited based on the device itself. I personally would use NETMF devices based on the STM32F405. This way there are no points on the PCB where the communications can be intercepted as to try and guess the encrypted key. With many of the larger NETMF devices intermediate encryption stages may be copied to the external ram before final encryption is complete. This could (if they are very good) give an attacker the chance to intercept the data with the intent of extracting the public key. The SoC solution however would require probing the chip itself; which would be much harder.
(Pursuant to my edited post)
Ultimately there is no such thing as completely secure encrypted data, only secure enough. You just have to put enough of a deterrent to tampering that it is not worth the attacker’s time to do it. Therefore if you can keep the value of the data that they can obtain, very low. Then they won’t even bother to do the work to compromise it.
So at some point this is a solved issue, right? Insurance companies now offer discounts if customers use their tracker/crash monitor. How do they solve the tamper-proof but retrievable data problem today? If that is something like hot-glue on the uSD card, or some other tamper evident method to protect physical access, is that sufficient for your application? Perhaps you need to have a chemical signature in the glue so you can see someone hasn’t just removed the glue, tampered with the card, and then re-glued with off the shelf glue? Or are you trying to solve for a different “attack” scenario, a different set of attackers with different motives, or something ?
From what I gather the data is important to his case. He needs the data unmolested. So long as they don’t destroy it outright, they shouldn’t be able to tamper with it.
9000USD for production sales agreement. This is far from what we can pay…
You’re right but I’m less interested by encryption than avoid file deletion. I think that the only way is to not allow MSC feature and to lock the sd physically on the board. Then I imagine that we can manage files rights (read write) using FTP server.
The other solution is to use flash memory chip but the one whe have already chosen is a spansion S25FL032P and it does not exist a chip in this serie with memory density similar to SD (4GB as a minimum)
Cryptographic approaches may still be helpful. If you use chained signatures (not necessarily encryption, just signing) on your files and store a chaining value in EWR, then any missing files would be immediately detectable both in code on the device and/or by examining the SD card content. Depending on how you structure the chaining information, you might even be able to make strong statements about how many files had been deleted or altered.
By chained signatures, I mean a signature that incorporates the hashes of all previous files, combined with a value stored in EWR which is mutated in a predictable way for each added file.
Defeating this approach would require a heck of a lot of work - at very least, reverse engineering the app and writing a custom app that could access the same EWR zone and write a carefully constructed value there. That establishes a pretty high bar. You can raise the bar further by exchanging chaining information periodically with a server. Then, even hacking the device won’t succeed in fooling the algorithm.
If your users can touch your device, then nothing is completely secure, but you can use approaches like this to set the bar so high that it is no longer worth their time.
This is an area of cryptography known as ‘non-repudiation’ - that is, making sure that the origin, existence or content of past messages cannot be denied.
A request is made to kingston technologies let’s wait and see…
Guys you are terrific what is the domain where I won’t learn from you!!!
The other option is to ask GHI to enable a kind of password feature in the MSC mode since it seems MassStorage is in GHI sdk and not in the NETMF core. Hey GHI team what are you thinking about that?
Ok modifications have been made to deny command for unauthorized user. It was quite simple. I need then to convince my boss to remove MSC feature…
Ok - I’ll bite - what exactly was the ‘quite simple’ change?
I’ve added a boolean “is_restricted” to the UserInfo Class.
I’ve added an item in the enumaration : UserAuthenticationResult.Limited
In the FtpCommandType.pass the code is now:
if (state != FtpState.WaitPwd)
{
SendResponse(332);
break;
}
var args = new UserAuthenticatorArgs(tempName, command.Content);
FtpListener.RaiseEvent(this, args);
if (args.Result == UserAuthenticationResult.Approved || args.Result == UserAuthenticationResult.Limited)
{
Logging.Print("Current directory: " + args.StartDirectory);
_currentDirectory = new FilePath(args.StartDirectory);
_listDelayInterval = args.ListDelayInterval;
if (args.Result == UserAuthenticationResult.Limited)
{
User.is_restricted = true;
}
else User.is_restricted = false;
User.UserName = tempName;
User.PassWord = command.Content;
SendResponse(230, "access granted for " + User.UserName + ", restrictions may apply.");
state = FtpState.WaitCommand;
break;
}
SendResponse(530);
state = FtpState.WaitCommand;
break;
Then in each command where user needs to be properly identified I check:
For example:
case FtpCommandType.Store:
if (state == FtpState.WaitPwd)
{
SendResponse(331);
break;
}
if (state == FtpState.WaitCommand)
{
if (!DataModeOn)
{
SendResponse(425);
break;
}
if (!User.is_restricted)
{
SendResponse(150,
"Opening BINARY mode data connection for " + command.Content + ".");
var request = new FtpListenerRequest(WebRequestMethods.Ftp.UploadFile,
_currentDirectory.Combine(command.Content).GetNetPath(), this);
var context = new FtpListenerContext(this, request);
_sendContext.AddContext(context);
}
else
SendResponse(550);
break;
}
SendResponse(503);
break;