Subscriber Discussion

Cyber Security - Firmware Encryption

UM
Undisclosed Manufacturer #1
Mar 17, 2017

**Disclaimer:  I am posting this on my own, with no relation to the manufacturer I work for.  I have been interested in this for a while, and finally got around to building a linux VM to play.**

I am starting this discussion for people to be able to discuss about firmware encryption.  This may not be the most scientific method, just what I know about so far...

Many hackers and researchers find vulnerabilities by reviewing firmware to see the file system, code, database, user list & password hashes, etc.  Once they find what operating system/files are present, they can then look for weak algorithms, client side hashing, or buffer overflows.

Link to video showing a hacker playing with firmware...

Encrypting the firmware makes this a lot harder.  The hacker instead needs access to a device that they already have user access to, as opposed to just reviewing the firmware and then attempting to access a device on the Internet.

 

I have chosen models based on common manufacturers that I could access firmware for.  I am not familiar with all of the lines for each manufacturer, so let me know if there is a better, newer model to test.  If you can point me to a firmware link, I am happy to take a look.

 

Below are screenshots of firmware that is not encrypted.

You can then use the software to extract the contents to examine:

I had to manipulate the file to remove a header. Then I was able to extract the firmware archive.

Here is the web filesystem:

Here is a firmware that is encrypted.  Note that it states that the file uses OpenSSL encryption.

Some firmware files I was not able to tell, which may mean the firmware has been obfuscated or it may also be encrypted, but I was unable to tell with the tools I have.

Arecont surrountvideo omni g2 av20275dn v65199 unknown/Possibly encrypted

Avigilon H4 ES camera line ACC6.0.0.24 h4HD-FW-t200-3.16.2.52 no encryption

Axis P3225-LVE no encryption

Bosch dinion ip dynamic 7000 hd cpp 6.32.0099 unknown/Possibly encrypted

Canon vbh43 v.1.25 not encrypted

Dahua DH-IPC-HDBW42A1FN-AS v432105 not encrypted

Digital watchdog wdc-md421d 2.1.5.3 not encrypted

Flir quasar gen II fs20160805nsz - broadcom header, appears not enc. 

Hanwha Techwin QND-7080R v1.01 Encrypted

Hikvision DS-4x12 v5.4.0 not encrypted

Panasonic SFV78L v2.53es unknown/Possibly encrypted

Pelco Sarix IME+ next gen dome cameras - IME329 v6.2.1.73 no encryption

Sony G6 v2.7.3 No encryption

 

 

Vivotek FD8369A-V v0200e not encrypted

 

Anyone else think that this is important, and that firmware should be encrypted or at least have an MD5 hash listed so you can confirm that the file has not been tampered with?

(2)
Avatar
Brian Karas
Mar 17, 2017
IPVM

First off, nice work!

Encrypting the firmware makes this a lot harder.

Encrypting firmware may make decompilation/analysis harder, but it is unlikely to make it impossible. A big part of the problem with this logic, IMO, is that you are pitting a large army of hackers against your encryption scheme/method. You really only need to slip up in one part of the process and then the 'protection' is gone.

Further, using firmware encryption to hide poor cyber security is not any kind of a solution, and there is still the risk some of those security weaknesses could be discovered through other means (traffic sniffing between camera and clients/servers/services, logical guessing, brute-force attacks).

I am all for MD5 checksums to make it easier to verify that a given firmware image is not tampered with or altered though.

UM
Undisclosed Manufacturer #1
Mar 17, 2017

I definitely agree that encryption should not be used to hide poor programming .  It should just be another layer of defense and good coding technique to encrypt and sign/hash your files.

(1)
UE
Undisclosed End User #2
Mar 17, 2017

encrypted firmware gives mostly only one signal... "I'm hiding stuff", and therefore no "defence", rather opposite in my eyes.

I think it's better to keep it a bit more open... besides, the encrypted image needs to be decrypted before it could be deployed, and thats done in the device and usually with static key, so what's the actually defence...

However, I share same as Brian, good work. more of that :)

(1)
(1)
UM
Undisclosed Manufacturer #1
Mar 17, 2017

I think the biggest reason to have encrypted firmware is to prevent someone from creating a malicious firmware file. 

A device that is expecting an encrypted firmware hopefully won't take one that isn't encrypted or signed by the wrong party. 

We recently saw someone create a utility to create new firmware files to remove restrictions, etc.... Huge cyber risk. If someone is able to post this as if it is the legit firmware and get zombie devices can have a nice boy net army.... 

Avatar
Brian Karas
Mar 17, 2017
IPVM

But if I can break the encryption to create a malicious file, I can theoretically also re-encrypt it.

Signed is completely different.

UE
Undisclosed End User #2
Mar 17, 2017

But, can't you break the signed and re-sign then?

UE
Undisclosed End User #2
Mar 17, 2017

I understand your point, but if there is a tool that decrypt, you could reverse it to find out how to encrypt (or simply get it from some SDK maybe). From there you need to be in MITM, or compromise the actual Firmware holder. This has already happen few times some years ago, with modified SW packages and modified MD5 checksum.

However, I agree with you that this is potential threat, and should not be threaten with ignorance.

AH
Andrew Hogendijk
Mar 20, 2017

I think there is a confusion here between encryption and digital signing. Encryption in this case would seek to 'hide' the contents of the firmware. At some point the firmware would have to be decrypted in the device for it to be able to run - that decryption key must be 'available' - therefore you will always be able to get to the firmware with a little effort. In short if you have your hands on the device / computer and it can run you can get to whatever you want.

Digtal signing on the other hand is a system whereby at the hardware level only trusted (signed) firmware would be allowed to run. If it's not signed then it simply doesn't run.

This is all a part of a defense in depth approach to IT based security. There are many other layers of defense that also need to be considered. Sandboxing of anything running, watchdogging, system behavioural control, and so forth.

Building something to be as secure as possible is a multi-faceted problem that requires a system be designed securely from the ground up. It is not something that you can slap a 'security measure' on top of after the fact.

Andrew

(1)
AT
Andrew Tierney
Mar 20, 2017

It's possible to store keys in the the device in such a way that it is very difficult to recover the key used to encrypt firmware. We're talking days to weeks of work, certainly enough to deter casual inspection.

AT
Andrew Tierney
Mar 20, 2017

Here's my take on it, testing embedded products and providing recommendations for vendors.

Firmware signing is a necessity. It's vital that only genuine firmware can be loaded onto your device without serious effort (e.g. the Android bootloader unlock model followed by Moto). Without this in place, you cannot ensure that the firmware you are running is genuine and not malicious.

Firmware encryption is not a necessity, but it does deter casual and time restricted hackers from inspecting the firmware. Many of the vulnerabilities found recently would be virtually impossible to find via a black-box approach. It is better that these vulnerabilities are found during development and internal testing so that the vulnerability lifecycle is totally under vendor control, rather than potentially having a loose cannon security researcher drop a 0-day on you.

People who think that third-party researchers finding vulnerabilities are significantly improving security are naive. The amount of issues that are found are tiny compared to a full pen-test with white-box access to source.

(1)
Avatar
Brian Karas
Mar 20, 2017
IPVM

People who think that third-party researchers finding vulnerabilities are significantly improving security are naive. The amount of issues that are found are tiny compared to a full pen-test with white-box access to source.

In a perfect world, yes. In the case of the recent exploits found in security products, there did not seem to be an option for white-box access to the source. So, the exploits found by security researchers have significantly improved awareness, and most likely overall security, as the vendors have generally responded by patching/updating firmware.

 

(1)
UM
Undisclosed Manufacturer #3
Sep 14, 2018

“So, the exploits found by security researchers have significantly improved awareness, and most likely overall security, as the vendors have generally responded by patching/updating firmware.”

 

Brian I fully agree, yet there is still a long ways to go in education of the physical security sector to understand what is happening from firmware and software coding issues and the impact they can create. Responsible vendors I do believe are trying to also get a handle on these issues as they aren’t  static but ever changing in the infosec world which effects us all everyday.

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions