1 / 50

Security Fundamentals

COMP 150-IDS: Internet Scale Distributed Systems (Fall 2012). Security Fundamentals. Noah Mendelsohn Tufts University Email: noah@cs.tufts.edu Web: http://www.cs.tufts.edu/~noah. Goal.

yan
Download Presentation

Security Fundamentals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMP 150-IDS: Internet Scale Distributed Systems (Fall 2012) Security Fundamentals Noah Mendelsohn Tufts UniversityEmail: noah@cs.tufts.edu Web: http://www.cs.tufts.edu/~noah

  2. Goal • Learn about fundamental security mechanisms such as encryption, PKI, TLS, and related technologies such as rootkits, etc. Non Goal • This presentation does not attempt to explore broader issues relating to good security architecture including requirements gathering, threat analysis, design for security, penetration testing, etc.

  3. Encryption Basics

  4. Simple Encryption EncryptionFunction Data Encrypted Data

  5. Decryption DecryptionFunction Data Encrypted Data

  6. Encryption/Decryption are functions over data+key EncryptedData = Fencrypt(key, data) Data = Fdecrypt (key, EncryptedData) Data = Fdecrypt (key, Fencrypt(key, data))

  7. Encryption/Decryption are functions over data+key EncryptedData = Fencrypt(key, data) Data = Fdecrypt (key, EncryptedData) Same key for encryption and decryption

  8. Encryption & Decryption Functions Usually not Secret What’s secret? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  9. Same secret key needed by sender & receiverKey distribution/protection is a big problem What’s secret? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  10. Public KeyBasics

  11. Same secret key for sender and receiver Ordinary Encryption EncryptionFunction Data Encrypted Data DecryptionFunction Data

  12. Key PairsDifferent Keys forEncryption & Decryption Asymmetric Key Crypto EncryptionFunction Data Encrypted Data DecryptionFunction Data Note: the encryption key cannot decrypt…only its pair canEither key can serve to encrypt, then the other decrypts.

  13. Public Key Crypto • Built on asymmetric crypto • Pair: one part public, one part private • Private cannot be derived from public • To send me a message: • Encrypt it with my public key, which everyone knows is mine • Only I have the private key to decrypt • Avoids need to distribute secret keys! • …but, we do need to watch for fraudulent public keys

  14. Digital signatures: non-repudiation • Prove that these bits were from me • Step 1: I hash the content yielding a small number unique to the content • Step 2: I encrypt that hash using my private key, resulting in a digital signature • Step 3: I send you the bits and the signature • Step 4: You decrypt the signature using my public key, and compare to hash you compute on bits you’ve received Signature check: you have confidence it came from meNon-repudiation: I can’t deny it!

  15. Public KeyInfrastructure(PKI)

  16. Certificates • How do you know the public key is mine? • Certificate: a public key signed by someone you trust! • Their signature asserts: this key is Noah’s public key • Whom do you trust? • The organization you work for (E.g. Tufts University) • Well known signing organizations (Verisign, Thawt, Equifax, etc.) • Yourself (self-signed certs…usually a kludge only for testing) • Trust hierarchies • I am Noah as vouched for by Tufts as vouched for by Equifax • Your browser comes with a trusted set of root certificates • The PKI hierarchy has become fundamental to the integrity of the Web – used to establish identity of https: Web sites!

  17. Identity and Authentication

  18. PKI and identity management • PKI works best in hierarchical organizations of medium size • Nonetheless, it is the most common framework for authenticating the identity of Web sites • Some systems use PKI to authenticate down to the user-level • In practice, most Web sites use ordinary passwords, with sites authenticated using HTTPS (PKI) • There are ongoing problems with the operational integrity (and business motivations of) the some CA providers

  19. HTTPS and TLS Warning: the protocol on the following slide is greatly simplified. Actual TLS has many crypto and PKI options, and uses a much more elaborate and robust setup protocol. This is close enough in spirit to give the general idea.

  20. Transport Level Security (TLS and SSL) Tufts.edu CPU Memory Storage CPU Memory Storage I want an encrypted connection to Tufts, and I want to be sure it’s Tufts

  21. Transport Level Security (TLS and SSL) Certificate from Tufts checked against cert hierarchy up to root Tufts.edu Connection setup Certificate from Tufts CPU Memory Storage CPU Memory Storage I want an encrypted connection to Tufts, and I want to be sure it’s Tufts

  22. Transport Level Security (TLS and SSL) Problem:Public key encryption much too slow for bulk data transfer. Tufts.edu CPU Memory Storage CPU Memory Storage I want an encrypted connection to Tufts, and I want to be sure it’s Tufts

  23. Transport Level Security (TLS and SSL) Solution:TLS/SSL use PKI to authenticate server (and optionally client) and to establish agreement on a private (symmetric) key used to encrypt actual session data. Tufts.edu CPU Memory Storage CPU Memory Storage Result: an authenticated, encrypted, high-performance connection.

  24. Transport Level Security (TLS and SSL) Tufts.edu Connection setup Certificate from Tufts CPU Memory Storage CPU Memory Storage I want an encrypted connection to Tufts, and I want to be sure it’s Tufts

  25. Web Server HTTPS: HTTP over TLS or SSL Browser E.g. Firefox E.g. Apache Many commercial applications work this way

  26. Web Server HTTPS: HTTP over TLS or SSL Your browser keeps a list of root certs (Verisign, etc.)These companies control the verification of secure connections you make on the Web! E.g. Firefox E.g. Apache Many commercial applications work this way

  27. Web Server HTTPS: HTTP over TLS or SSL If someone can get a bogus cert for google.com or microsoft.com, that’s a big deal! E.g. Firefox E.g. Apache Many commercial applications work this way

  28. Web Server HTTPS: HTTP over TLS or SSL Some Cert Authorities (Cas) aren’t nearly careful enough in when issuing certs E.g. Firefox E.g. Apache Many commercial applications work this way

  29. Web Server The Web itself is a 2 or 3 Tier system Browser Proxy Cache E.g. Firefox E.g. Squid E.g. Apache

  30. Web Server The Web itself is a 2 or 3 Tier system Browser HTTP CONNECT header used to make proxy transparent to TLS…benefits of proxy are lost! E.g. Firefox E.g. Squid E.g. Apache

  31. Web Server The Web itself is a 2 or 3 Tier system Browser A malicious proxy with a trusted cert can implement “man-in-the-middle” attacks E.g. Firefox E.g. Squid E.g. Apache

  32. Trust

  33. Storage and filesystem for data in the clear at source What must be trusted? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  34. Encryption software and OS on which it runs What must be trusted? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  35. The compiler and linker used to build the OS & encryption(per K. Thompson) What must be trusted? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  36. Key store at source What must be trusted? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  37. The CPU, device HW and microcode used to run the system What must be trusted? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  38. All the equivalent at the receiver What must be trusted? EncryptionFunction Data Encrypted Data DecryptionFunction Data

  39. Trust is a key system design issue • Always consider: what/who is being trusted? • What is the consequence if trust is misplaced? • Can we tell if trust is misplaced • Reflections on Trusting Trust tells us “it’s at best really hard to be sure” • Can we change our minds (revoke trust)? • Watch for: • Any place where information is stored “in the clear” • Any place where “capabilities” are stored or given out • Note that keys are a kind of capability

  40. Some actual attacks that have worked • Freezing (I.e. chilling) RAM chips to retain data after power down • Timing attack: SSH passwored cracking facilitated by keystroke timing • Timing attack: SSL private keys revealed!! • Demonstrated on production Web servers* • Rootkits, bootkits & VM attacks * SSL timing paper: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

  41. A Bit about Operating Systems and Virtual Machines

  42. Sector Operating Systems and Virtual Machines Sector Block Device Driver Raw Device Driver Application TTY Driver Filesystem In-memory BlockCache Unix Kernel

  43. Sector Operating Systems and Virtual Machines Disk virtualization Display Virtualization Unix Kernel Network virtualization Memory virtualization Virtual Machine “Hypervisor”

  44. Sector Operating Systems and Virtual Machines Sector Block Device Driver Raw Device Driver In-memory BlockCache Application TTY Driver Filesystem Unix Kernel Disk virtualization Display Virtualization Virtual Machine “Hypervisor” Network virtualization Memory virtualization

  45. Sector Operating Systems and Virtual Machines Application TTY Driver Filesystem Sector Sector Block Device Driver Block Device Driver Raw Device Driver Raw Device Driver Unix Kernel In-memory BlockCache In-memory BlockCache Application TTY Driver Filesystem Unix Kernel Disk virtualization Display Virtualization Virtual Machine “Hypervisor” Network virtualization Memory virtualization

  46. Sector Operating Systems and Virtual Machines The Virtual Machine “Hypervisor”provides the illusion of a complete CPU + memory +I/O to each virtual machine Application TTY Driver Filesystem Sector Sector Block Device Driver Block Device Driver Raw Device Driver Raw Device Driver Unix Kernel In-memory BlockCache In-memory BlockCache Application TTY Driver Filesystem Unix Kernel Disk virtualization Display Virtualization Virtual Machine “Hypervisor” Network virtualization Memory virtualization

  47. Sector Virtual Machines and Trust The Hypervisor has access to all resources of the VM’s, including RAM, disk, running program images, etc. … Experimental exploits have been implemented as hypervisors Application TTY Driver Filesystem Sector Sector Block Device Driver Block Device Driver Raw Device Driver Raw Device Driver Unix Kernel In-memory BlockCache In-memory BlockCache Application TTY Driver Filesystem Unix Kernel Disk virtualization Display Virtualization Virtual Machine “Hypervisor” Network virtualization Memory virtualization

  48. Sector Operating Systems and Virtual Machines Timing attacks have been attempted across VMs. Application TTY Driver Filesystem Sector Sector Block Device Driver Block Device Driver Raw Device Driver Raw Device Driver Unix Kernel In-memory BlockCache In-memory BlockCache Application TTY Driver Filesystem Unix Kernel Disk virtualization Display Virtualization Virtual Machine “Hypervisor” Network virtualization Memory virtualization

  49. Summary

  50. Summary • Typical security mechanisms are build on core technologies like simple encryption & PKI • Those are just building blocks: security must be considered in all aspects of system design • Abstractions leak: (computation can be timed, etc.) • Many vulnerabilities are operational, not technical • There are serious vulernabilities in the Interent infrastructure and the Web – it’s not entirely clear how severe the consequences will be

More Related