Professional Documents
Culture Documents
Submitted By: Secure Firmware Validation and Updation A Mini Project Report
Submitted By: Secure Firmware Validation and Updation A Mini Project Report
Submitted by
of
BACHELOR OF ENGINEERING
in
COMPUTER SCIENCE
COIMBATORE – 641014
COIMBATORE INSTITUTE OF TECHNOLOGY
(A Govt. Aided Autonomous Institution Affiliated to Anna University)
COIMBATORE –641 014
BONAFIDE CERTIFICATE
Certified that the candidates were examined by us in the project work viva-voce
examination held on …………………
Place:
Date:
TABLE OF CONTENTS
ACKNOWLEDGEMENT I
ABSTRACT II
LIST OF ABBREVIATIONS III
1 INTRODUCTION 1
1.1 Firmware 1
1.3 Scope 2
2 LITERATURE SURVEY 4
3 REQUIREMENTS 8
4. PROPOSED SYSTEM 9
4.1 Server 9
4.2 Client 9
7 REFERENCES 15
LIST OF FIGURES
1 BLOCK DIAGRAM 10
Our Project, “Secure Firmware Validation and Updation” has been the
result of motivation and encouragement from many, whom we would like to
thank.
We sincerely thank all our faculty members for the advice and support in
various dimensions of the project work. We present our gratefulness to the Lab
Assistants and other non teaching staff for their timely support and assistance in
the laboratory. Finally, we like to thank our families and friends for their
appreciation and guidance.
I
ABSTRACT
Embedded systems are more than ever present in consumer electronics devices
such as home routers, personal computers. Firmware, which is embedded
software specifically designed for monitoring and control in resource
constrained conditions, was not a major attack target. However, recent serious
cyber attacks focus on firmware rather than application or operating system
levels, because exploiting the firmware level offers stealth capabilities, e.g.,
anti-virus software and operating system cannot reveal such a firmware level
exploit. A remote firmware update is required for consumer devices connected
to the Internet to improve the existing Firmware. The proposed scheme utilizes
an Eliptic Curve based mutual ID authentication and key derivation to securely
distribute a firmware image.
II
LIST OF ABBREVIATIONS
III
INTRODUCTION
CHAPTER 1
1.INTRODUCTION
1.1 FIRMWARE
Before ECC became popular, almost all public key algorithms were based on
RSA and alternative cryptosystems based on modular arithmetic. ECC produces
key with sizes far lesser than RSA and other exponential encryption algorithm.
ECC thus has the capability of being run faster than any other algorithms, thus
improve computation capabilities.
1.3 Scope:
Validate server and client before file transfer happens with lesser key size
transfers.
The suggested system would improve security of firmware updation and also
reduces computational overhead in performing authentications in resource
limited conditions like in embedded devices and smart objects.
LITERATURE SURVEY
CHAPTER 2
2. LITERATURE SURVEY:
Description:
Advantages:
Disadvantages:
Does not explain about any algorithm in specific and machine capabilities
of the client for firmware exchange.
4
2.2 A New Approach of Elliptic Curve Diffie-Hellman Key Exchange
Authors:NissaMehibel ,M’hamedHamadouche
Description:
Discussed about using elliptic curve for key exchange algorithm such as
DiffieHelmann algorithm.
Discusses in detail about how diffiehelmann with ecc can be used for key
exchange with proof for the same.
Advantages:
Hence this algorithm would perform with much higher speeds than
existing algorithms.
The paper shows proof for the same with comparisons with other
algorithms.
Disadvantages:
Does not provide basis for making the algorithm work in smaller systems
such as iot devices and so on.
Discusses about certificate transfer for choosing the curve and its
parameters and not about its computation complexity especially in
minimal hardware situations.
5
2.3 AN ELLIPTIC CURVE AUTHENTICATED KEY EXCHANGE
BASED APPROACH TO KEY INFRASTRUCTURE
Authors:Praveen Koduri
Description:
In this paper we discuss the complete key setup procedures and various
scenarios describing how confidential communication is performed once
the key has been setup and mutual authentication achieved.
2)Communicating using the key derived from the key setup process.
Advantages:
Disadvantages:
The system proposes a shared key resource for minimising the load of
computation on mobile devices.
This further will create new threats for the mobile device firmwares and
does not solve our problem statement.
6
2.4Design of ECC based Authenticated Group Key Agreement Protocol
Using Self-Certified Public Keys
Description:
The proposed protocol also gives the Join and Leave procedures which
facilitates key updation on the change of group membership.
Advantages:
Disadvantages:
Does not describe about the process of join and leave procedure for group
members for key sharing.
The only limitation of this protocol is that the key updation cost by leave
procedure is not justified as compared to the initialization cost.
7
REQUIREMENTS
I
CHAPTER 3
REQUIREMENTS
RAM : 1MB
Keyboard: 14”
8
PROPOSED SYSTEM
CHAPTER 4
PROPOSED SYSTEM
4.1 SERVER
The server has a program running it it always waiting for connections for
multiple clients. Whenever a client connects to the server , the server sends a
passcode to the client for authentication and waits for the reply. Based on the
reply, the server prompts the user whether the client is trustworthy or not.
When authenticated the server sends the URL link to the client that
consists of the firmware image that he client requests.
4.2 CLIENT
The client has a program runs only when the user at the client side wishes
to run it. The client program requests connection to server and waits for the
passcode. Once the passcode is received , the client side script generates a
signature using the ECC algorithm and authenticates it with its in-built
signature.
When the client authenticates the server , the client prompts the user to
type a passcode to be sent to the server for getting the firmware link.
9
SERVER
WEBSITE HOSTED BY
SERVER
FIRMWARE WEBSITE
3) MANAGER CLIENT
DISTRIBUTES FILE TO
IOT DEVICES . /MANAGER
IOT DEVICES
Figfi
FIGURE 1
10
DESIGN AND IMPLEMENTATION
I
CHAPTER 5
DESIGN AND IMPLEMENTATION
A desktop file to start the server side script is created in Linux and
the user can start the server using this file. This file is made executable so that
the user can double click to open the server. After opening the server , the
network connection function runs to establish a connction to the client.
FIGURE-2
After the submit button is pressed, the server sends the passcode to
the client for authentication. Once a response is got by the server , it
checks whether it is an error or not. If it is an error , then it displays it
through a message box like in the figure below.
FIGURE-3
11
If the client does not return an error then it invokes the
verify_signature function in the script and checks for validity and
authenticity. If the signature matches , then the server returns a dialog box
as shown below and sends a URL for firmware image to the client.
FIGURE-4
If there is an error then it notifies the user about the error using the
same message box as in figure-3 and exits. This is how the server side
script works.
A desktop file to start the client side script is created in Linux and
the user can start the client using this file. This file is made executable so that
the user can double click to open the client. After opening the client , the
network connection function runs to establish a connection to the server by
sending a request to the server. Once the server accepts the request , it sends a
passcode to the client that it got from the user.
FIGURE-5
12
After the submit button is pressed, the client sends the passcode to
the server for authentication. Once a response is got by the client , it
checks whether it is an error or not. If it is an error , then it displays it
through a message box like in the figure below.
FIGURE-6
If the server does not return an error then it invokes the open URL
function in the script . This opens a Mozilla Firefox browser and a new
tab for opening the URL. If an URL is received at the client side , then
mutual key authentication is completed and server and client are
validated.
FIGURE-7
13
This is how the client side script works and mutual key
authentication is done.
14
CONCLUSION AND FUTURE SCOPE
CHAPTER 6
14
REFERENCES
I
CHAPTER 7
REFERENCES
15