0

I'm designing the update procedure for IP Camera's. I'm wondering if my current design is secure enough.


I have a binary file that I want to get to a device. I make a hash of this binary file and encrypt the hash with my private key (a signature). I put this binary file and the encrypted hash in a zip file. I create a MD5 hash of the zip file. I put the public key, MD5 hash and zip file publicly available.

I have multiple devices, some of them under hostile client control, some of them under friendly client control.

The friendly clients have a download algorithm like this:

On receiving a command, containing URL's, the provided URL's are used to download the public key, the MD5 hash and the zip file. The downloaded zip file is checked to see if it matches the MD5 hash. It is then extracted. Then the encrypted key is decrypted with the provided public key. A hash is made of the binary file and compared with the decrypted key.

If both the MD5 check and the hash check of the binary file succeed, the binary is executed with root access.

The hostile clients have access to the whole device, so any stored secrets on the device are known to them. They don't have access to the system I store the private key on, though.


From what I can see, the command and timing thereof is potentially hostile, the URL's are potentially hostile, so the zip is potentially hostile, as is the binary and hash and MD5. The MD5 hash is easily bypassed, but it only serves as file integrity check. The encrypted hash of the binary, however, is my main point of defense.

When the zip and the binary and the encrypted hash and the public key are all under control of the attacker, is my system still secure (that is, can an attacker make a friendly client execute a binary that didn't originate from me)? Is breaking the security easier since the "ciphertext" and "plaintext" and the public key are provided? If it is easier, is it easier by any relevant magnitude?

4
  • 2
    Please, stop trying to invent your own crypto! There are well understood, easy to use digital signature algorythm, use them!
    – Stephane
    Apr 14, 2015 at 12:02
  • @Stephane I do not intend to invent my own crypto - I'm wondering if my application of the crypto is proper.
    – Pimgd
    Apr 14, 2015 at 12:20
  • 2
    Ah but you do: you're reinventing a digital signature algorythm. You're also confusing the private and public part of the key (you need the private key to decrypt data) and your threat model seems all over the place (what's that thing about "hostile clients"?). In fact, you're getting it all wrong. If you want to deliver code update, digitally sign it and deliver it over a secure connection. If you need to limit who has access to it, have clients authenticate before the download.
    – Stephane
    Apr 14, 2015 at 12:29
  • @Stephane I'm not sure I'll be able to establish a secure connection. I do not intend to encrypt the data, just to encrypt the hash (thereby making a signature, right?).
    – Pimgd
    Apr 14, 2015 at 12:34

2 Answers 2

2

No, your update process is flawed, and anybody trying to comprimise it will succeed.

I assume you are not using TLS/HTTPS, as you don't mentioned them in your question.

That's why:

  • Your public key is to be obtained from the Internet

    This allows the attacker to intercept the connection and provide a tampered public key. All your verification process was already defeated.

  • Your zip is downloaded and verified using a possibly tampered key

    As soon as the file gets downloaded it will be checked against the public key (now tampered). The attacker has already compromised the public key, and can create a new zip with a malicious payload and sign it with the generated key. Your program will happily accept it.

At this moment, the malicious payload gets executed with root access. Game over.

A (somewhat) safer approach is this:

  • Use SSL/TLS

    This makes harder to intercept and tamper with the files over the internet.

  • Use certificate pining

    It makes even harder to tamper the files, as a self signed or unrecognized CA will not be accepted.

  • Put the public key on your updater

    This way it will not be easily fooled into accepting a forged update package.

  • Protect the updater

    Your device must not allow access to the memory or the contents of the filesystem where the updater is installed. If you fail at this, the public key inside it could be changed.

3
  • Trying to protect the device is nearly pointless: the goal of an update system should be to protect legitimate systems against compromise, not fix (or even detect) compromised systems.
    – Stephane
    Apr 14, 2015 at 12:42
  • Physical access is not a concern for me, since someone could solder a few wires to the camera and flash it with their own firmware, after which the camera could be running anything. Also, a question, if the public key is on the updater, do I need a secure connection?
    – Pimgd
    Apr 14, 2015 at 12:44
  • 1
    A secure connection is useful for defense in depth: the more interlocked layers you have, the better. In this way, the attacker must bypass the SSL/TLS, the certificate pinning and the public key on the device to be able to compromise the update package.
    – ThoriumBR
    Apr 14, 2015 at 13:03
0

No.

An attacker can make a binary. They can then make a hash from their binary, and encrypt it with their private key. They then package their binary and supply the malicious binary, public key to the camera. Because the attacker is able to supply the public key and the content, he controls both sides of the check and the system is easily compromised.

At least one of the two parts must be under your control, and since the binary always changes, you'll have to put the public key on the camera in a secure manner. Else it's not possible to verify that the supplied binary was signed by you.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .