CHAPTER 5: TRUSTED COMPUTING

CHAPTER 5: TRUSTED COMPUTING

1. 1. THE BELL-LAPADULA MODEL FOR COMPUTER SECURITY

   • Formal description of model
     • Based on current state of system (b, M, f, H): (current access set b, access matrix M, level function f, hierarchy H)
     • 3 BLP properties:
       • ss-property
       • *-property
       • ds-property
     • BLP give formal theorems
       • Theoretically possible to prove system is secure but not possible in practice
   • Abstract operations
   • Example of BLP use
   • Implementation example-multics
   • Limitations to the BLP models
     • Incompatibility of confidentiality & integrity within a single MLS system
     • Cooperating conspirator prob. in the presence of covert channels
   • General description
     • 1970 - formal model for access control
     • Top secret > secret > confidential > restricted > unclassified (hierarchy of security levels)
     • SUBJECT has security clearance
     • OBJECT has security classification
     • BLP Model Access Modes
       • Read
       • Append
       • Write
       • Execute
     • Multilevel security
       • No read up @ ss-property
       • No write down @ *-property
   • Computer security models
     • Problems involved both design & implementation
   • BLP Rules
     • 1. Get access
     • 2. Release access
     • 5. Give access permission
     • 6. Rescind access permission
     • 3. Change object level
     • 4. Change current level
     • 7. Create an obj.
     • 8. Delete a group of obj.

2. 2. OTHER FORMAL MODELS FOR COMPUTER SECURITY

   • Biba integrity model
   • Clark-Wilson integrity model
   • Chinese wall model

3. 3. THE CONCEPT OF TRUSTED SYSTEMS

   • Reference monitors
   • Trojan horse defense

4. 4. TRUSTED COMPUTING AND THE TRUSTED PLATFORM MODULE

   • Authenticated boot service
     • Responsible for booting entire OS in stages & ensuring each is valid & approved for use: each stage digital signature associated w/ code is verified
     • Log records versions of all code running
     • Result in config. that is well-defined with approved components
   • Certification service
     • Once a configuration is achieved & logged the TPM can certify config. to others
     • Confidence that config. is unaltered bcs: TPM is considered trustworthy
     • Provides a hierarchical certification approach : hardware/OS config.
   • Encryption service
     • Encrypts data so that it can only be decrypted by a machine w/ a certain config.
     • TPM maintains a master secret key unique to machine
     • Encrypted data can be stored locally @ transmitted to a peer apps. on a remote machine
   • TPM functions
   • Protected storage

5. 5. ASSURANCE AND EVALUATION

   • Target audience
     • Consumers : Select security features & functions
     • Developers : Respond to security requirements
     • Evaluators : Use the assurance requirements as criteria when evaluating security features & controls
   • Scope of assurance
     • System architecture
     • System integrity : add. the correct operation of the system hardware & firmware
     • System testing : ensures security features have been tested thoroughly
     • Covert channel analysis
     • Trusted facility mgt. : deals w/ system admin.
     • Config. mgt.
     • Design specification & verification
     • Trusted recovery
     • Trusted distribution
   • Common criteria evaluation assurance levels
     • EAL 1: Functionally tested
     • EAL 2: Structurally tested
     • EAL 3: Methodically tested & checked
     • EAL 4: Methodically designed, tested & reviewed
     • EAL 5: Semi-formally designed & tested
     • EAL 6: Semi-formally verified design & tested
     • EAL 7: Formally verified design & tested
   • Evaluation
     • Ensures security features work correctly & effectively & show no exploitable vulnerabilities
     • Performed in parallel w/ @ after the development of the TOE
     • Higher levels entail: greater rigor, more time, more cost
     • Principle input: security target, evidence, actual TOE
     • Result: confirm security target is satisfied for TOE
     • Process relates security target to high-level design, low-level design, functional specification, source code implementation, & object code & hardware realization of the TOE
     • Degree of rigor & depth of analysis are determined by assurance level desired

Bilder und Dateien der Mindmap