7

I'm using a microprocessor - PIC32MZ2048efm144 MCU that receives commands encrypted with a specific key, decrypts them and executes the command. The encrypted commands are stored offline, so I cannot just change the key whenever I want. The key is FIXED. The commands are encrypted by a server, and donwloaded by a phone. The phone sends the encrypted commands to the MCU at a later time, when it's not online. The commands are encrypted before the phone communicates them to the MCU, so a session key is not possible.

I am allowed to connect an external encryption / decryption module to the PIC, but then the data will pass decrypted in at least one direction..

The solution brought here: Storing a secure key in an embedded device's memory

uses one-time keys to encrypt, but I need to store a single super-secret key

What My employer requires is for the keys to not be accessible, so physical protection besides the one offered by secure memory modules and the MCU, is not considered.

Assuming no military-grade equipment is used, are there any know solutions you guys know and can recommend?

Thanks in advance!

Sonja
  • 77
  • 1
  • 4
  • Can you explain more about what you are trying to prevent? What does the microprocessor do? Do you think using a public/private key might work? If you stored the private key on the micro-processor? Then the devices sending commands would create a session key, encrypt it using the public key, and send it to you. After that, both sides use the session key. What would happen if an attacker had the public key (which, even though it is called "public", does not actually have to be public)? – user57037 Nov 21 '16 at 09:03
  • @mkeith I updated the question, hope it helps :) – Sonja Nov 21 '16 at 10:59
  • 3
    Since you've chosen that PIC, why not use the "Programmatically Secure Key Storage" it provides? It has its own built-in crypto module! – pjc50 Nov 21 '16 at 12:14
  • 2
    I don't think you've clearly quantified the value of your secret. It seems like you want a cheap, and reliable method (which I think is unknown). Ask for clarification on what needs to be possible _after_ a vulnerability is found in this first solution. Signed over-the-air firmware updates would be my first non-negotiable feature... Its a system problem - always. – Sean Houlihane Nov 21 '16 at 14:00
  • Well, if the PIC's memory is protected (and it even has a key storage module) why not use a simple AES encryption? I know it's symmetrical, but if the server is secure (which we kind of have to assume) then there is no risk here - or is there? – jaskij Nov 21 '16 at 19:11
  • @pjc50 this pic does not support "Programmatically Secure Key Storage" :( only the PIC24 does that.. – Sonja Nov 24 '16 at 08:41
  • If you have a finite number of commands encrypted with a static key there is a type of attack called a replay attack that you might have to worry about. The idea is that the attacker sees the encrypted command, observes the result, then knows what that encrypted command does, and can play it back. The attacker may not decrypt it, and may not have the key, but he/she can send the encrypted command any time he or she wants. If the attacker cannot observe the encrypted command, then there is no need for encryption in the first place. – user57037 Nov 30 '16 at 08:22

3 Answers3

11

I'm sorry this answer won't actually solve your problem. But it is too long to fit in a comment, and it will allow you to rethink your problem in the right way (because as it is, I think it is flawed).

This kind of problems have to be solved taking account all components of the system, and making reasonable assumptions on what a potential hacker can or can't do.

For example:

You say: "the PIC32MZ2048efm144 (MCU) receives commands encrypted with a specific key, decrypts them and executes the command". I suppose the result of the execution of the command is toggling some GPIOs to actuate stuff.

Then, why are you afraid that, potentially, some data passes decrypted between the MCU and an encryption/decryption module? A hacker that has access to the hardware to see the decrypted commands would, anyway, be able to directly act on the GPIOs of the MCU and "actuate the stuff" as easily.

Second example:

Using on-time keys is an idea. But as you say, where do you store the main master key used to generate the one-time keys? You'll face the exact same questions as in your original problem.

Actually, there is no way to make your system secure if you suppose that a hacker can potentially sneak in at any location of your system (which is what it seems to me you're currently assuming).

What makes a system secure, then?

A smart card is made secure because it is unreasonable to assume a hacker can probe the internal routes within the IC, between the memory and the CPU block.

An electric door lock is made secure because it is unreasonable to assume a hacker can reach the wires that actuate the lock.

Etc... Basically, you have to start by indentifying things a hacker won't be able to do, and work out your whole solution from there. For example, is it possible to put your whole system in a secure, physically tamper-resistant box? In this case, you can freely have decrypted commands passing through an internal bus.

You can't build a secure system without knowing what it is the hacker can't reasonably do. You didn't tell us that. We therefore can't propose a complete solution.

dim
  • 15,845
  • 3
  • 39
  • 84
  • first of all, thank you for the elaborate answer! I updated the question in a way I believe will answer you :) – Sonja Nov 21 '16 at 11:07
  • What I undertand from the edit of your post is that only the keys need to be secured. The actual results of the commands **don't** need to be secured. In this case, put the keys in an external secure module like you suggested, and accept that the decrypted commands can be seen in clear. If my suggestion is invalid for some reason, **take the time to explain in *details* what is acceptable and what is not**. It's not just one more sentence in your post that we need. We need the whole picture of the thing. Really. – dim Nov 21 '16 at 11:12
  • 6
    Also, I feel that encryption of the commands isn't actually what you want to do. Usually, we need to encrypt *data* (some information about something, or a document...). But we rarely need to encrypt *commands* sent to a device. What is usually required on commands is *signing them*, to guarantee that they come from the authorized party. But their content is rarely sensitive, actually. So you should confirm this as well. – dim Nov 21 '16 at 11:23
2

This looks like a classic case where asymmetric key encryption would be useful. In asymmetric key encryption you have two keys, a private one and a public one. You want to fully protect the private key, but the public key can be made public and needs no protection. you may be able to keep the private key on the secure system and the public key on the embedded device.

hildred
  • 852
  • 1
  • 7
  • 17
  • Decryption of data is made with the *private* key (and encryption with the public key). Otherwise, it means everybody can decrypt (as everybody has access to the public key), which would be a problem. Therefore, you need the *private* key to be in the device. So, now, how to put the private key in the device? Well, back to the initial problem... – dim Nov 21 '16 at 15:45
  • being able to decrypt commands doesnt allow creating new ones from scratch so having the public key accessible somehow isn't that much of a issue – masterX244 Nov 21 '16 at 15:57
  • This is generally the same as cryptographic signing; which does have the disadvantage that if someone has the public key (doesn't actually have to be public, could be as securely stored as the symmetric key) they can decrypt everything; but, as masterX244 says, you generally can't create/sign new commands. I think this is a good solution. – CoderTao Nov 23 '16 at 05:44
0

You don't explain why you want the commands encrypted (in other words, what your threat model is). Is your purpose to prevent an adversary in possession of the PIC based device from determining what the commands sent to it are? Or are you trying to prevent the PIC based device from executing a set of commands substituted by an adversary and only allow it to execute commands originating from your server?

If the former, you face an almost impossible task: your device must decrypt the commands in order to execute them - possession of the PIC device means possession of the decryption key. An adversary can either extract the key (stored in the PIC device which he possesses), or simply wait until until your firmware decrypts the commands and then capture them from memory.

If, on the other hand, you're only trying to ensure that you device will only execute commands originating from your server, you're in luck. In this case you can use public key encryption (e.g. RSA) or a public key digital signature scheme (e.g. DSS). In these, you device only stores the public key: this is sufficient to decrypt the commands (or verify the digital signature), but can not be used to encrypt commands (or generate a digital signature) that the device will accept. That requires the private key, which you use to encrypt (or sign) the commands before sending them. The private key never needs to leave your server. Even better, encrypt of sign the commands on a machine that doesn't communicate externally and only copy these to the server so the private key is never found on an externally accessible server.