WHITE PAPER Secure Firmware Upgrade System

ENlighten Whitepaper TemplateJune 2014
TABLE OF CONTENTS
Requirements of a Firmware Upgrade System ........................................ 4
Secure Firmware Upgrade Process ........................................................ 6
Secure Firmware Upgrade Reference Architecture ................................. 6
Firmware Upgrade Generator ............................................................... 7
3
Abstract
and data that resides as read-only software on that device.”
Even though Firmware is designed as Read-only component,
Firmware Upgrades are required to correct bugs and add new
functionalities. The ability to upgrade Firmware is considered
an important feature for embedded systems, particularly the
ones that are connected to the Internet. It becomes even
more important when the devices are deployed in remote
locations. In such cases somebody has to go there and update
the system, generally the OEMs don’t get paid for updates, why
would they incur this extra cost? A cost effective solution is to
have a Remote Firmware Upgrade. But, it has its own share of
problems - what if the system gets a wrong image and the
system becomes unusable, it is even worse if the attacker adds
a malware to the image, then the whole network at the client
side will go for a toss.
To overcome these problems device manufacturers are opting
for Secure Firmware Upgrade, where the upgrades are first
authenticated and verified and then upgraded. This paper
discusses the key issues that must be considered for the
upgradability of the system and presents a reference design of
the Secure Firmware Upgrade System.
Why Secure Firmware Upgrade?
In order to strive for constant improvements OEMs quite often
release firmware upgrades for their systems. These upgrades
not only fix bugs, but also extend the existing firmware.
Firmware upgrade is a very critical and sensitive operation
Firmware Upgrades are
add new functionalities.
4
Doing it right the first time is important failing to do so might
brick the device and make it unusable and worse, it could also
update the firmware with any malicious code and attack the
connected devices too. Recently there has been a lot of
traction in this segment e.g. Firmware modification attack on
some printers (CVE-2011-4161) where a firmware update can
be sent remotely to port 9100 without authentication and a
recent firmware modification attack on home automation
devices where firmware modification attack can be used to
repeatedly turn on and off a small desk lamp. More malicious
hacks could do similar things to heaters or other connected
devices in the home. It is very important to authenticate and
secure the firmware Upgrade system.
Requirements of a Firmware Upgrade System
The requirements for a firmware Upgrade system are different
for each system we have listed below some of the generic
requirements
Security
source.
User should be able to verify the Integrity of the upgrade
before applying it.
component of Firmware upgrade.
Reliability
Reliability is again a very important feature in fact at times
when the user is unsure of the system’s behavior he/she
refuses to upgrade the firmware. During this process
User should not lose his/her personalized data.
System's performance should not degrade .
Security, Reliability, Minimal
Downtime, Automated Process
5
operations with minimal time. Different strategies could be
defined for different systems e.g. for critical systems downtime
should be very low which might result in more memory and
computational requirements. Hence downtime could vary, but
the downtime should be well defined and agreed upon by all
stakeholders.
Fault Tolerance
Firmware Upgrade may fail due to any of the reasons - bad
Firmware resulting which device may stop functioning, flash
corruption, Communication errors resulting in partially written
Firmware.
make the device unusable.
For General users the Firmware Upgrade process should not
request any inputs from the users it should be a self-contained
application that installs firmware upgrade if updates are
available and user agrees to update his/her system. All the
other required inputs could be received from the server or
should be contained in the device.
Depending on the device type the weightage of requirement
can be increased for example for a critical system like Health
Monitoring device minimal downtime is more important, in
fact some of the Firmware Upgrade systems are providing zero
Downtime Solutions.
6
following diagram depicts various steps that are required to
Upgrade Firmware. The process starts right from the time
when the firmware change needs to be propagated to the
client.
Based on the discussion, we present a Reference Architecture
for Secure firmware upgrade.
7
The system is divided into two parts Server side Modules and
client side modules. The server side implementation is used to
generate an encrypted firmware image. This image is then
pushed to the client from the server. The downloaded image is
then decrypted and verified via security module at the client
end and then the Firmware upgrade is installed.
Firmware Upgrade Generator
Generate Upgrade using the two firmware versions.
Test and Verify Upgrade on Old firmware.
Publish Firmware upgrade.
The tested firmware upgrade is then sent to the security
module as an input.
This module resides in client and server, the server side
security module is responsible for encrypting the image, while
© 2014, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.
8
the client side module is responsible for the verifying the
security and integrity of the Firmware.
The goal of security module is
Encrypt the Image
unusable if firmware is deleted from the hardware or vice-
versa.
To accomplish this task 2 level of security is maintained.
Firmware Authentication
integrity and authenticity of the firmware before execution.
This task is accomplished using asymmetric key pairs.
Hardware Authentication
Before execution the firmware verifies the hardware using
Unique Id e.g. the MAC id of the hardware. The firmware is
executed only if the verification is successfully completed.
Device Firmware Update Client
This module is deployed on the client device and is responsible
for downloading the upgrade from the server.
9
Following is the flow chart for a typical Firmware Upgrade
Client: Firmware Upgrade Process
time
End
Before designing this module the OEM needs to consider the
following parameters:
How much of end user interaction is required? e.g. For
some Firmware updating clients the end user has an option
to specifically install a selected version on his/her device
for others the end user confirmation is required to
download and install new updates.
How the end device will be notified about available
updates? The device should poll for updates or the server
will push updates on end devices.
Will all the device get updates at once or each device will
be notified about the updates separately to manage the
load on update server?
Firmware Upgrade Installer
Firmware Upgrade installer receives firmware as an input from
the security module and installs it on the system. Typically a
Linux based embedded system will have the following memory
10
structure. In this diagram we can see that generally Linux
Kernel and File System are upgraded. For some cases even the
boot loader can be updated
Boot Loader
The ability to upgrade a system remotely has become an
important feature, each device that need to be upgraded
comes with its own set of issues and design considerations.
Firmware Upgrade design is a process that starts right from the
Device Conception phase and continues till Device’s End of Life.
As discussed in this paper there could be serious consequences
of tampering with the device firmware so OEMs need to define
a procedure to verify and authenticate the firmware before
upgrading. The advent of IoT has added flames to this problem
and it has become necessary for the OEMs to continuously
improve and secure their Firmware Upgrade process.
11
References
Embedded Exploitation” Ang Cui, Michael Costello and
Salvatore J. Stolfo Department of Computer Science
Columbia University New York, US fang, costello,
[email protected]
http://arstechnica.com/security/2014/02/password-leak-
in-wemo-devices-makes-home-appliances-susceptible-to-
hijacks/
K. Shade.
12
Author Info
Shivani Tomar is a Senior Technical Lead with HCL Tech. She has extensive experience in developing software focusing on the consumer electronics segment. She is currently focusing on various aspects of Security for Embedded Devices. She is a part of Practice team in HCL and has contributed in various projects.
Hello, I'm from HCL's Engineering and R&D Services. We enable technology led organizations to go to market with innovative products and solutions. We partner with our customers in building world class products and creating associated solution delivery ecosystems to help bring market leadership. We develop engineering products, solutions and platforms across Aerospace and Defense, Automotive, Consumer Electronics, Software, Online, Industrial Manufacturing, Medical Devices, Networking & Telecom, Office Automation, Semiconductor and Servers & Storage for our customers. For more details contact: [email protected] Follow us on twitter: http://twitter.com/hclers Our blog: http://www.hcltech.com/blogs/engineering-and-rd-services Visit our website: http://www.hcltech.com/engineering-rd-services

Documents

WHITE PAPER Secure Firmware Upgrade System