USC CSci599 Trusted Computing Lecture Five – Key Management February 9, 2007

USC CSci599Trusted ComputingLecture Five – Key ManagementFebruary 9, 2007 Dr. Clifford Neuman University of Southern California Information Sciences Institute

Announcements • Assignment due today. • Those that didn’t get TVSApaper last week see me. • Mid-term in two weeks • For the most relevant of the assignments turned in I will be contacting you about presenting to the class.

Cryptography in Use • Provides foundation for security services • Provides confidentiality • Validates integrity • Provides data origin authentication • If we know the key • Where does the key come from • Straightforward plan • One side generates key • Transmits key to other side • But how? • How is the key protected • This is a key problem in security

Key Management • Key management is where much security weakness lies • Choosing keys • Storing keys • Communicating keys

What to do with keys • Practical issues • How to carry them • Passwords vs. disks vs. smartcards, vs. hardware. • Where do they stay, where do they go • How many do you have • How do you get them to begin with. • When can you use them.

Key Management and Trusted Computing • Protecting the keys needed for trusted computing. • This is the role of the TPM • We will discuss how this is done. • Using trusted computing to protect the keys needed for other applications. • This can be a role for trustedcomputing in general. • The TPM plays a role, but the rest of the system must extend this protection through the application stack.

What it means to protect a key • Prevent disclosure • A manageable problem in some situations. • Prevent use of the key for unauthorized purposes. • A much harder problem • How do we preserve or transport keys?

Key Distribution • Conventional cryptography • Single key shared by both parties • Public Key cryptography • Public key published to the world • Private key known only by owner • Third party certifies or distributes keys • Certification infrastructure • Authentication

KDC Based Key Distribution • User sends request to KDC: {s} • KDC generates a random key: Kc,s • Encrypted twice: {Kc,s}Kc, {Kc,s}Ks • {Kc,s}Kc called ticket • Ticket plus Kc,s called credentials • Ticket is opaque and forwarded with application request • No keys ever traverse net in the clear

Public Key Distribution • Public key can be public! • How does either side know who and what the key is for? Private agreement? (Not scalable.) • Does this solve key distribution problem? • No – while confidentiality is not required, integrity is. • Still need trusted third party

Recovery from exposed keys • Revocation lists (CRL’s) • Long lists • Hard to propogate • Lifetime / Expiration • Short life allows assurance of validitiy at time of issue. • Realtime validation • Online Certificate Status Protocol (OCSP) • What about existing messages?

Key Management Overview • Who needs strong secrets anyway • Users? • Servers? • The Security System? • Software? • End Systems? • Secret vs. Public

Group Key Management • Group key vs. Individual key • Identifies member of groups vs. which member of group • PK slower but allows multiple verification of individuals

Trust models for certification • X.509 Hierarchical • Single root (original plan) • Multi-root (better accepted) • SET has banks as CA’s and common SET root • PGP Model • “Friends and Family approach” - S. Kent • Other representations for certifications • No certificates at all • Out of band key distribution • SSH

Certification Infrastructures • Public keys represented by certificates • Certificates signed by other certificates • User delegates trust to trusted certificates • Certificate chains transfer trust up several links

Key in Trusted Computing Slide by Arun Viswanathan

Endorsement Key • Every TPM has unique Endorsement key • Semi-root of trust for system • Real root is CA that signs public key associated with Endorsement key • Generated and installed during manufacture

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 • Quote • Sign current value of PCR

Using Encryption • CreateWrapKey • Creates and encrypts for transfer a new RSA key • MakeIdentity • Creates an Attestation Identitykey for a user • TakeOwnership • Reinitialize TPM, and erases old keys

Applications • Authentication • Login checking • Digital Signatures on document • Email • Disk Encryption • Electronic commerce • Financial transactions • Broadcast access control (e.g. Satellite TV)

Authentication • User key may be needed from multiple machines. • Either user enters it (vulnerable) • Stored and used in smartcard (better) • Transferred between and stored in TPMs. • But how to validate presence of user

Encryption Based Authentication • Proving knowledge of encryption key • Nonce = Non repeating value {Nonce or timestamp}KCS C S But where does Kc come from?

Login Checking • Traditional crypto-based login checking is to obtain user key and use it to authenticate to the TCB. • But if the user key is in the TPM, or in a smartcard, it reduces to some kind of secret based authentication (e.g. password), or alternatively a biometric.

Digital Signatures • Key used to “sign” document must be carried and stored where used. • Can be stored in TPM, or protected so that it can only be accessed by TPM • TPM applies signature, or yields key used to apply signature in other software. • Must address issue of when key may be used, and to whom it may be given.

Email • Digital signature for sending • Authentication for retrieval • Unsealing based on binding key for received encrypted email.

Disk Encryption Covered in earlier lecture • 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

Ecommerce and Financial Transactions • Some keys and assets may need to be protected against user • Stored value cards • Others are protected for the user • Keys that authenticate requests by user, such as checks or credit card documents.

Satellite TV Slide from Nilesh Maheshwari

USC CSci599 Trusted Computing Lecture Five – Key Management February 9, 2007