USC CSci599 Trusted Computing Lecture notes Spring 2007
USC CSci599 Trusted Computing Lecture notes Spring 2007. Dr. Clifford Neuman University of Southern California Information Sciences Institute. Administration. Class home page http://ccss.usc.edu/599tc Preliminary Syllabus Assigned Readings Lecture notes Assignments
USC CSci599 Trusted Computing Lecture notes Spring 2007
E N D
Presentation Transcript
USC CSci599Trusted ComputingLecture notesSpring 2007 Dr. Clifford Neuman University of Southern California Information Sciences Institute
Administration • Class home page http://ccss.usc.edu/599tc • Preliminary Syllabus • Assigned Readings • Lecture notes • Assignments • See me for D Clearance
Administration • Class e-mail: csci599s07@clifford.neuman.name • Instructor • Dr. Clifford Neuman • Office hours Friday 10:45-11:45 SAL 212
USC CSci599Trusted ComputingLecture Two – Trusted HardwareJanuary 19, 2007 - PRELIMINARY Dr. Clifford Neuman University of Southern California Information Sciences Institute
NOTE • These are place holders for the topics we will discuss today. • There will be more slides by lecture.
The Hardware Basis • Trusted computing is proof by induction • Each attestation stage says something about the next level • Just like PKI Certification hierarchy • One needs a basis step • On which one relies • Hardware is that step • (well, second step anyway)
Hardware Topics • Trusted Platform Module • Discussion of Secure Storage • Boot process
Trusted Platform Module • Basically a Key Storage and Generation Device • Capabilities: • Generation of new keys • Storage and management of keys • Uses keys without releasing
Endorsement Key • Every TPM has unique Endorsement key • Semi-root of trust for system • Generated and installed during manufacture • Issues • Real root is CA that signs public key associated with Endorsement key
Identity Key • Key associated with certificate from a CA attesting to identity of the TPM and version / security attributes. (I’m not sure of the relationship with the EK)
Storage Root Key • Root of Key Hierarchy for managing keys related to TPM (except EK) • Root key never leaves TPM • Can be changed to reinitialize ownership.
Storage Keys • Can protect data • Can protect other keys • Some storage keys may be migrated.
Binding Key • Private key to decrypt data perhaps encrypted by others using a public key
Using Encryption • LoadKey • Generated or imported • Sign • Signs Data Presented to TPM • Unbind • Decrypt data from elsewhere in a public key
Using Encryption • Seal/Unseal • Encrypt and subsequent decrypt • This TPM Only • PCRs must be correct • Platform Configuration Register (PCR) • 20 by storage inside TPM is digest of accumulated data. • Contains information about the programs and other state of the processor.
Using Encryption • Extend • Add data to a PCR • 20 byte hash hashed into current PCR • As each module loaded its hash extends the PCR • Quote • Sign current value of PCR
Using Encryption • CreateWrapKey • Creates and encrypts for transfer a new RSA key • MakeIdentity • Creates an Attestation Identity key for a user • TakeOwnership • Reinitialize TPM, and erases old keys
Using Encryption • Other Functions • OIAP/OSAP • GetCapability • GetRandom
How to Use it For Atestation • As modules loaded, their hashes extend the PCR. • When attestation needed, remote entity can ask the TPM to sign PCR.
Peripheral Authenication • TPM’s can be embedded in peripherals too, so a system knows it is dealing with an authentic biometric scanner or other kinds of devices.
Exercise - Secure Storage • Full Disk Encryption • Key in register in disk • Or key in TPM and data encrypted/decrypted by TPM • Seagate Drive uses register in Disk • Key must be loaded • User prompt at BIOS • Or managed by TPM • But OS image maybe on disk, how to get
The Boot Process • Work and example using the functions described already.