From a5b17d821ff83f8c0183c0fc02dd12cb3b8041d1 Mon Sep 17 00:00:00 2001 From: Paul Wortman Date: Sat, 11 Jul 2015 18:16:08 -0400 Subject: [PATCH] Additions to PBDSec paper - Addition of Sources - Changes to paper contents - Additional Citings added Signed-off-by: Paul Wortman --- PBDSecPaper.tex | 111 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 99 insertions(+), 12 deletions(-) diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex index c479c51..58b9dd8 100644 --- a/PBDSecPaper.tex +++ b/PBDSecPaper.tex @@ -79,19 +79,14 @@ \begin{abstract} \begin{itemize} -\item PBD centers around minimizing costs of developing and manufacturering new components along with changing the landscape of this ecosystem, through the use of a ``meet-in-the-middle'' methodology where successive refinements of specificiations meet with abstractions of pototential implemenetations; the goal being to obtain the same level of abstraction as is writtien into good coding functions.~\cite{Vincentelli2002} Security centers around being able to gauge the trustworthiness of components as well as the larger system made of distributed components. There is a distinct lack of design methodology for doing platform-based design of security elements, although there is conceptual use in mobile embedded systems. \textbf{[Add citation(s) here]} +\item PBD centers around minimizing costs of developing and manufacturering new components along with changing the landscape of this ecosystem, through the use of a ``meet-in-the-middle'' methodology where successive refinements of specificiations meet with abstractions of pototential implemenetations; the goal being to obtain the same level of abstraction as is writtien into good coding functions~\cite{Vincentelli2002}. Security centers around being able to gauge the trustworthiness of components as well as the larger system made of distributed components. There is a distinct lack of design methodology for doing platform-based design of security elements, although there is conceptual use in mobile embedded systems~\cite{Schaumont2005}. % and imaging~\cite{Sedcole2006}. \item Ground work for implementing security via PBD exists; this paper is centered around connecting the dots and laying the foundation for framework that will be built upon for creating security in a doucmented, rigorous, standardized way. \end{itemize} \end{abstract} \section{Motivation} \label{Motivation} -\begin{itemize} -\item As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic 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 abstraction solution is then used for a variety of tasks, ranging from arithmatic to system behavior. It is an industry standard to use SoC to handle encryption/security in a secure and removed manner. -\item 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. This is the same sort of ``abstraction bridge'' that is required by the ``meet-in-the-middle'' methodology of PBD, along with the sort of software construct that benefits the virtualization of security component mapping. -\item ``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} -\item \textbf{\textit{Add something about previous security work; taxonomy?}} -\end{itemize} +As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic 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 abstraction solution is then used for a variety of tasks, ranging from arithmatic 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. This is the same sort of ``abstraction bridge'' that is required by the ``meet-in-the-middle'' methodology of PBD, along with the sort of software construct that benefits the virtualization of security component mapping. ``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} Work in the security realm is much more chaotic, although understakings have been made to define the scope of security and its intrecacies 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{Lin2013, Avizienis2004, Jorgen2008, Zakinthinos1997, Zhou2007}. A key developing aspect of security is its standardization of encryption algorithms, methods of authentication, and communication protocols. \begin{itemize} \item Standardization is the process of developing and implementing technical standards. Standardization can help to maximinze compatability, interoperability, safety, repeatability, or quality; it can also faciliate commoditization of formerly custom processes. Standards appear in all sorts of domains. @@ -104,11 +99,11 @@ \section{Motivation} \begin{itemize} \item The advatange to this method is ease of changes in development and searching of design spaces during early design and development of those systems. For PBD this means that a company/manufacturer is able to lower the cost and time spent in the `early development phase'; the time spent when first drawing up system designs prior to initial prototyping. While the advantage of overcoming multiple prototpying re-designs with a series of virtualization tools will cut down on development time, it can not be forgotten that the rigorous standards and documentation need to be developed for this sort of advantage. Once this hurdle is passed then the advantages of such a system can be reaped. For security this means that components can be standardized from a local, network, and distributed standpoint. These different scopes of security will be tackled in Section~\ref{Security}. The main point here is that with standardization comes a form of `contract' that all parties can expect will be followed, thus allowing for a different manufacturers/developers to create different aspect while knowing that these different elements will come together in the final product; much like the advantages of platform-based design. \item The disadvantage of using a new method is the loss in time for developing the standards, rigors, and documentation that would be used as new standards for the industry. The other disadvantage is in the adoptability of these new methods and designs. Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best''). - \item Virtualization will help offset the time and monetary costs in the long run. Essentially the issue boils down to how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block). A new set of tools needs to be developed that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks. Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks. As with any new system, there is a need for `tunable desings' that can be centered around specific aspects (e.g. power/energy efficient systems to minimize ``power cost buildup'', or security/trust centric needs). Functions, in this tool set, should be kept simple (e.g. decide output, \textbf{but} not how the output manifests). The reason behind this is that the design can remain simplistic in its design and operation. Virtualization tools lend to both the ideas of abstraction (choosing the simple output) and standardization/documentation (know what the outputs are, but not needing to know exactly how they manifest; just that they will). They are a much needed tool for exploring design spaces and bringing codesign of software and hardware elements. + \item Virtualization will help offset the time and monetary costs in the long run. Essentially the issue boils down to how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block). A new set of tools needs to be developed that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks. Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks. As with any new system, there is a need for `tunable desings' that can be centered around specific aspects (e.g. power/energy efficient systems to minimize ``power cost buildup'', or security/trust centric needs). Functions, in this tool set, should be kept simple (e.g. decide output, \textbf{but} not how the output manifests). The reason behind this is that the design can remain simplistic in its design and operation. Virtualization tools lend to both the ideas of abstraction (choosing the simple output) and standardization/documentation (know what the outputs are, but not needing to know exactly how they manifest; just that they will)~\cite{Alagar2007}. They are a much needed tool for exploring design spaces and bringing codesign of software and hardware elements. \end{itemize} \item Hardware/Software Codesign \begin{itemize} - \item There are different coding languages to handle different aspects (i.e. SW/HW) of vitrualization. When dealing with the virtualization of software the aspects of timing and concurrenccy semantics still fall short. These problems come from a lack of resolution and control at the lowest levels of virtualization interaction. The overwhelming hardware issue is that hardware semantics are very specific and tough to simulate. There has been the development of hardware simulation languages, such as SystemC, but there has not been the development of tools to bridge the space between hardware and software simulation/virtualization. Codesign of software simulations of hardware allows for development of high level software abstraction to interact with low level hardware abstraction. + \item There are different coding languages to handle different aspects (i.e. SW/HW) of vitrualization. When dealing with the virtualization of software the aspects of timing and concurrenccy semantics still fall short. These problems come from a lack of resolution and control at the lowest levels of virtualization interaction. The overwhelming hardware issue is that hardware semantics are very specific and tough to simulate. There has been the development of hardware simulation languages, such as SystemC~\cite{Kreku2008}, but there has not been the development of tools to bridge the space between hardware and software simulation/virtualization. Codesign of software simulations of hardware allows for development of high level software abstraction to interact with low level hardware abstraction. \item Future considerations (end of Jurgen Teich paper~\cite{Teich2012}) \begin{itemize} \item System-on-chip (SoC) technology will be alreadu dominated by 100-1000 core multiprocessing on a chip by 2020~\cite{Teich2012}. Changes will affect the way companies design embedded software and new languages, and tool chains will need to emerge in order to cope with the enormous complexity. Low-cost embedded systems (daily-life devices) will undoubtably see development of concurrent software and exploitation of parallelism. In order to cope with the desire to include environment in the design of future cyber-physical systems, the heterogeneity will most definitely continue to grow as well in SoCs as in distributed systems of systems. @@ -128,7 +123,7 @@ \section{Platford-based design} \begin{itemize} \item PBD (Platform-based design) \begin{itemize} - \item The monetary considerations of platform-based design include system re-use, flexibility of elements, and re-programmability. As system complexity grows the costs of producing chips becomes more expensive, thus pushing for the systems that are produced to be ``multi-capable'' (e.g. re-use value)~\cite{Keutzer2000}. The greatest challenge in the hardware design space is placement and arragement of components based on an array of differing variables. Design of architecture platforms is result of trade-off in complex space, and worse yet some aspects directly compete/contradict each other~\cite{Vincentelli2002}. + \item The monetary considerations of platform-based design include system re-use, flexibility of elements, and re-programmability. As system complexity grows the costs of producing chips becomes more expensive, thus pushing for the systems that are produced to be ``multi-capable'' (e.g. re-use value)~\cite{Keutzer2000}. The greatest challenge in the hardware design space is placement and arragement of components based on an array of differing variables. Design of architecture platforms is result of trade-off in complex space, and worse yet some aspects directly compete/contradict each other~\cite{Vincentelli2002, Gruttner2013}. \begin{itemize} \item The size of the application space that can be supported by the architectures belonging to the architecture platform represents the flexability of the platform. The size of the architecture space that satisfies the constraints embodied in the design architecture is what providers/manufacturers have in designing their hardware instances. Even at this level of abstraction these two aspects of hardware design can compete with each other. Ex: A manufacturer has pre-determined sizes that constrain their development space apriori. Further more, aspects such as design space constraints and heat distribution are a well known source of trouble when designing embedded systems. \end{itemize} @@ -147,7 +142,7 @@ \section{Security} \label{Security} \begin{itemize} \item Evolving with time and understanding as knowledge of encryption and other security encapsulation techniques. There are considerations that are accounted from a software standpoint: capabilities of the software, speed of the algorthims/actions that take place, and how unique (level of uniqueness) a given solution is. Similarly there are hardware considerations as well: tolerance of the chip elements in use, their capabilities, power distribution over the entire hardware design, signal lag between different elements, and cross-talk caused by communication channels. Different groups have tackled aspects of these considerations. -\item The Trusted Computing Group (TCG) created Trusted Platform Modules (TPM) which are able to validate their own functionality and if they have been tampered with. This is, in essence, a method of `self-analysis'; thus the ground work for a `self-analyzing' security component is already in place. This self checking can be used as a method for allowing the larger system of security components to locate damaged/error-prone componenets so that they can be replaced/fixed thus raising the overall trustworthiness of the system of components. +\item The Trusted Computing Group (TCG) created Trusted Platform Modules (TPM) which are able to validate their own functionality and if they have been tampered with. This is, in essence, a method of `self-analysis'; thus the ground work for a `self-analyzing' security component is already in place. This self checking can be used as a method for allowing the larger system of security components to locate damaged/error-prone componenets 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'' yet~\cite{Sadeghi2008}. \item The definition of ``trustworthiness'' that is chosen to help color this perspective on security is as defined in the Benzel et.~al.~paper. \begin{quotation} ``\textit{Trustworthy} (noun): the degree to which the security behavior of the component is demonstrably compliant with its stated functionality (\textit{e.g., trustworthy component}). \\ \textit{Trust}: (verb) the degree to which the user or a component depends on the trustworthiness of another component. For example, component A \textit{trusts} component B, or component B is \textit{trusted} by component A. Trust and trustworthiness are assumed to be measured on the same scale.''~\cite{Benzel2005} @@ -155,7 +150,7 @@ \section{Security} \begin{itemize} \item Dependability is a measure of a system's availability, reliability, and its maintainability. Furthermore, Avizienis et.~al.~extends this to also encompass mechanisms designs to increase and maintain the dependability of a system~\cite{Avizienis2004}. For the purpose of this paper, the interpretation is that trustworthiness requires inherrent dependability; i.e. a user should be able to trust that trustworthy components will dependably perform the desired actions and alert said user should an error/failure occur. \item Unfortunately the measurement of trust(worthiness) is measured by the same, abstract scale~\cite{Benzel2005}. Thus, in turn, there is a void for the design and development of an understandable and standardized scale of trust(worthiness). Which could then lead to a change of paradigm in the methods by which security policies, mechanisms, and principles are implemented and evolve. - \item ``In order to develop a component-based trustworthy system, the development process must be reuse-oriented, component-oriented, and must integrate formal languages and rigorous methods in all phases of system life-cycle.''~\cite{Mohammed2009} Component-Based Software Engineering (CBSE) is widely adopted in the software industry as the mainstream approach to software engineering~\cite{Mohammed2009}. CBSE is a reuse-based approach of defining, implementing and composing loosely coupled independent components into systems and emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. Thus it can be seen that the ideals being outlined in this paper are already in use, all that is needed is their re-application to a new design methodology. + \item ``In order to develop a component-based trustworthy system, the development process must be reuse-oriented, component-oriented, and must integrate formal languages and rigorous methods in all phases of system life-cycle.''~\cite{Mohammed2009} Component-Based Software Engineering (CBSE) is widely adopted in the software industry as the mainstream approach to software engineering~\cite{Mohammed2009, Mohammad2013}. CBSE is a reuse-based approach of defining, implementing and composing loosely coupled independent components into systems and emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. Thus it can be seen that the ideals being outlined in this paper are already in use, all that is needed is their re-application to a new design methodology. \item ``Most prevalent trust models only focus on assessing trustworthiness of systems at runtime, and do not provide necessary predictions of the trust of systems before they are built. This makes imporving trustworthiness of the composed system to be costly and time-consuming. Therefore it is important to consider trust of the composed software system at the development time itself.''~\cite{Gamage} \end{itemize} \item Scopes of security/trustworthiness @@ -252,6 +247,98 @@ \section{Conclusion} \bibitem{Avizienis2004} Algirdas Avi\v{z}ienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, \emph{ Basic Concepts and Taxonomy of Dependable and Secure Computing}, IEEE Transactions on Dependable and Secure Computing (October 2004) +\bibitem{Lin2013} Chung-Wei Lin, Qi Zhu, Calvin Phung, and Alberto Sangiovanni-Vincentelli, \emph{ +Security-Aware Mapping for CAN-Based Real-Time Distributed Automotive Systems}, IEEE/ACM ICCAD (November 2013) + +\bibitem{Zakinthinos1997} Aris Zakinthinos, and E.S.~Lee, \emph{ +A General Theory of Security Properties}, IEEE Proceedings Symposium on Security and Privacy (May 1997) + +\bibitem{Jorgen2008} J{\"o}rgen Hansson, Peter H.~Feiler, and John Morley, \emph{ +Building Secure Systems using Model-Based Engineering and Architectural Models}, (2008) + +\bibitem{Canedo2013} Arquimedes Canedo, Eric Schwarzenbach, and Mohammad Abdullah Al Faruque, \emph{ +Context-sensitive Synthesis of Executable Functional Models of Cyber-Physical Systems}, ACM/IEEE ICCPS (April 2013) + +\bibitem{Cimatti2012} Alessandro Cimatti, and Stefano Tonetta, \emph{ +A Property-Based Proof System for Contract-Based Design}, EUROMICRO Conference on SEAA (September 2012) + +\bibitem{Aedo2012} A.~Benavides, J.~Aedo, and F.~Rivera, \emph{Multi-purpose System-on-Chip Platform for Rapid Prototyping}, IEEE LASCAS (March 2012) + +\bibitem{Jorgen2010} J{\"o}rgen Hansson, Lutz Wrage, Peter H.~Leiler, John Morley, Bruce Lewis, and J{\'e}r{\^o}me Hugues, \emph{ +Architectural Modeling to Verify Security and Nonfunctional Behavior}, IEEE Security \& Privacy (Feb 2010) + +\bibitem{Gerstlauer2009} Andreas Gerstlauer, Christian Haubelt, Andy D.~Pimentel, Todor P.~Stefanov, Daniel D.~Gajski, J{\"u}rgen Teich, \emph{ +Electronic System-Level Synthesis Methodologies}, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (September 2009) + +\bibitem{Gronbaek} Inge Gr{\o}nb{\ae}k, \emph{ +Architecture for the Internet of Things (IoT): API and interconnect}, SENSORCOM (August 2008) + +\bibitem{Vivekanandarajah2008} Kugan Vivekanandarajah and Santhosh Kumar Pilakkat, \emph{ +Task Mapping in Heterogeneous MPSoCs for System Level Design}, IEEE ICECCS (April 2008) + +\bibitem{Pimentel2006} Andy D.~Pimentel, Cagkan Erbas, Simon Polstra, \emph{ +A Systematic Approach to Exploring Embedded System Architectures at Multipl Abstraction Levels}, IEEE Transactions on Computers (February 2006) + +\bibitem{Schaumont2005} Patrick Schaumont, David Hwang, and Ingrid Verbauwhede, \emph{ +Platform-Based Design for an Embedded-Fingerprint-Authentication Device}, IEEE Transactions on Computer-Aided Design on Integrated Circuits and Systems (November 2005) + +\bibitem{Benveniste2007} Albert Renveniste, Beno{\^i}t Cailaud, and Proberto Passerone, \emph{ +A Generic Model of Contracts for Embedded Systems}, Research Report (June 2007) + +\bibitem{Ren2006} Jie Ren, \emph{ +A Connector-Centric Approach to Architectureal Access Control}, Dissertation (2006) + +\bibitem{Zhou2007} Jie Zhou and Jim Alves-Foss, \emph{ +Security Policy Refinement and Enforcement for the Design of Multi-level Secure Systems}, Journal of Computer Security (2007) + +\bibitem{Sedcole2006} Nicholas Peter Sedcole, \emph{ +Reconfigurable Platform-Based Design in FPGAs for Video Image Processing}, Doctoral Thesis, University of London (January 2006) + +\bibitem{Benveniste2012} Albert Benveniste, Benoit Caillaud, Dejan Nickovic, Roberto Passerone, Jean-Baptiste Raclet, Philipp Reinkemeier, Alberto Sangiovanni-Vincentelli, Werner Damm, Thomas Henzinger, Kim G.~Larsen, \emph{ +Contracts for System Design}, Research Report (November 2012) + +\bibitem{Pinto2006} Alessandro Pinto, Alvise Bonivento and Alberto L.~Sangiovanni-Vincentelli, \emph{ +System Level Design Paradigms: Platform-Based Design and Communication Synthesis}, ACM Transactions on Design Automation of Electronic Systems (TODAS) (July 2006) + +\bibitem{Bonivento2006} Alvise Bonivento, Luca P.~Carloni, Alberto Sangiovanni-Vincentelli, \emph{ +Platform Based Design for Wireless Sensor Networks}, Mobile Networks and Applications (August 2006) + +\bibitem{Vincentelli2004} Alberto Sangiovanni-Vincentelli, Luca Carloni, Fernando De Bernardinis, and Marco Sgroi, \emph{ +Benefits and Challenges for Platform-Based Design}, Proceedings of the 41st annual Design Automation Conference (2004) + +\bibitem{Pellizzoni2009} Rodolfo Pellizzoni, Patrick MEredith, Min-Young Nam, Mu Sun, Marco Caccamo, and Lui Sha, \emph{ +Handling Mixed-Criticality in SoC-based Real-Time Embedded Systems}, EMSOFT (2009) + +\bibitem{Wu2006} Min Wu, Xiaoyang Zeng, Jun Han, Yongyi Wu, and Yibo Fan, \emph{ +A High-Performance Platform-Based SoC for Information Security}, Proceedings of the 2006 Asia and South Pacific Design Automation Conference (2006) + +\bibitem{Kreku2008} Jari Kreku, Mika Hoppari, Tuomo Kestil{\"a}, Yang Qu, Juha-Pekka Soininen, Per Andersson, and Kari Tiensyrj{\"a}, \emph{ +Combining UML2 Application and SystemC Platform Modelling for Performance Evaluation of Real-Time Embedded Systems}, Journal on Embedded Systems - C-Based Design of Heterogeneous Embedded Systems (January 2008) + +\bibitem{Irvine2007} Cynthia E.~Irvine and Karl Levitt, \emph{ +Trusted Hardware: Can It Be Trustworthy?}, Proceedings of the 44th annual Design Automation Conference (2007) + +\bibitem{Mohammad2013} Mubarak Sami Mohammad, \emph{ +A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems}, Doctoral Thesis (January 2013) + +\bibitem{Sadeghi2008} Ahmad-Reza Sadeghi, \emph{ +Trusted Computing - Special Aspects and Challenges}, SOFSEM 2008: Theory and Practice of Computer Science (2008) + +\bibitem{Lee2001} Edward A.~Lee and Yuhong Xiong, \emph{ +System-Level Types for Component-Based Design}, Embedded Software Lecture Notes in Computer Science Volume 2211 (2001) + +\bibitem{Bush2003} Stephen F.~Bush, \emph{ +Extended Abstract: Complexity and Vulnerability Analysis}, DIMACS Workshop on Complexity and Inference (June 2003) + +\bibitem{Gamatie2011} Abdoulaye Gamati{\'e}, S{\'e}bastien Le Beux, {\'E}ric Piel, Rabie Ben Atitallah, Anne Etien, Philippe Marquet, and Jean-Luc Dekeyser, \emph{ +A Model-Driven Design Framework for Massively Parallel Embedded Systems}, ACM Transactions on Embedded Computing Systems (November 2011) + +\bibitem{Alagar2007} Vasu Alagar and Mubarak Mohammad, \emph{ +A Component Model for Trustworthy Real-Time Reactive Systems Development}, FACS (2007) + +\bibitem{Gruttner2013} Kim Gr{\"u}ttner, Philipp A.~Hartmann, Kai Hylla, Sven Rosinger, Wolfgang Nebel, Fernando Herrera, Eugenio Villar, Carlo Brandolese, William Fornaciari, Gianluca Palermo, Chantal Ykman-Couvreur, Davide Quaglia, Francisco Ferrero, and Ra{\'u}l Valencia, \emph{ +The COMPLEX Reference Framework of HW/SW Co-Design and Power Management Supporting Platform-Based Design-Space Exploration}, Microprocessors and Microsystems Volume 37, Issue 8 (November 2013) + \end{thebibliography} \end{document}