Addition of PBDSec Map Space image

Addition of code for PBDSec Map image

Signed-off-by: Paul Wortman <paw10003@engr.uconn.edu>

PBDSecPaper.tex

@@ -229,10 +229,19 @@ The issue of platform-based design is not so much an over-engineering of design/
 \section{Related Work}
 \label{Related Work}
 
+As systems move towards more complex designs and implementations (as allowed by Moore's Law and other growths in technology) the ability to make even simple changes to these designs becomes exponentially more difficult.  For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development.  An example of this abstraction simplification is the use of system-on-chip (SoC) to replace multi-chip solutions.  This SoC abstraction solution is then used for a variety of tasks, ranging from arithmetic to system behavior.  It is an industry standard to use SoC to handle encryption/security in a secure and removed manner~\cite{Wu2006}.  Middleware describes software that resides between an application and the inner workings of the system hosting the application.  The purpose of the middleware is to abstract the complexities of the underlying technology from the application layer~\cite{Lang2003}; to act as translation software for communicating from lower level to a higher level.  Platform-Based Design (PBD) has been proposed as a methodology to allow for this lower-to-higher translation ``abstraction bridge'' that enables a ``meet-in-the-middle'' approach~\cite{Vincentelli2007}.  Platform-based design attempts to map applications to a platform chosen from a set of well-defined components.  These components are defined by various characteristics including performance, weight, cost, etc.  The mapping process to select architectures, platforms, and components sets out to maximize some objective function in the context of constraints and system requirements.
+
+While security in these systems is clearly important, it is rarely part of the early design process and thus, does not enter into the platform-based design process.  In this paper, we advocate for a new security aware platform-based design approach that takes into account component security attributes during platform definition.  In addition, the mapping process must incorporate security requirements as part of the objective function and constraints.
+%To date, the PBD approach to design has been along with the sort of software construct that benefits the virtualization of security component mapping.
+%\begin{quotation}
+%  ``However, even though current silicon technology is closely following the growing demands; the effort needed in modeling, simulating, and validating such designs is adversely affected.  This is because current modeling tools and frameworks, hardware and software co-design environments, and validation and verification frameworks do not scale with the rising demands.''~\cite{Patel2007} 
+%\end{quotation}
+Work in the security realm is much more chaotic, although undertakings have been made to define the scope of security and its intricacies in a well documented manner~\cite{Benzel2005}.  Other work in the security realm includes security-aware mapping for automotive systems, explorations of dependable and secure computing, how to model secure systems, and defining the general theorems of security properties~\cite{Avizienis2004, Lin2013, Zakinthinos1997, Jorgen2008, Zhou2007}.  Security has many facets to it: failure, processes, security mechanisms, security principles, security policies, trust, etc.  A key developing aspect of security is its standardization of encryption algorithms, methods of authentication, and communication protocol standards.
+
 Metropolis is one tool that is based in part on the concept of platform-based design.  Metropolis can analyze statically and dynamically functional designs with models that have no notion of physical quantities and mapped designs where the association of functionality to architectural services allows for evaluation of characteristics (e.g.~latency, throughput, power, and energy) of an implementation of a particular functionality with a particular platform instance~\cite{Vincentelli2007, Metropolis}.  Metropolis is but one manifestation of platform-based design as a tool.  PBD has been used for the platform-exploration of synthetic biological systems as seen in the work done by Densmore et.~al.~to create a strong and flexible tool~\cite{Densmore2009}.  Other applications, of platform-based design,  include design on a JPEG encoder, imaging, and use for distributed automotive design~\cite{Vincentelli2007, Teich2012, Keutzer2000, Lin2013, Gerstlauer2009, Gronbaek2008, Pimentel2006, Schaumont2005, Sedcole2006, Benveniste2012, Pinto2006, Bonivento2006, Pellizzoni2009, Kreku2008, Gamatie2011, Gruttner2013, Densmore2009}
 
-Different groups have tackled aspects of
-these considerations.  The Trusted Computing Group (TCG) created
+Different groups have tackled aspects of 
+security design and development.  The Trusted Computing Group (TCG) created
 Trusted Platform Modules (TPM) which are able to validate their own
 functionality and if the TPMs have been tampered with.  This is, in
 essence, a method of `self-analysis'; thus the ground work for a
@@ -241,7 +250,7 @@ checking can be used as a method for allowing the larger system of
 security components to locate damaged/error-prone components so that
 they can be replaced/fixed thus raising the overall trustworthiness of
 the system of components.  Therefore TPMs are a good stepping stone on
-the path for better security, but TPM/TCG has no found ``the answer''
+the path for better security, but TPM/TCG has not found ``the answer''
 yet~\cite{Sadeghi2008}.  Another example of security/trustworthiness
 implementation is the use of monitors for distributed system security.
 Different methods are used for determining trust of actions
@@ -272,6 +281,12 @@ Others are incorporating platform-based design in everything from image processi
 \subsection{Mapping}
 \label{Mapping}
 
+\begin{figure*}
+	\includegraphics[width=\textwidth,height=8cm]{./images/pbdsec_mapping.png}
+	\caption{PBD Security Map Space}
+	\label{fig:MapSpace}
+\end{figure*}
+
 As promised earlier, the paper will now examine the different scopes of security/trustworthiness: local, network, and distributed.  Each of these scopes will be examined in terms of the considerations/challenges, principles, and policies that should be used to determine action/behavior of these different security elements and the system as a whole.
 
 The local scope encompasses a security element's own abilities, trustworthiness, and the dependencies of that element (e.g. least common mechanisms, reduced complexity, minimized sharing, and the conflict between this as least common mechanisms).  The purpose of this section is to present the considerations, principles, and policies that govern the behavior and function of security elements/components at the local scope/level.  First, this paper will reiterate the definitions stated in the Benzel et.~al.~paper.  Failure is a condition in which, given a specifically documented input that conforms to specification, a component or system exhibits behavior that deviates from its specified behavior.  A module/database is seen as a unit of computation that encapsulates a database and provides an interface for the initialization, modification, and retrieval of information from the database.  The database may be either implicit, e.g. an algorithm, or explicit.  Lastly, a process(es) is a program(s) in execution.  To further define the actions/behavior of a given component in the local scope, this paper moves to outlining the principles that define component behavior at the local device level. \\
@@ -393,14 +408,6 @@ With these concepts in-mind, it should be obvious that security design \textbf{m
 
 \section{Related Work}
 \label{Related Work}
-As systems move towards more complex designs and implementations (as allowed by Moore's Law and other growths in technology) the ability to make even simple changes to these designs becomes exponentially more difficult.  For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development.  An example of this abstraction simplification is the use of system-on-chip (SoC) to replace multi-chip solutions.  This SoC abstraction solution is then used for a variety of tasks, ranging from arithmetic to system behavior.  It is an industry standard to use SoC to handle encryption/security in a secure and removed manner~\cite{Wu2006}.  Middleware describes software that resides between an application and the inner workings of the system hosting the application.  The purpose of the middleware is to abstract the complexities of the underlying technology from the application layer~\cite{Lang2003}; to act as translation software for communicating from lower level to a higher level.  Platform-Based Design (PBD) has been proposed as a methodology to allow for this lower-to-higher translation ``abstraction bridge'' that enables a ``meet-in-the-middle'' approach~\cite{Vincentelli2007}.  Platform-based design attempts to map applications to a platform chosen from a set of well-defined components.  These components are defined by various characteristics including performance, weight, cost, etc.  The mapping process to select architectures, platforms, and components sets out to maximize some objective function in the context of constraints and system requirements.
-
-While security in these systems is clearly important, it is rarely part of the early design process and thus, does not enter into the platform-based design process.  In this paper, we advocate for a new security aware platform-based design approach that takes into account component security attributes during platform definition.  In addition, the mapping process must incorporate security requirements as part of the objective function and constraints.
-%To date, the PBD approach to design has been along with the sort of software construct that benefits the virtualization of security component mapping.
-%\begin{quotation}
-%  ``However, even though current silicon technology is closely following the growing demands; the effort needed in modeling, simulating, and validating such designs is adversely affected.  This is because current modeling tools and frameworks, hardware and software co-design environments, and validation and verification frameworks do not scale with the rising demands.''~\cite{Patel2007} 
-%\end{quotation}
-Work in the security realm is much more chaotic, although undertakings have been made to define the scope of security and its intricacies in a well documented manner~\cite{Benzel2005}.  Other work in the security realm includes security-aware mapping for automotive systems, explorations of dependable and secure computing, how to model secure systems, and defining the general theorems of security properties~\cite{Avizienis2004, Lin2013, Zakinthinos1997, Jorgen2008, Zhou2007}.  Security has many facets to it: failure, processes, security mechanisms, security principles, security policies, trust, etc.  A key developing aspect of security is its standardization of encryption algorithms, methods of authentication, and communication protocol standards.
 
 Standardization is the process of developing and implementing technical standards.  Standardization can help to maximize compatibility, interoperability, safety, repeatability, or quality; it can also facilitate commoditization of formerly custom processes.  Standards appear in all sorts of domains.  For the IC domain standardization manifests as a flexible integrated circuit where customization for a particular application is achieved by programming one or more components on the chip (e.g. virtualization).  PC makers and application software designers develop their products quickly and efficiently around a standard `platform' that emerged over time.  As a quick over view of these standards: x86 ISA which makes is possible to reuse the OS \& SW applications, a full specified set of buses (ISA, USB, PCI) which allow for use of the same expansion boards of IC's for different products, and a full specification of a set of IO devices (e.g. keyboard, mouse, audio and video devices).  The advantage of the standardization of the PC domain is that software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach.  If the instruction set architecture (IAS) is kept constant (e.g. standardized) then software porting, along with future development, is far easier~\cite{Vincentelli2002}.  In a `System Domain' lens, standardization is the aspect of the capabilities a platform offers to develop quickly new applications (adoptability).  In other words, this requires a distillation of the principles so that a rigorous methodology can be developed and profitably used across different design domains.
 So why is standardization useful?  Standardization allows for manufacturers, system developers, and software designers to all work around a single, accepted, platform.  It is understood what the capabilities of the hardware are, what the limitations of system IO will be, along with what the methods/protocols of communication will be.  Even these preset aspects of the `standard' have their own `contractual obligations' of how they will function, what their respective `net-lists' are, and where the limitations of such standards lie.  While the act of creating a standard takes time, not only due to time of development but due to speed of adoption of wide use, it is a necessary step.  Without standardization, it becomes far more difficult to create universally used complex systems, let alone validate their correctness and trustworthiness.  This is how one is able to change the current paradigm to a new standard model.