-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Push of starting outline to git repo
Signed-off-by: Paul Wortman <paul.mauddib28@gmail.com>
- Loading branch information
Showing
2 changed files
with
573 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,216 @@ | ||
| % template-v1.tex: LaTeX2e template for Usenix papers. | ||
| % Version: usetex-v1, 31-Oct-2002 | ||
| % Revision history at end. | ||
|
|
||
| \documentclass[XXX,endnotes]{usetex-v1} | ||
| % Choose the appropriate option: | ||
| % | ||
| % 1. workingdraft: | ||
| % | ||
| % For initial submission and shepherding. Features prominent | ||
| % date, notice of draft status, page numbers, and annotation | ||
| % facilities. The three supported annotation macros are: | ||
| % \edannote{text} -- anonymous annotation note | ||
| % \begin{ednote}{who} -- annotation note attributed | ||
| % text to ``who'' | ||
| % \end{ednote} | ||
| % \HERE -- a marker that can be left | ||
| % in the text and easily | ||
| % searched for later | ||
| % 2. proof: | ||
| % | ||
| % A galley proof identical to the final copy except for page | ||
| % numbering and proof date on the bottom. Annotations are | ||
| % removed. | ||
| % | ||
| % 3. webversion: | ||
| % | ||
| % A web-publishable version, uses \docstatus{} to indicate | ||
| % publication information (where and when paper was published), | ||
| % and page numbers. | ||
| % | ||
| % 4. finalversion: | ||
| % | ||
| % The final camera-ready-copy (CRC) version of the paper. | ||
| % Published in conference proceedings. This doesn't include | ||
| % page numbers, annotations, or draft status (Usenix adds | ||
| % headers, footers, and page numbers onto the CRC). | ||
| % | ||
| % If several are used, the last one in this list wins | ||
| % | ||
|
|
||
| % | ||
| % In addition, the option "endnotes" permits the use of the | ||
| % otherwise-disabled, Usenix-deprecated footnote{} command in | ||
| % documents. In this case, be sure to include a | ||
| % \makeendnotes command at the end of your document or | ||
| % the endnotes will not actually appear. | ||
| % | ||
|
|
||
| % These packages are optional, but useful | ||
| \usepackage{epsfig} % postscript figures | ||
| \usepackage{url} % \url{} command with good linebreaks | ||
| %\usepackage[showframe]{geometry} % http://ctan.org/pkg/geometry | ||
| \usepackage{graphicx} % http://catn.org/pkg/graphicx | ||
|
|
||
| \begin{document} | ||
|
|
||
| \title{Mapping Security to Platform-Based Design} | ||
|
|
||
| % document status: submitted to foo, published in bar, etc. | ||
| \docstatus{Submitted to Cool Stuff Conference 2002} | ||
|
|
||
| % authors. separate groupings with \and. | ||
| \author{ | ||
| \authname{Paul A.\ Wortman} | ||
| \authaddr{ECE} | ||
| \authaddr{University of Connecticut} | ||
| \authaddr{ Storrs, CT, 06279} | ||
| \authurl{\url{paul.wortman@engr.uconn.edu}} | ||
| \authurl{\url{http://host.dom/yoururl}} | ||
| %\and | ||
| %\authname{Name Two} | ||
| %\authaddr{Two's Institution} | ||
| %\authurl{\url{two@host.dom}} | ||
| % | ||
| } % end author | ||
|
|
||
| \maketitle | ||
|
|
||
| \begin{abstract} | ||
| \begin{itemize} | ||
| \item Lack of design/methodology for doing platform-based design of security elements, although conceptual use in mobile embedded systems. | ||
| \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{Previous Work} | ||
| \label{Previous Work} | ||
| \begin{itemize} | ||
| \item Middleware security (having translation software for communicating from lower level to a higher level) | ||
| \begin{itemize} | ||
| \item ``In this dissertation, the term middleware describes software that resides between an application and the inner workings of the system hosting the application, and that abstracts the complexities of the underlying technology from the application layer.''~\cite{Lang2003} | ||
| \end{itemize} | ||
| \item Use of system-on-chip (SoC) to replace multi-chip solutions. | ||
| \begin{itemize} | ||
| \item Use of SoC to handle encryption/security in a secure and removed manner. | ||
| \end{itemize} | ||
| \end{itemize} | ||
|
|
||
| \section{Considerations} | ||
| \label{Considerations} | ||
| \begin{itemize} | ||
| \item What standardization is important | ||
| \item Hardware/Software Codesign | ||
| \begin{itemize} | ||
| \item Previous issues and considerations | ||
| \begin{itemize} | ||
| \item Codesign of software simulations of hardware allows for development of high level software abstraction to interact with low level hardware abstraction(?) | ||
| \end{itemize} | ||
| \item Future considerations (end of Jurgen Teich paper~\cite{Teich2012}) | ||
| \end{itemize} | ||
| \item PBD (Platform-based design) | ||
| \begin{itemize} | ||
| \item Monetary considerations: re-use, flexibility of elements, re-programmable | ||
| \item ``In PBD, the partitioning of the design into hardware and software is not the essence of system design as many think, tather it is a consequence of decisions taken at a higher level of abstraction.''~\cite{Vincentelli2007} | ||
| \begin{itemize} | ||
| \item ``Critical decisions are about the architecture of the system, e.g., processors, buses, hardware accelerators, and memories, that will carry on the computation and communication tasks associated with the overall specification of the design.''~\cite{Vincentelli2007} | ||
| \end{itemize} | ||
| \item ``In the PBD refinement-based design process, platforms should be defined to eliminate large loop iterations for affordable designs.''~\cite{Vincentelli2007} | ||
| \begin{itemize} | ||
| \item ``The should restrict the design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass sucess. The library of functional and communication components is the design space that we are allowed to explore at the appropriate level of abstraction.''~\cite{Vincentelli2007} | ||
| \end{itemize} | ||
| \item ``Establishing the number, location, and components of intermediate ``platforms'' is the essence of PBD.''~\cite{Vincentelli2007} | ||
| \begin{itemize} | ||
| \item ``In fact, designs with different requirements and specification may use different intermediate platforms, hence different layers of regularity and design-space constraints. The tradeoffs involved in the selection of the number and characteristics of platforms relate to the size of the design space to be explored and the accuracy of the estimation of the chracteristics of the solution adopted. Naturally, the larger the step across platforms, the more difficult is predicting performance, optimizing at the higher levels of abstraction, and providing a tight lower bound. In fact, the design space for this approach may actually be smaller than the one obtained with smaller steps because it becomes harder to explore meaningful design alternatives and the restriction on search impedes complete design-space exploration. Ultimately, predictions/abstractions may be so inaccurate that design optimizations are misguided and the lower bounds are incorrect.''~\cite{Vincentelli2007} | ||
| \end{itemize} | ||
| \item ``The identification of precisely defined layers where the mapping processes take place is an important design decision and should be agreed upon at the top design management level.''~\cite{Vincentelli2007} | ||
| \begin{itemize} | ||
| \item ``Each layer supports a design stage where the performance indexes that characterize the architectural components provide an opaque abstraction of lower layers that allows accurate performance estimations used to guide the mapping process.''~\cite{Vincentelli2007} | ||
| \end{itemize} | ||
| \item ``This approach results in better reuse, because it decouples independent aspects, that would otherwise be tired, e.g., a given functional specification to low-level implementation details, or to a specific communication paradigm, or to a scheduling algorithm.''~\cite{Vincentelli2007} | ||
| \begin{itemize} | ||
| \item ``It is very important to define only as many aspects as needed at every level of abstraction, in the interest of flexibility and rapid design-space exploration.''~\cite{Vincentelli2007} | ||
| \end{itemize} | ||
| \end{itemize} | ||
| \end{itemize} | ||
|
|
||
| \section{Security} | ||
| \label{Security} | ||
| \begin{itemize} | ||
| \item Hardware: tolerance, capabilities, power distribution, signal lag, cross-talk | ||
| \begin{itemize} | ||
| \item PUF? (Think layer above this) | ||
| \end{itemize} | ||
| \item Software: capabilities, speed, uniqueness | ||
| \item How to define ``trustworthiness''? | ||
| \begin{itemize} | ||
| \item Differentiate between trustworthy and dependable | ||
| \item How does one measure trust? | ||
| \begin{itemize} | ||
| \item Arbitrary scale of trust; needs to be understandable/standardized | ||
| \end{itemize} | ||
| \end{itemize} | ||
| \item Scopes of security/trustworthiness | ||
| \begin{itemize} | ||
| \item Local (self) | ||
| \item Network (communication) | ||
| \item Within distributed system | ||
| \end{itemize} | ||
| \item Mapping of Security onto PBD structure | ||
| \end{itemize} | ||
|
|
||
| \section{Conclusion} | ||
| \label{Conclusion} | ||
| \begin{itemize} | ||
| \item Need for development of platform-based design for security elements of all types | ||
| \item Advantages: swap out old security modules with newer ones (re-use of base system), degree of system customization to meet system hardware/software needs | ||
| \end{itemize} | ||
|
|
||
| %references section | ||
| %\bibliographystyle{plain} | ||
| %\bibliography{body} | ||
|
|
||
| \begin{thebibliography}{99} | ||
|
|
||
| \bibitem{Vincentelli2007} Alberto Sangiovanni-Vincentelli, | ||
| \emph{Quo Vadis, SLD? Reasoning About the Trends and Challeneges of System Level Design}, Proceedings of the IEEE (March 2007) | ||
|
|
||
| \bibitem{Teich2012} J{\"u}rgen Teich, | ||
| \emph{Hardware/Software Codesign: The Past, the Present, and Predicting the Future}, Proceedings of the IEEE (May 2012) | ||
|
|
||
| \bibitem{Lang2003} Ulrich Lang, | ||
| \emph{Access policies for middleware}, University of Cambridge (May 2003) | ||
|
|
||
| \end{thebibliography} | ||
|
|
||
| \end{document} | ||
|
|
||
| % Revision History: | ||
| % designed specifically to meet requirements of | ||
| % TCL97 committee. | ||
| % originally a template for producing IEEE-format articles using LaTeX. | ||
| % written by Matthew Ward, CS Department, Worcester Polytechnic Institute. | ||
| % adapted by David Beazley for his excellent SWIG paper in Proceedings, | ||
| % Tcl 96 | ||
| % turned into a smartass generic template by De Clarke, with thanks to | ||
| % both the above pioneers | ||
| % use at your own risk. Complaints to /dev/null. | ||
| % make it two column with no page numbering, default is 10 point | ||
|
|
||
| % Munged by Fred Douglis <douglis@research.att.com> 10/97 to separate | ||
| % the .sty file from the LaTeX source template, so that people can | ||
| % more easily include the .sty file into an existing document. Also | ||
| % changed to more closely follow the style guidelines as represented | ||
| % by the Word sample file. | ||
| % This version uses the latex2e styles, not the very ancient 2.09 stuff. | ||
| % | ||
|
|
||
| % Revised July--October 2002 by Bart Massey, Chuck Cranor, Erez | ||
| % Zadok and the FREENIX Track folks to ``be easier to use and work | ||
| % better''. Hah. Major changes include transformation into a | ||
| % latex2e class file, better support for drafts, and some | ||
| % layout improvements. | ||
| %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | ||
| % for Ispell: | ||
| % LocalWords: workingdraft BCM ednote SubSections xfig SubSection joe |
Oops, something went wrong.