Using software flashing to secure embedded device updates - Embedded.com

Using software flashing to secure embedded device updates

More and more devices in our modern world come with a multitude andvariety of embedded systems. An obvious example of this trend aretoday's vehicles, which have several dozen electronic control units(ECUs) that control almost everything, such as air conditioning,electric windows, the engine, and the brake system.

This article focuses on ECUs as a representative example of modernembedded systems, however, the described techniques work equally wellfor other embedded systems. Several ECUs allow downloading of updatedprogram and data code via a boot loader.

Such software might be a control unit firmware update for fixingbugs, for improving features, or for downloading data such asadditional multimedia files. The first case is also called a softwaredownload or simply flashing (since flash memory is updated).

The download might be performed directly over a diagnostic channelor another available communication channel such as Bluetooth and GSM.Once such vehicle communication channels are opened to the outsideworld for downloading software, their integrity must be ensured.

An example of a malicious software download is the replacement offirmware by an unauthorized party, e.g., as done for chip tuning in theautomotive context. The main security objective is as follows:

1. Only original softwaremust be accepted by the embedded system: No manipulated or malicioussoftware may be downloaded to the embedded system. In particular,software must not be successfully downloaded to the embedded systemthat alters its defined behavior.

2. Only authenticatedparties may alter data, e.g., parameters, stored in the embeddedsystem.

Furthermore, in an actual security design it is important to ensurethat the compromise of a single embedded system does not affect thesecurity of other embedded systems of the same product line, i.e., asuccessful attack does not scale. The required computationalperformance on the embedded system side shall be minimal.

Digital Signatures
The secure software flashing scheme we present is based on digitalsignatures. A digital signature provides the security objective ofintegrity and authenticity; data being digitally signed cannot bealtered by a malicious third party without being detected by thereceiver.

Furthermore, the receiver can verify that the data was indeed signedby the claimed signer. Moreover, the signer is not able to deny that heis the legitimate creator of the signature (non-repudiation). Digitalsignatures are generated and verified with asymmetric cryptographicalgorithms, such as the Rivest Shamir Adleman (RSA) algorithm orElliptic Key Cryptography (ECC).

A digital signature is computed as shown in Figure 1 below, .There is a key pair consisting of a private key SK and a public key PK.Only the signer has access to SK whereas PK can be publiclydistributed.

Figure1. The generation of digital signatures at the embedded systemmanufacturer.

In our setting, SK is only known to the manufacturer of the embeddedsystem, for example an automotive OEM, whereas PK is built into everyembedded system. The program code x is first hashed to a short fixedlength value y.

Typically, y is computed by applying a hash function of the SHAfamily, resulting in an output of 20 to 32 bytes. Finally, a digitalsignature is computed over y using the private key SK. The signaturecan then be verified by using the public key PK. Please note that theprivate key SK must never leave the secure environment of themanufacturer.

Therefore, signatures are typically computed in High SecurityModules (HSMs), such as smart card security controllers, which are usedin banking applications and which provide tamper-resistant features inaccordance with the Common Criteria (CC) security standard.

Certificates
As described above, a public key is used in each embedded system andfirmware programs are signed using the corresponding private key. It ispossible to use an individual public/private key pair for each embeddedsystem, vehicle model year, each ECU type, etc., however, thisincreases the logistic efforts of the overall system.

In the case of individual public/private key pairs it is reasonableto use certificates. A certificate is comparable to a passport; itcertifies a public key and, if required, an identity. In the automotivecase, the certificate is simply a public key signed by the OEM'sprivate key together with the public key and some additionalinformation: SigSK (PKA ) | PKA | data.

The flash program is then verified by PKA and signed withthe corresponding private key. When the flashing process begins, thecertificate first needs to be downloaded and verified using the OEM'sroot public key PK, and then the flash program is downloaded andverified using PKA .

Secure Software Flashing
A solution for this problem in general is quite simple. Based ondigital signatures, the issuer of the software signs the program codeand the embedded system (e.g. the control unit in the vehicle) verifiesit. Hence, the issuer holds a private key for signing the program codeand the control units hold the corresponding public key for verifyingit.

This is shown in Figure 2 below in more detail. First, thesoftware is developed. Once it is finished (step 1), the program objectcode is passed to a trust center (step 2) that signs the object codeusing its private key.

The signature is then passed back and attached to the program objectcode. The package of code and signature is now stored in a database(step 4) that might hold versions for different embedded systems.Finally, the appropriate program code is downloaded to a embeddedsystem (step 5) and verified by means of its public key (step 6).

Figure2. Secure software download

One can see that security objective  is clearly fulfilled: Onlya legitimate authority can issue an appropriate signature for programcode that will be accepted by the vehicle, i.e., only authenticsoftware will be accepted by the embedded system.

Most of today's cars already provide a mechanism for downloadingsoftware. Hence, only a mechanism for verifying the signature isadditionally needed in the vehicle. RSA is an appropriate fit forsignature verification, since it allows very fast signatureverification and it can be implemented in software without infringingpatents.

Some performance values of our implementation are displayed in Table1 below. Note that for the signature verification, first the programcode needs to be hashed and then an RSA exponentiation is performed.

Table1: RSA signature verification on ARM MPCore @ 400 MHz

On the server side the key management and the organizationalsecurity must be thoroughly organized. Organizational security includesthe organization of who has access to sign program code and how theprocess of signing is performed and recorded. However, no full-sizedPublic Key Infrastructure (PKI) is necessary.

Basically, it is sufficient to issue a single private/public keypair such that the private key is stored in the trust center and thepublic key in the embedded system. The trust center might simply be aPC that is disconnected from any computer network and a secure smartcard that holds the secret key.

If a finer-grained approach is desired, a key pair for each embeddedsystem type, for each production year, or each production locationmight be applied. No certificates that induce overhead are required,though.

The embedded system only needs to store a public key such that nosecret information is stored here. However, this public key must beprotected against manipulation, i.e. it must be stored in secure memorythat may be read but not overwritten.

For example, many modern microcontrollers provide internal Flash ROMmemory and security features which prevent the modification of thismemory. Otherwise, an adversary could replace this key and thenactivate any manipulated software.

Security objectives can be fulfilled by a simplechallenge-and-response mechanism as shown in Figure 3 below .The embedded system and an external party (e.g., a standard PC) share asecret key.

Figure3. Challenge and response identification

The parties then run a challenge-response scheme in order to provethat the external party knows the secret key. After a successful run,the external party can access the embedded system to adjust parameters.

However, it is crucial that a well-defined interface be specified.For instance, it is reasonable to record all changes in a log file andgive access only to non-safety critical data. Using a symmetric-keymanagement is reasonable – each embedded system knows an individualsymmetric secret key shared with the third party.

This third party might be the system manufacturer storing all keysin a protected database. The security can be further increased by usingsecurity tokens that hold the secret key for accessing the embeddedsystem. Such an approach even allows several authorization levels to beimplemented.

For instance, in the automotive context there might be a basic levelfor workshops to adjust typical parameters of an ECU, and another levelfor testing that allows all parameters to be changed.

Protecting the key built into the embedded system is crucial. If anadversary is able to read out a symmetric key or replace a public keyhe might be able to manipulate program or data code. Thus, virtualsoftware protection can be achieved only by using secure memory orapplying hardware-assisted approaches employing a security anchor.

Nevertheless, there are also mechanisms that try to complicateutilization or at least try to help identify the origin in casesoftware could be successfully read out by an attacker.

In order to make decompiling and re-engineering of program binariesmore difficult, programs known as “obfuscators'' convert source code,object code, or both, into obfuscated code, making the resultexcessively complicated and thus far less readable and almostimpossible to understand by a human being.

However, obfuscation only increases the difficulty for reverseengineering, limits portability and is regarded as “security throughobscurity''. Digital watermarking and fingerprinting are techniqueswhich embed visible or invisible information into a digital content(software or data) that cannot be removed or modified or can only beremoved or modified with difficulty.

Original owners then can use tools to extract the embeddedinformation to detect, e.g., the origin of an illegitimate copy ortampering. However, there are already technologies for both mechanismsto abolish respective restrictions. Thus, such mechanisms cannotreplace proper hardware-based software protection.

Secure Flash Process
The flash program file has several parts. Each block is optionallyencrypted, and the signature of the file was computed beforehand. Inthe first step, the external device that triggers the flashing processoptionally authenticates the bootloader (e.g., by a challenge-responsemechanism as described above). In the next step, a certificate might bepassed to the bootloader which verifies it using its stored public key.

Then, the external device passes block by block to the bootloader ofthe embedded system. The bootloader first decrypts the block and thenstores it in the flash memory. At the same time, the bootloaderincrementally computes the hash over each block.

Once all blocks are passed, the bootloader finalizes the computationof the hash value over the new flash program file and performs adigital signature verification using the determined hash value.

If the signature verification is successful, the downloaded file isaccepted and activated. Otherwise, a safety procedure is activated andthe bootloader awaits the download of a proper flash file. This isshown in Figure 4 below .

Figure4. Flash process

Conclusions
Virtually all modern embedded systems are equipped with internal FlashROM memory. Usually, a boot loader is built into the firmware to updatethe program.

However, in most cases there are no mechanisms implemented to avoiddownloading a manipulated program that alters the device's behavior ina manner not authorized by the manufacturer. In this article wepresented mechanisms to protect the software update process.

These mechanisms are an efficient countermeasure to manipulationattacks, in particular, if the boot loader in the internal Flash ROMcan be protected with security (so-called “lock”) bits.

Such mechanisms have been successfully implemented in a variety ofapplications, ranging from the automotive domain to gambling and themobile phone industry.

The German automotive OEMs even standardized the mechanism for asecure boot loader [0]. While this standard allows the use of symmetriccryptography only via a so-called message authentication code (MAC), westrongly suggest implementing the asymmetric cryptographic approachbased on digital signatures; otherwise either our original securityrequirements cannot be fulfilled or the organizational effort isimmense.

While the cryptographic mechanisms are generally straightforward toimplement, security needs to be provided at all levels, ranging fromorganization security to appropriate mechanisms for signing thefirmware up to inclusion of suppliers. In particular, the securitymechanisms need to be carefully incorporated into the existingdevelopment processes.

Dr. André Weimerskirch isChief Executive Officer (CEO) and President of American-based escryptInc. and is in charge of the international activities of escrypt. From2004 to 2007 Dr. Weimerskirch held the position of Chief TechnologyOfficer (CTO) of escrypt GmbH in Germany.

Dr. Kai Schramm is CTO of escrypt Inc., supervising thetechnical implementation of projects and providing unique expertise tocustomers. From 2006 to 2007 Dr. Schramm worked at the securityengineering group of Renesas Technologies in the UK as a consultant. Hestudied electrical engineering and computer science at PurdueUniversity in the USA and at the University of Bochum in Germany.

References
1) Christian S. Collberg andClark D. Thomborson, “Watermarking, Tamper-Proofing, and ObfuscationTools for Software Protection”, IEEE Transactions on SoftwareEngineering, vol. 28, nr. 8, 2002.

2) Hersteller InitiativeSoftware (HIS), “HISSecurity Module Specification, Version 1.1“..

3) Cullen Linn and SaumyaDebray, “Obfuscation of Executable Code to Improve Resistance to StaticDisassembly”, ACM Conference on Computer and Communications Security(CCS), 2003.

4) Marko Wolf, AndréWeimerskirch, and Thomas Wollinger, “State-of-the-Art: EmbeddingSecurity in Vehicles”, EURASIP Journal on Embedded Systems, SpecialIssue on Embedded Systems for Intelligent Vehicles, 2007.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.