COMP 150-IDS: Internet Scale Distributed Systems (Spring 2015)
Security Fundamentals
Noah Mendelsohn
Tufts University
Email: noah@cs.tufts.edu
Web: http://www.cs.tufts.edu/~noah
Copyright 2012 & 2015 – Noah Mendelsohn
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.
2
© 2010 Noah Mendelsohn
Encryption Basics
© 2010 Noah Mendelsohn
Simple Encryption
Encryption
Function
Data
Encrypted Data
4
© 2010 Noah Mendelsohn
Decryption
Decryption
Function
Data
Encrypted Data
5
© 2010 Noah Mendelsohn
Encryption/Decryption are functions over data+key
EncryptedData = Fencrypt(key, data)
Data = Fdecrypt (key, EncryptedData)
Data = Fdecrypt (key, Fencrypt(key, data))
6
© 2010 Noah Mendelsohn
Encryption/Decryption are functions over data+key
EncryptedData = Fencrypt(key, data)
Data = Fdecrypt (key, EncryptedData)
Same key for encryption and decryption
7
© 2010 Noah Mendelsohn
What’s secret?
Encryption &
Decryption Functions
Usually not Secret
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
8
© 2010 Noah Mendelsohn
What’s secret?
Same secret key needed
by sender & receiver
Key
distribution/protection is
a big problem
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
9
© 2010 Noah Mendelsohn
Public Key
Basics
© 2010 Noah Mendelsohn
Ordinary Encryption
Same secret key for
sender and receiver
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
11
© 2010 Noah Mendelsohn
Asymmetric Key Crypto
Key Pairs
Different Keys
for
Encryption & Decryption!!
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
Note: the encryption key cannot decrypt…only its pair can
Either key can serve to encrypt, then the other decrypts.
12
© 2010 Noah Mendelsohn
Digital Signatures
© 2010 Noah Mendelsohn
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
© 2010 Noah Mendelsohn
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 the message came from me
Non-repudiation: I can’t deny having signed those bits!
15
© 2010 Noah Mendelsohn
Public Key
Infrastructure
(PKI)
© 2010 Noah Mendelsohn
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
© 2010 Noah Mendelsohn
Identity and Authentication
© 2010 Noah Mendelsohn
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 userlevel
 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
© 2010 Noah Mendelsohn
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.
© 2010 Noah Mendelsohn
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
© 2010 Noah Mendelsohn
Transport Level Security (TLS and SSL)
Certificate from
Tufts checked
against cert
hierarchy up to Connection setup
root
Tufts.edu
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
© 2010 Noah Mendelsohn
Transport Level Security (TLS and SSL)
Tufts.edu
Problem:
Public key encryption much too slow for
bulk data transfer.
CPU
Memory
Storage
CPU
Memory
Storage
I want an encrypted connection to Tufts, and I want to be sure it’s Tufts
© 2010 Noah Mendelsohn
Transport Level Security (TLS and SSL)
Tufts.edu
Solution:
CPU
Memory
Storage
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.
CPU
Memory
Storage
Result: an authenticated, encrypted, high-performance connection.
© 2010 Noah Mendelsohn
Transport Level Security (TLS and SSL)
Connection setup
Tufts.edu
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
© 2010 Noah Mendelsohn
HTTPS: HTTP over TLS or SSL
Web Server
Browser
E.g. Firefox
E.g. Apache
Many commercial applications work this way
© 2010 Noah Mendelsohn
HTTPS: HTTP over TLS or SSL
Web Server
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
© 2010 Noah Mendelsohn
HTTPS: HTTP over TLS or SSL
Web Server
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
© 2010 Noah Mendelsohn
HTTPS: HTTP over TLS or SSL
Web Server
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
© 2010 Noah Mendelsohn
HTTPS: HTTP over TLS or SSL
Web Server
Some Cert Authorities (Cas)
aren’t nearly careful enough in
when issuing certs
News Reports on Lax CA Administration
2015
http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/
2011
E.g. Firefox
E.g. Apache
http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/
Many commercial applications work this way
© 2010 Noah Mendelsohn
The Web itself is a 2 or 3 Tier system
Web Server
Browser
Proxy Cache
E.g. Firefox
E.g. Squid
E.g. Apache
© 2010 Noah Mendelsohn
The Web itself is a 2 or 3 Tier system
Web Server
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
© 2010 Noah Mendelsohn
The Web itself is a 2 or 3 Tier system
Web Server
Browser
A malicious proxy with a
trusted cert can implement
“man-in-the-middle” attacks
E.g. Firefox
E.g. Squid
E.g. Apache
© 2010 Noah Mendelsohn
Trust
© 2010 Noah Mendelsohn
What must be trusted?
Storage and filesystem
for data in the clear at
source
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
36
© 2010 Noah Mendelsohn
What must be trusted?
Encryption software
and OS on which it
runs
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
37
© 2010 Noah Mendelsohn
What must be trusted?
The compiler and
linker used to build the
OS & encryption
(per K. Thompson)
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
38
© 2010 Noah Mendelsohn
What must be trusted?
Key store at source
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
39
© 2010 Noah Mendelsohn
What must be trusted?
The CPU, device HW
and microcode used to
run the system
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
40
© 2010 Noah Mendelsohn
What must be trusted?
All the equivalent at
the receiver
Encryption
Function
Data
Decryption
Function
Encrypted Data
Data
41
© 2010 Noah Mendelsohn
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
42
© 2010 Noah Mendelsohn
Some actual attacks that have worked
 Freezing (I.e. chilling) RAM chips to retain data after power
down
 Timing attack: SSH password 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
43
© 2010 Noah Mendelsohn
A Bit about Operating Systems
and Virtual Machines
© 2010 Noah Mendelsohn
Sector
In-memory Block
Cache
Raw Device Driver
Block Device Driver
Filesystem
Application
TTY Driver
Operating Systems and Virtual Machines
Sector
Unix Kernel
© 2010 Noah Mendelsohn
Disk virtualization
Display Virtualization
Operating Systems and Virtual Machines
Memory virtualization
Sector
Network virtualization
Virtual Machine “Hypervisor”
© 2010 Noah Mendelsohn
Memory virtualization
Sector
In-memory Block
Cache
Unix Kernel
Disk virtualization
Raw Device Driver
Block Device Driver
Filesystem
Application
TTY Driver
Display Virtualization
Operating Systems and Virtual Machines
Sector
Network virtualization
Virtual Machine “Hypervisor”
© 2010 Noah Mendelsohn
In-memory Block
Cache
Unix Kernel
Raw Device Driver
Block Device Driver
Filesystem
Application
Memory virtualization
Sector
Disk virtualization
In-memory Block
Cache
Raw Device Driver
Block Device Driver
Filesystem
Application
TTY Driver
Sector
Unix Kernel
TTY Driver
Display Virtualization
Operating Systems and Virtual Machines
Sector
Network virtualization
Virtual Machine “Hypervisor”
© 2010 Noah Mendelsohn
In-memory Block
Cache
Unix Kernel
Raw Device Driver
Block Device Driver
Filesystem
Application
Memory virtualization
Sector
Disk virtualization
In-memory Block
Cache
Raw Device Driver
Block Device Driver
Filesystem
Application
TTY Driver
Sector
The Virtual Machine
“Hypervisor”
Unix Kernel
provides the illusion of a complete CPU
+ memory +I/O to each virtual
machine
TTY Driver
Display Virtualization
Operating Systems and Virtual Machines
Sector
Network virtualization
Virtual Machine “Hypervisor”
© 2010 Noah Mendelsohn
Unix Kernel
Raw Device Driver
Block Device Driver
Filesystem
Application
Memory virtualization
In-memory Block
Cache
Disk virtualization
In-memory Block
Raw Device Driver
Block Device Driver
Filesystem
Application
TTY Driver
Sector
Cacheto all
The Hypervisor has access
resources of the
VM’s,
including RAM,
Unix
Kernel
disk, running program images, etc.
…
Experimental exploits have been
Sector
implemented as hypervisors
TTY Driver
Display Virtualization
Virtual Machines and Trust
Sector
Network virtualization
Virtual Machine “Hypervisor”
© 2010 Noah Mendelsohn
Unix Kernel
In-memory Block
Cache
Unix Kernel
Raw Device Driver
Block Device Driver
Filesystem
Application
Memory virtualization
Sector
Disk virtualization
In-memory Block
Cache
Raw Device Driver
Block Device Driver
Filesystem
Application
TTY Driver
Sector
Timing attacks have been attempted
across VMs.
TTY Driver
Display Virtualization
Operating Systems and Virtual Machines
Sector
Network virtualization
Virtual Machine “Hypervisor”
© 2010 Noah Mendelsohn
Summary
© 2010 Noah Mendelsohn
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
© 2010 Noah Mendelsohn