AlterationOutline.txt

Intro
	-> Why do this?
		-> Current design ideals incorrect
			-> Security needs to be a 1st round element is system design
		-> Protect the function of the system
		-> Protect the design of a secure system
			-> Anti: tampering, cloning, reverse engineering
	-> PBD (overview)
		-> Security not in the thought process of PBD
Related Work
	-> Low level concepts
		-> Flaws
	-> Hardware implementations
		-> Flaws
	-> Security primitives
		-> Flaws
	-> PBD implementations
		-> Flaws
Proposed Approach
	-> Requirement Specifications
		-> High-level requirements: data1 must remain private to some cost value (time, money), system functionality must remain private to some cost value (time, money)
		-> How to go about protecting data to keep it private? This gets us from high-level behavioral requirements down to implementation (level of abstraction down)
			-> Work downwards to lower level design and development
	-> Component Definitions
		-> Security Properties
			-> If a processor would need: cryptographic function, TPM, secure keys, PUF, uniform/obfuscated implementation (to prevent side channel attacks; branch of confidentiality), unexposed pins (BGA), power drain/usage, integrity of data/information, anti-tampering, anti-reverse engineering
				-> PUF (Physical Unclonable Function): reason to use PUF is that it is based on process variations (hardware variations; temp, age, leakage, component properties, voltage, jitter, noise, etc.) which makes it very difficult if not impossible to predect or model, mainly used for key generation and ID extraction purposes (authentication).  Three main properties of PUF are: reliability, uniqueness, and randomness (of the output data).  It should be noted that the properties of relibaility and randomness conflict and it is required that a balance be struck during the design and development stage. PUF is a prevention method; in that PUF can be used to ensure that the system is operating as expected.
					-> From Sara's paper: better resiliance against tampering compared to other solutions, PUF input and ouput nets are maps of challenges and responses which are refered to as `Challenge-Response Pairs' (CRPs), two broad categories for PUFs (strong PUF and weak PUF); where strong PUFs are used for authentication and weak PUFs are used for key generation (the reason being that strong PUFs can handle a larger number of CRPs), three types of PUF; cover-based (based on physical optic/electric properties of the system; e.g. light scattering, dieletric coefficient), memory-based (based on properties of memory (start-up behavior); DRAM/SRAM/Flash PUF), delay-based (based on delay of operations by components; Arbiter PUF)
					-> Mention/Combine first about reason to use PUF and what are PUF's input/ouput, then characteristics of PUFs, what are the types of PUFs, why would I ever want to use PUFs (they are good)
			-> If memory would need: maintaining protection, strength of encryption (of disk/space), `hidden' pins (BGA), memory based PUF
		-> What happens when unable to trust components
			-> Secure system built from unsecure components
			-> Examine Root-of-Trust (e.g. TPM)
			-> System is ONLY as secure as it's least secure component
				-> How to evaluate secure
					-> Overhead brought into initial system state to validate all of this on the fly (perhaps pre-validate)
				-> Other method is to know that all components are trustworthy and thus do not require validation
	-> Mapping
		-> Mapping is difficult
		-> Need a method for comparing arbitrary values/rankings
			-> Would require comparision of properties such as trustworthiness, relibaility, fidelity, etc.
		-> Documentation and standardization is required for a mapping function/framework to be developed
		-> Virtualization aids in exploration of the development/design space
		-> Time is the most expensive and omni-present cost of development
		
		-> Development considerations
			-> Disaster planning
			-> Upgrade/Modification paths
		
		-> Point out security considereations that a mapping function may need to account for
			-> Principles and functionality that may need to be maintained
			-> Different scope considerations for security (local, network, distributed)
	-> Documentation
		-> A necessary evil
		-> Documentation is good
		-> Documentation leads to better virtualization and automation of tools
		-> Leads to need for user documentation
		-> Leads to better adoptability
Restate point being made
	-> Security needs to be implemented 1st in design
	-> Use PBD as a design methodology 
	-> Proposed application is an attempt to tackle the open ended problem of mapping high-level requirements to component hardware/function
Conclusion