0% found this document useful (0 votes)
30 views

09 Security

CS6456 is a graduate operating systems course taught by Brad Campbell at the University of Virginia. The course covers topics related to protection and security mechanisms in operating systems, including page tables, scheduling, data encryption, authentication, data integrity, confidentiality, non-repudiation, cryptography, hashing, symmetric and asymmetric encryption. Security requirements, why data breaches are common, and key distribution challenges are also discussed.

Uploaded by

maykelnawar
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
30 views

09 Security

CS6456 is a graduate operating systems course taught by Brad Campbell at the University of Virginia. The course covers topics related to protection and security mechanisms in operating systems, including page tables, scheduling, data encryption, authentication, data integrity, confidentiality, non-repudiation, cryptography, hashing, symmetric and asymmetric encryption. Security requirements, why data breaches are common, and key distribution challenges are also discussed.

Uploaded by

maykelnawar
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 51

CS6456: Graduate

Operating Systems
Brad Campbell – [email protected]
https://www.cs.virginia.edu/~bjc8c/class/cs6456-f19/

1
2
Protection vs. Security
• Protection: mechanisms for controlling access of programs,
processes, or users to resources
• Page table mechanism
• Round-robin schedule
• Data encryption

• Security: use of protection mechanisms to prevent misuse of


resources
• Misuse defined with respect to policy
• E.g.: prevent exposure of certain sensitive information
• E.g.: prevent unauthorized modification/deletion of data
• Need to consider external environment the system operates in
• Most well-constructed system cannot protect information if
user accidentally reveals password – social engineering
challenge 3
Security Requirements
• Authentication
• Ensures that a user is who is claiming to be

• Data integrity
• Ensure that data is not changed from source to
destination or after being written on a storage device

• Confidentiality
• Ensures that data is read only by authorized users

• Non-repudiation
• Sender/client can’t later claim didn’t send/write data
• Receiver/server can’t claim didn’t receive/write data
4
Why are Data Breaches so Frequent?
Really Large TCB Really Large TCB

SSL
SSL
h h
SSL
Full OS TCB

• State of the art: AdHoc boundary construction!


• Protection mechanisms are “roll-your-own” and different for each application
• Use of encrypted channels to “tunnel” across untrusted domains
• Data is typically protected at the Border rather than Inherently
• Large Trusted Computing Base (TCB): huge amount of code must be correct to
protect data
• Make it through the border (firewall, OS, VM, container, etc…) data compromised!
• What about data integrity and provenance?
• Any bits inserted into “secure” environment get trusted as authentic
5
Securing Communication: Cryptography

• Cryptography: communication in the presence of


adversaries

• Studied for thousands of years


• See the Simon Singh’s The Code Book for an excellent, highly
readable history

• Central goal: confidentiality


• How to encode information so that an adversary can’t extract it,
but a friend can

• General premise: there is a key, possession of which allows


decoding, but without which decoding is infeasible
• Thus, key must be kept secret and not guessable
6
Using Symmetric Keys
• Same key for encryption and decryption
• Achieves confidentiality
• Vulnerable to tampering and replay attacks
Plaintext (m) m

Encrypt with
Internet Decrypt with
secret key secret key
Ciphertext

7
Block Ciphers with Symmetric Keys
• Block cipher algorithms encrypt blocks of data
• Works with a block size (e.g., 64 bits)
• Can encrypt blocks separately:
• Same plaintextsame ciphertext
• Much better:
• Add in counter and/or link ciphertext of previous block

9
Authentication in Distributed Systems
• What if identity must be established across network?

Network

PASS: gina
• Need way to prevent exposure of information while still
proving identity to remote system
• Many of the original UNIX tools sent passwords over the
wire “in clear text”
• E.g.: telnet, ftp, yp (yellow pages, for distributed login)
• Result: Snooping programs widespread
• What do we need? Cannot rely on physical security!
• Encryption: Privacy, restrict receivers 11
• Authentication: Remote Authenticity, restrict senders
Authentication via Secret Key
• Main idea: entity proves identity by decrypting a secret
encrypted with its own key
• K – secret key shared only by A and B
• A can asks B to authenticate itself by decrypting a nonce,
i.e., random value, x
• Avoid replay attacks (attacker impersonating client or server)
• Vulnerable to man-in-the middle attack
A B
E(x, K
)

Notation: E(m,k) –
x
encrypt message
m with key k

12
Secure Hash Function
DFCD3454BBEA788A
Hash
Fox 751A696C24D97009
Function
CA992D17

The red fox 52ED879E70F71D92


Hash
runs across 6EB6957008E03CE4
the ice Function
CA6945D3

• Hash Function: Short summary of data (message)


• For instance, h1=H(M1) is the hash of message M1
• h1 fixed length, despite size of message M1
• Often, h1 is called the “digest” of M1
• Hash function H is considered secure if
• It is infeasible to find M2 with h1=H(M2); i.e., can’t easily find other
message with same digest as given message
• It is infeasible to locate two messages, m1 and m2, which
“collide”, i.e. for which H(m1) = H(m2)
• A small change in a message changes many bits of digest/can’t
tell anything about message given its hash 13
Integrity: Cryptographic Hashes
• Basic building block for integrity: cryptographic hashing
• Associate hash with byte-stream, receiver verifies match
• Assures data hasn’t been modified, either accidentally – or
maliciously

• Approach:
• Sender computes a secure digest of message m using H(x)
• H(x) is a publicly known hash function
• Digest d = HMAC (K, m) = H (K | H (K | m))
• HMAC(K, m) is a hash-based message authentication function
• Send digest d and message m to receiver
• Upon receiving m and d, receiver uses shared secret key, K, to
recompute HMAC(K, m) and see whether result agrees with d
14
Using Hashing for Integrity

corrupted msg m
plaintext (m)
NO
=
digest’
Digest Internet Digest
HMAC(K,m) HMAC(K,m)

Encrypted Digest
Unencrypted Message

Can encrypt m for confidentiality


15
Standard Cryptographic Hash Functions
• MD5 (Message Digest version 5)
• Developed in 1991 (Rivest), produces 128 bit hashes
• Widely used (RFC 1321)
• Broken (1996-2008): attacks that find collisions

• SHA-1 (Secure Hash Algorithm)


• Developed in 1995 (NSA) as MD5 successor with 160 bit hashes
• Widely used (SSL/TLS, SSH, PGP, IPSEC)
• Broken in 2005, government use discontinued in 2010

• SHA-2 (2001)
• Family of SHA-224, SHA-256, SHA-384, SHA-512 functions

• HMAC’s are secure even with older “insecure” hash


functions 16
Key Distribution
• How do you get shared secret to both places?
• For instance: how do you send authenticated,
secret mail to someone who you have never met?
• Must negotiate key over private channel
• Exchange code book/key cards/memory
stick/others

• Could use a third party

17
Third Party: Authentication Server (Kerberos)
• Notation:
• Kxy is key for talking c k et Key
q Ti
between x and y Re Server
• (…) means encrypt e t
Tick
K

message (…) with the


key K Ticket
• Clients: A and B, Secure Communication
Authentication server S
• Usage:
• A asks server for key:
• AS: [Hi! I’d like a key for talking between A and B]
• Not encrypted. Others can find out if A and B are
talking
• Server returns session key encrypted using B’s key
• SA: Message [ Use Kab (This is A! Use Kab)Ksb ] Ksa
• This allows A to know, “S said use this key”
• Whenever A wants to talk with B
• AB: Ticket [ This is A! Use Kab ]Ksb 18
Asymmetric Encryption (Public Key)
• Idea: use two different keys, one to encrypt (e) and one to
decrypt (d)
• A key pair

• Crucial property: knowing e does not give away d

• Therefore e can be public: everyone knows it!

• If Alice wants to send to Bob, she fetches Bob’s public key


(say from Bob’s home page) and encrypts with it
• Alice can’t decrypt what she’s sending to Bob …
• … but then, neither can anyone else (except Bob)

20
Public Key Encryption Details
• Idea: Kpublic can be made public, keep Kprivate private
Insecure Channel

Bpublic Bprivate
Aprivate Apublic

Alice Insecure Channel Bob

• Gives message privacy (restricted receiver):


• Public keys (secure destination points) can be acquired by anyone/used
by anyone
• Only person with private key can decrypt message
• What about authentication?
• Use combination of private and public key
• AliceBob: [(I’m Alice)Aprivate Rest of message]Bpublic
• Provides restricted sender and receiver
• But: how does Alice know that it was Bob who sent her B public? And
22
vice versa…
Public Key Cryptography
• Invented in the 1970s
• Revolutionized cryptography
• (Was actually invented earlier by British intelligence)
• How can we construct an encryption/decryption algorithm using
a key pair with the public/private properties?
• Answer: Number Theory
• Most fully developed approach: RSA
• Rivest / Shamir / Adleman, 1977; RFC 3447
• Based on modular multiplication of very large integers
• Very widely used (e.g., ssh, SSL/TLS for https)
• Also mature approach: Eliptic Curve Cryptography (ECC)
• Based on curves in a Galois-field space
• Shorter keys and signatures than RSA

23
Non-Repudiation: RSA Crypto & Signatures

• Suppose Alice has published public key KE


• If she wishes to prove who she is, she can send a message
x encrypted with her private key KD (i.e., she sends E(x,
KD))
• Anyone knowing Alice’s public key KE can recover x, verify that
Alice must have sent the message
• It provides a signature I will
pay Bob
• Alice can’t deny it: non-repudiation $500

• Could simply encrypt a hash of the data to


sign a document that you wanted to be in clear text
• Note that either of these signature techniques work
perfectly well with any data (not just messages)
I will
• Could sign every datum in a database, for instance
pay Bob
$500

26
Digital Certificates
• How do you know KE is Alice’s public key?

• Trusted authority (e.g., Verisign) signs binding


between Alice and KE with its private key KVprivate
• C = E({Alice, KE}, KVprivate)
• C: digital certificate
• Alice: distribute her digital certificate, C
• Anyone: use trusted authority’s KVpublic, to extract
Alice’s public key from C
• D(C, KVpublic) =
D(E({Alice, KE}, KVprivate), KVpublic) = {Alice, KE}

27
Putting It All Together - HTTPS

• What happens when you click on


https://www.amazon.com?

• https = “Use HTTP over TLS”


• SSL = Secure Socket Layer
• TLS = Transport Layer Security
• Provides security layer (authentication, encryption) on
top of TCP
• Fairly transparent to applications

29
HTTPS Connection (SSL/TLS) (cont’d)
Browser Amazon
• Browser (client) connects via
TCP to Amazon’s HTTPS server Hel
lo
(TL . I su
S p
• Client sends over list of crypto 2) o +RSA+ port
r AES
(SS 128
protocols it supports or
L+R
SA+ +SH
A
… 3DE
• Server picks protocols to use S+M
D5)
for this session
• Server sends over its e t ’s use S12 8+SH
L E
S +R SA+A
certificate TL
’s my
A 2 H e r e
• (all of this is in the clear) c er t B o f
~1 K
d ata

30
Inside the Server’s Certificate
• Name associated with cert (e.g., Amazon)
• Amazon’s RSA public key
• A bunch of auxiliary info (physical address, type of
cert, expiration time)
• Name of certificate’s signatory (who signed it)
• A public-key signature of a hash (SHA-256) of all this
• Constructed using the signatory’s private RSA key, i.e.,
• Cert = E(HSHA256(KApublic, www.amazon.com, …), KSprivate))
• KApublic: Amazon’s public key
• KSprivate: signatory (certificate authority) private key
•…

31
Validating Amazon’s Identity
• How does the browser authenticate certificate signatory?
• Certificates of several certificate authorities (e.g., Verisign) are
hardwired into the browser (or OS)
• If can’t find cert, warn user that site has not been verified
• And may ask whether to continue
• Note, can still proceed, just without authentication
• Browser uses public key in signatory’s cert to decrypt signature
• Compares with its own SHA-256 hash of Amazon’s cert
• Assuming signature matches, now have high confidence it’s
indeed Amazon … assuming signatory is trustworthy
• DigiNotar CA breach (July-Sept 2011): Google, Yahoo!, Mozilla, Tor
project, Wordpress, … (531 total certificates)

32
HTTPS Connection (SSL/TLS) cont’d
Browser Amazon
s my
• Browser constructs a random session Here’
c er t d ata
key K used for data communication o f
~1 KB
• Private key for bulk crypto K E(K, K
Apu
• Browser encrypts K using Amazon’s blic )

public key
• Browser sends E(K, KApublic) d K
Agree
to server
• Browser displays E(pa
s swor
d …,
• All subsequent comm. encrypted w/ K)
symmetric cipher …,
(e.g., AES128) using key K e s p o n se
E (r
• E.g., client can authenticate using a K)
password
34
Hardware Security
• Definition: implement security protection
mechanisms in hardware
• E.g., design trusted hardware, as opposed to (in addition
to) trusted software
• Software security: software protect software!
• Vulnerable to attacks
• Is the antivirus/hardware untouched?
• Easy infiltration
• Fast spread
• Hardware security: hardware protect software
• Attacks need physical access
• Software infiltration much more difficult
35
Trusted Platform Module (TPM)

• A chip integrated into the hardware


platform
• It is a separate, trusted co-processor

“The TPM represents a separate trusted


coprocessor, whose state cannot be
compromised by potentially malicious host
system software.”
IBM Research Report

36
Goals
• TPMs allow a system to:
• Gather and attest system state
• Store and generate cryptographic data
• Prove platform identity

• Prevents unauthorized software


• Helps prevent malware

37
TPM Components

• Root key
• PKI private keys could be stored in the chip
• PK signatures calculated in the chip itself, never
visible outside
• Random number generators
• SHA-1 encryption
• Monotonic counters
• Process isolation (encrypted I/O, prevents keystroke
loggers, screen scrapers)

38
Limitations

• Advanced features will require O/S support


• Potential for abuse by Software vendors
• Co-processor or Cop-processor?
• “Trusted Computing requires you to surrender control of
your machine to the vendors of your hardware and
software, thereby making the computer less
trustworthy from the user’s perspective” - Ross
Anderson
• The TPM's most controversial feature is attestation,
the ability to measure the state of a computer and
send a signed message certifying that particular
hardware or software is or isn't present.
39
Real-World Applications
• Hard drive encryption
• BitLocker in Windows 8
• Trustworthy OS
• Google’s Chromebook use TPM to prevent firmware rollback

• Potential applications:
• DRM
• Fighting pirate software

40
BitLocker™ Drive Encryption Architecture
Static Root of Trust Measurement of boot components

PreOS Static OS All Boot Blobs Volume Blob of Target OS


unlocked unlocked

TPM Init

BIOS

MBR

BootSector

BootBlock

BootManager
Start
OS Loader
OS

42
Disk Layout And Key Storage
OS Volume Contains Where’s the Encryption Key?
• Encrypted OS 1. SRK (Storage Root Key)
contained in TPM
• Encrypted Page File
2. SRK encrypts FVEK (Full Volume
• Encrypted Temp Files
Encryption Key) protected by TPM/PIN/USB
• Encrypted Data Storage Device
• Encrypted Hibernation File 3. FVEK stored (encrypted by SRK) on hard
drive in the OS Volume

3
OS Volume
2 FVEK 1 SRK
System

System Volume Contains:


MBR, Boot manager, Boot Utilities
(Unencrypted, small)
43
Intel SGX: Goals

• Extension to Intel processors that support:


• Enclaves: running code and memory isolated
from the rest of system
• Attestation: prove to local/remote system what
code is running in enclave
• Minimum TCB: only processor is trusted
• nothing else: DRAM and peripherals are untrusted

• ⇒ all writes to memory are encrypted


45
Applications
Server side:
• Storing a Web server HTTPS secret key:
• key only opened inside an enclave
• ⇒ malware cannot get the key
• Running a private job in the cloud: job runs in enclave
• Cloud admin cannot get code or data of job

Client side:
• Hide anti-virus (AV) signatures:
• AV signatures are only opened inside an enclave
• not exposed to adversary in the clear
• Hide proprietary ML models:
• Speech detection on smart home devices
• Models secret and hidden from competitors
46
Intel SGX: how does it work?

• An application defines part of itself as an


enclave
Untrusted part Enclave

create enclave

(isolated memory)

Process memory
47
Intel SGX: how does it work?

• An application defines part of itself as an


enclave
Untrusted part Enclave
enclave code runs
create enclave
using enclave data
call TrustedFun 67g35bd954bt

Process memory
48
Intel SGX: how does it work?

• An application defines part of itself as an


enclave
Untrusted part Enclave
enclave data only
create enclave
accessible to code
call TrustedFun in enclave
67g35bd954bt

Process memory
49
How does it work?
• Part of process memory holds the enclave:

low enclave high

app enclave enclave


OS
code code data

Process memory

• Enclave code and data are stored encrypted in main memory


• Processor prevents access to cached enclave data outside of enclave.
50
Creating an enclave: new instructions

• ECREATE: establish memory address for


enclave
• EADD: copies memory pages into enclave
• EEXTEND: computes hash of enclave contents
(256 bytes at a time)
• EINIT: verifies that hashed content is properly
signed
• if so, initializes enclave (signature = RSA-3072)

• EENTER: call a function inside enclave


• EEXIT: return from enclave
51
SGX Summary

• SGX: an architecture for managing secret data


• Intended to process data that cannot be read by
anyone, except for code running in enclave
• Attestation: proves what code is running in
enclave
• Minimal TCB: nothing trusted except for x86
processor
• Not suitable for legacy applications

53
SGX insecurity: side channels

enclave memory bus DRAM


(enc data) memory
OS
processor

Attacker controls the OS. OS sees lots of side-channel info:


• Memory access patterns
• State of processor caches All can leak
as enclave executes enclave data.
• State of branch predictor Difficult to block.
57
The Spectre attack

Speed vs. security in HW

[slides credit: Paul Kocher]


59
Memory caches (4-way associative)

Caches hold local (fast) copy of recently-accessed 64-byte chunks


of memory
CPU MEMORY Set Addr Cached Data ~64B
Sends address, CACHE 0 F0016280
31C6F4C0
B5
9A
F5
DA
80
59
21
11
E3
48
2C..
F2.. Address: MAIN
Receives data 339DD740 C7 D7 A0 86 67 18.. MEMORY
614F8480 17 4C 59 B8 58 A7..
132E1340
1 71685100 27 BD 5D 2E 84 29.. Data: Big, slow
Addr: 2A1C0700 132A4880 30 B2 8F 27 05 9C.. e.g. 16GB SDRAM
Fast
AC 99 17 8F 44 09..
2A1C0700
2A1C0700 9E C3 DA EE B7 D9..
C017E9C0 D1 76 16 54 51 5B..
Data: 9E C3 DA EE B7 D3..
2 311956C0 0A 55 47 82 86 4E..
002D47C0 C4 15 4D 78 B5 C4..
hash(addr)
Addr: 91507E80 60 D0 2C DD 78 14..
to map to 55194040 DF 66 E9 D0 11 43..
132E1340
Data: AC 99 17 8F 44 09.. cache set
Slow 3 9B27F8C0 84 A0 7F C7 4E BC.. Reads change system state:
8E771100 3B 0B 20 0C DB 58..
A001FB40 29 D9 F5 6A 72 50.. • Read to newly-cached
Fast 317178C0 35 82
99 CB
to 91
78 8B..
Addr:
4
132E1340
6618E980
AC
Evict
35
17
11
8F
make
4A
44
E0 2E
room
09..
F1..
location is fast
132E1340 BA0CDB40 B0 FC 5A 20 D0 7F.. • Read to evicted location
Data: AC 99 17 8F 44 09.. 89E92C00 1C 50 A4 F8 EB 6F..
090F9C40 BB 71 ED 16 07 1F..
is slow

60
Speculative execution
CPUs can guess likely program path and do speculative execution
 Example:
if (uncached_value == 1) // load from memory
a = compute(b)

 Branch predictor guesses if() is ‘true’ (based on prior history)


 Starts executing compute(b) speculatively

 When value arrives from memory, check if guess was correct:


 Correct: Save speculative work ⇒ performance gain
 Incorrect: Discard speculative work ⇒ no harm (?)
61
Conditional branch (Variant 1) attack
if (x < array1_size)
y = array2[ array1[x]*4096 ];

Suppose unsigned int x comes from untrusted


caller

Execution without speculation is safe:


array2[array1[x]*4096] not eval unless
x < array1_size

63
What about with speculative execution?
Conditional branch (Variant 1) attack
Memory & Cache Status
if (x < array1_size)
array1_size = 00000008
y = array2[array1[x]*4096];
Memory at array1 base:
8 bytes of data (value doesn’t matter)
Memory at array1 base+1000:
09 F1 98 CC 90...(something secret)
Before attack:
array2[ 0*4096]
• Train branch predictor to expect if() is true array2[ 1*4096]
array2[ 2*4096]
(e.g. call with x < array1_size) array2[ 3*4096]
array2[ 4*4096]
• Evict array1_size and array2[ 5*4096]
array2[ 6*4096] Contents don’t matter
array2[] from cache array2[ 7*4096] only care about cache status
array2[ 8*4096]
Uncached Cached
array2[ 9*4096]
array2[10*4096]
array2[11*4096]

64
Conditional branch (Variant 1) attack
Memory & Cache Status
if (x < array1_size)
array1_size = 00000008
y = array2[array1[x]*4096];
Memory at array1 base:
8 bytes of data (value doesn’t matter)
Memory at array1 base+1000:
Attacker calls victim with x=1000 09 F1 98 CC 90...(something secret)

Speculative exec while waiting for array1_size: array2[ 0*4096]


array2[ 1*4096]
 Predict that if() is true array2[ 2*4096]
array2[ 3*4096]
 Read address (array1 base + x) array2[ 4*4096]
array2[ 5*4096]
(using out-of-bounds x=1000) array2[ 6*4096] Contents don’t matter
array2[ 7*4096] only care about cache status
 Read returns secret byte = 09 array2[ 8*4096]
Uncached Cached
array2[ 9*4096]
(in cache ⇒ fast ) array2[10*4096]
array2[11*4096]

65
Conditional branch (Variant 1) attack
Memory & Cache Status
if (x < array1_size)
array1_size = 00000008
y = array2[array1[x]*4096];
Memory at array1 base:
8 bytes of data (value doesn’t matter)
Memory at array1 base+1000:
Attacker calls victim with x=1000 09 F1 98 CC 90...(something secret)

Next: array2[ 0*4096]


array2[ 1*4096]
 Request mem at (array2 base + 09*4096) array2[ 2*4096]
array2[ 3*4096]
 Brings array2[09*4096] into the cache array2[ 4*4096]
array2[ 5*4096]
 Realize if() is false: discard speculative work array2[ 6*4096] Contents don’t matter
array2[ 7*4096] only care about cache status
array2[ 8*4096]
Uncached Cached
array2[ 9*4096]
Finish operation & return to caller array2[10*4096]
array2[11*4096]

66
Conditional branch (Variant 1) attack
Memory & Cache Status
if (x < array1_size)
array1_size = 00000008
y = array2[array1[x]*4096];
Memory at array1 base:
8 bytes of data (value doesn’t matter)
Memory at array1 base+1000:
09 F1 98 CC 90...(something secret)
Attacker calls victim with x=1000 array2[ 0*4096]
array2[ 1*4096]
array2[ 2*4096]
Attacker: array2[ 3*4096]
• measures read time for array2[i*4096] array2[ 4*4096]
array2[ 5*4096]
array2[ 6*4096] Contents don’t matter
• Read for i=09 is fast (cached), array2[ 7*4096] only care about cache status
reveals secret byte !! array2[ 8*4096]
Uncached Cached
array2[ 9*4096]
• Repeat with many x (10KB/s) array2[10*4096]
array2[11*4096]

67

You might also like