Is it possible to password protect an USB MSC drive (STM32L4)?

[martinj3456]

Posted on June 20, 2018 at 06:11

Hello,

I'm following the USB MSC CubeL4 example for STM32L476. Is it somehow possible to make this Mass Storage Drive password protected?

In my project, I'm storing sensor data in FATFS (SDIO) files in microSD card. I want to restrict the file's access when connected to PC (Windows and Linux) as USB Mass Storage mode.

If the Drive Password protection is not feasible, could you please recommend anything different or any example tutorial?

Thank you for your reply.

M

[Torsten Jaekel]

Posted on June 20, 2018 at 07:56

As I understand: you have USB and SD card on MCU, implemented a MSC device, which can be read from host PC via PC (as external memory device).

This is not password protected. As I understand it works in a way, that PC (host) sends requests via USB to read low level based sectors. So, the file system, reading your SD card etc. is done from host (for the host it is just a link to access sectors on your storage media). So, the MSC is not based on files, it is based on media, to access physical sectors on SD card (the file system sits on host PC).

If you could add a password protection: do not allow any sector read (and write) before not a password was entered successfully (deny all requests until password has released function calls).

The only problem:

it is not supported by any host software, not the host file system (which is involved here). The user had to start another application on host (PC) in order to send password (which MCU would receive in order to release the SD card sector read and writes). It might be too complicated. You could use a UART link (also via USB VCP) in order to send a password.

As I understand MSC - there is not any way to add password protection for SD cards (read via USB), not on media neither on file basis.

What about this?:

You store files, sensor data in files on SD card but the content is encrypted. You can still read and transfer files, but you cannot read the content on any host.

Encrypt file content on/via MCU, when writing to SD card, use RSA, DES or what ever (MCU might have RNG - Random Random Generator, used for public and private keys).

You just need an application (SW tool) starting on host (PC) in order to decrypt file content. You had to download (copy) files which are encrypted and a special app will decrypt (with password key entered).

MSC itself is very basic storage media access (like reading a floppy disk, via sectors).

[martinj3456]

Posted on June 20, 2018 at 16:39

Thank you for your kind reply. Yes, Password protected Drive seems little complicated.

Encryption seems feasible. Could you refer any examples or tutorial for STM32 ?

Also, is it possible from MCU side to encrypt the whole file (say .BIN file) from FATFS SD ? I mean is it possible to complete all sensor write first, and encrypt at the end when the file is to be closed? 

Thank you again.

M

[Tesla DeLorean]

Posted on June 20, 2018 at 17:01

At a file level I'd probably look to encapsulate in a standard from, like PKZIP, on the fly. Going back and doing it later seems to obviate the need to protect the data.

If you have your own format, you'd need to provide an app or other means of decoding. You could however be able to use AES or DES, or something asymmetric.

Doesn't sound like you have much windows/linux driver level experience, so doing a mass-storage driver or filter driver is probably not an option.

[Tesla DeLorean]

Posted on June 20, 2018 at 17:10

Consider writing data to a QSPI or eMMC on the board, and provide access to the data from there, or use it to stage plain text data before writing to MicroSD card. Ideally don't store anything outside the core in plain text

[Torsten Jaekel]

Posted on June 21, 2018 at 07:35

Sorry, I have not done such encryption and not checked any demo application. Just here my thoughts:

• if you use a STM32H75x (not 74x) - it provides CRYPTO engines and HASHes:
  as I understand datasheet: you can push any data stream (e.g. DMA from memory) through HW DES, AES engines, in order to encrypt or
  decrypt data
• so, if you push all file content through it, afterwards you store the encrypted sector on SD card, flash ... - this is what you might want to do,
  you would DMA memories, e.g. for a storage media the sectors, a file through it, you get back encrypted sectors, encrypted file buffers and then you write to storage (just put the encryption engine between file content generator and write file (sectors) to a media, before SD_WriteSector() you let encrypt)

And there is also (for STM32H7xx):

a feature to boot and run in secure mode (e.g. to protect your FW from debugging, spying ...). You had the option to  place your code, esp. your keys for encryption, in a secure area, run just as secure or even use the chip features to protect your code (make it invisible for anybody, even for you later).

But I have no clue how to change between 'open' and 'secure' in these STM32H7xx MCUs (I know ARM TrustZone, but it looks a bit proprietary to me in STM32H7xx).

My personal concern would be just on 'security holes', examples:

- even you encrypt - the keys can be found on (non-secure) memories (a debugger can grab it)

- the code you use, calling the CRYPT block functions can be debugged (not on a secure memory region)

- the data you transfer resides un-encrypted (before or when you do encryption) in a visible memory (internal SRAM) and even you kill it later - a debugger can set break point before it is done.

I know this problem from HW based cyphers where they talk always about the 'hot and cold' side, security demarcation lines, the 'red and black' side inside a system. If 'hot and cold' have still a hole, a backdoor - it is not really secure (e.g. keys on the 'cold' side stored or open data left on cold side, or spying code accessing secure region ...).

So, you need a system with real ARM TrustZone IP implemented. How much STM32H7 is really TrustZone compliant - I do not know.

(and also a question if security holes are still existing, e.g. see the recent news about caches on any CPU and opening a security hole: if you encrypt, all fine and encrypted data sits just in caches, secure vs. non-secure memories are OK - but somebody could 'snoop' cache content - you have a hole, even all other is fine - 'booo, how to make sure???' e.g. on multi-core systems with Cache Coherency Interconnects - another core could snoop secure data from caches).

At the end, you need two memory regions which are so isolated from each other (secure vs. non-secure) and the ability to disable debugging on secure memories (and very reliable code there because even you would not get a chance to debug later).

BTW: even snooping on HW signals, e,g, external SD card, flash devices, FMC DDR memory ... you had to think about: if you use external SD RAMs (FMC) and you transfer un-encrypted data to it - a hole again.

Very challenging if you want to do it really right and rock-solid. And hard to debug and make sure your secure code works well ... Good luck.

[Torsten Jaekel]

Posted on June 21, 2018 at 08:07

BTW: a simple way to encrypt in order to keep 'regular hackers' might be:

put your data into a stream of garbage, a stream of noisy (meaningless) data.

Idea is:

• you generate a stream of noise (e,g, with RNG), many bytes of random noise
• you substitute on particular spaces which are also randomly spread with your data bytes
• you add also a random noise value to your data bytes when stored
• you create a 'decoding protocol' which is never disclosed (just you would know where the bytes are, the amount of noise added, the randomized spacing ... - it is your KEY)

I have written such an approach in Python (for PCs): you could do auto-correlation for decoding and take a key which tells you the 'pattern' how you have

spread the bytes, which noise was added etc.

So, such a stream of random bytes where nobody would know where the user bytes really are, how they are spread (and scattered = reshuffled in terms of  their order) or which noise value was added - should be quite difficult to decode. If you put the key in front of this stream and you do not disclose the meaning, its coding - it might be quite safe. Just a need to write the counter-part, to decode.

So, the idea is:

'randomize and add noise to user data; place this modified user data in a big stream of garbage, noise, with randomized spacing ... and nobody will be able to decode and find your user data (just you via the opposite 'transfer/decoding function'. (it is more related to 'information hiding' then encryption, hard to find something inside noise ...).