![](bg2.png)
fense in depth approach. The goal of this approach
is not only to provide protection against known at-
tacks, but also to be more resistant to not-known ones.
Such a holistic approach will also offer designers a
clearer vision about security and it will allow them
to evaluate and customize security solutions in their
design during the design space exploration (i.e., the
evaluation and comparison of different design points
to find the optimal one with respect to different met-
rics) phase, based on threat models foreseen for the
device.
Although important, the development of compre-
hensive security solutions does not solve the problem
of designing secure embedded systems. In fact, em-
bedded system designers have often seen security as
a desired but not directly feasible and not critical fea-
ture. This is due to different reasons, the main one be-
ing that the organizations developing embedded soft-
ware often lack support of security specialists (Koop-
man, 2004); the introduction of security mechanisms
in embedded systems is further complicated by the
non existence of a design methodology aimed at in-
cluding security in system codesign from the early
phases of development. Designers miss both security
solutions specifically optimized for embedded sys-
tems and the information that would allow them to
easily integrate those solutions into their designs by
evaluating security-cost trade-offs. Presently, most
embedded systems are developed by using perfor-
mance and/or power driven approaches. By these
approaches, different design solutions (i.e., different
system hardware/software configurations) are evalu-
ated in a procedure called design space exploration
(Palermo et al., 2008; Alippi et al., 2004).
In this paper we discuss a design methodology
that allows designers to easily include security from
the early stages of the design process as opposes to
adding it at later stages as it is most often done cur-
rently. In this methodology, sets of security solu-
tions need to be identified and labeled with their cost
(power consumption, consumption of computing re-
sources, silicon area, memory, ...) and with a mea-
sure of their security. While it is known that an abso-
lute security metric is difficult, or even impossible,
to obtain, it is possible to measure system security
relatively to known attacks for the system considered
(Atzeni and Lioy, 2005). In most cases (e.g., different
cryptographic algorithms) it is also possible to com-
pare security provided by different solutions.
The remaining part of this paper is organized as
follows: Section 2 discusses the related work; Section
3 introduces the design methodology that we have de-
veloped; Section 4 discusses the results obtained by
applying our methodology to a case study; Section
5 presents a discussion on some key elements of the
methodology.
2 RELATED WORK
Security is a new dimension that designers should
consider throughout the design process, along with
other metrics such as cost, performance, and power
(Ravi et al., 2004). For this purpose, a security met-
ric is required. Unfortunately, though, at the moment
there is none available (Atzeni and Lioy, 2005): while
there is the possibility to compare similar security so-
lutions (e.g., different cryptographic algorithms) from
the stand point of security and cost, at present there is
no methodology to measure the security of systems.
In this paper, among the other things, we propose a
security metric that aggregates an evaluation of the
security of all different security elements. The evalu-
ation is done by considering the resistance of the se-
curity solutions to known attacks as well as their cor-
respondence to security requirements.
In the last years some effort has been put in devel-
oping security standards for systems and applications.
The NIST FIPS 140-2 (NIST, 2002) standard catego-
rizes cryptographic systems in four levels depending
on the services they offer and on the algorithms they
support. The International Organization for Standard-
ization (ISO) has also defined a set of standards for se-
curity in ISO/IEC 27000-series. In particular, a stan-
dard related to application security (ISO/IEC 27034)
is in early stages of its development (ISO/IEC, 2011).
In this work we rely on these standards to specify se-
curity requirements.
In (Ravi et al., 2004; Atzeni and Lioy, 2005) it
is stated importance of including security as objec-
tive in multi-objective design space exploration for
embedded systems design with the purpose of reduc-
ing power and processing overhead. In these pa-
pers, though, no methodology for including security
in design space exploration is proposed. In (Kocher
et al., 2004) it is stated that, as opposed to the other
design metrics (e.g., area, performance, power), se-
curity is currently specified by system architects in
a vague and imprecise manner. The main problem
is that security experts are the only people in a de-
sign team who have a complete understanding of the
security requirements, although different aspects of
the embedded system design process can affect se-
curity. Furthermore, (Kocher et al., 2004) suggests
that design methodologies for secure embedded sys-
tems should include techniques for specifying secu-
rity requirements in a way that can be easily com-
municated to the design team, and evaluated through-
SECRYPT2013-InternationalConferenceonSecurityandCryptography
40