2!

Network  Security  
• ApplicaDon  layer  
– E-­‐mail:  PGP,  using  a  web-­‐of-­‐trust  
– Web:  HTTP-­‐S,  using  a  cerDficate  hierarchy  
• Transport  layer  
Network  Security  Protocols   – Transport  Layer  Security/  Secure  Socket  Layer  

Mike  Freedman   • Network  layer  

– IP  Sec  
COS  461:  Computer  Networks  
• Network  infrastructure  
h?p://www.cs.princeton.edu/courses/archive/spr14/cos461/   – DNS-­‐Sec  and  BGP-­‐Sec  

3! 4!

Basic  Security  ProperDes   Basic  Security  ProperDes  

• Confiden'ality:     • Confiden'ality:  Concealment  of  informaDon  or  resources  

• Authen'city:     • Authen'city:  IdenDficaDon  and  assurance  of  origin  of  info  

• Integrity:   • Integrity:  Trustworthiness  of  data  or  resources  in  terms  of  
prevenDng  improper  and  unauthorized  changes  

• Availability:     • Availability:  Ability  to  use  desired  informaDon  or  resource  

• Non-­‐repudia'on:   • Non-­‐repudia'on:  Offer  of  evidence  that  a  party  indeed  is  

sender  or  a  receiver  of  certain  informaDon  

• Access  control:   • Access  control:  FaciliDes  to  determine  and  enforce  who  is  
allowed  access  to  what  resources  (host,  soWware,  network,  …)  

1
 5! 6!

EncrypDon  and  MAC/Signatures  

ConfidenDality  (EncrypDon)   Auth/Integrity  (MAC  /  Signature)  

Sender:     Sender:     Email  Security:    
•    Compute  C  =  EncK(M)   •    Compute  s  =  SigK(Hash  (M))   Pre?y  Good  Privacy  (PGP)  
•    Send  C   •    Send  <M,  s>  
Receiver:   Receiver:  
•    Recover  M  =  DecK(C)   •    Compute  s’  =  VerK(Hash  (M))    
•    Check  s’  ==  s  

These  are  simplified  forms  of  the  actual  algorithms  

7! 8!

E-­‐Mail  Security   Sender  and  Receiver  Keys  

• Security  goals   • If  the  sender  knows  the   • If  the  receiver  knows  
– ConfidenDality:  only  intended  recipient  sees  data   receiver’s  public  key   the  sender’s  public  key  
– Integrity:  data  cannot  be  modified  en  route   – ConfidenDality   – Sender  authenDcaDon  
– AuthenDcity:  sender  and  recipient  are  who  they  say   – Receiver  authenDcaDon   – Sender  non-­‐repudiaDon  

• Security  non-­‐goals  
– Timely  or  successful  message  delivery  
– Avoiding  duplicate  (replayed)  message  
– (Since  e-­‐mail  doesn’t  provide  this  anyway!)  

2
 9! 10!

Sending  an  E-­‐Mail  Securely   Public  Key  CerDficate  

• Sender  digitally  signs  the  message   • Binding  between  idenDty  and  a  public  key  
– Using  the  sender’s  private  key   – “IdenDty”  is,  for  example,  an  e-­‐mail  address  
– “Binding”  ensured  using  a  digital  signature  
• Sender  encrypts  the  data  
– Using  a  one-­‐Dme  session  key   • Contents  of  a  cerDficate  
– Sending  the  session  key,  encrypted  with  the   – IdenDty  of  the  enDty  being  cerDfied  
receiver’s  public  key   – Public  key  of  the  enDty  being  cerDfied  
– IdenDty  of  the  signer  
• Sender  converts  to  an  ASCII  format  
– Digital  signature  
– ConverDng  the  message  to  base64  encoding  
– Digital  signature  algorithm  id  
– (Email  messages  must  be  sent  in  ASCII)  

11! 12!

Web  of  Trust  for  PGP  

• Decentralized  soluDon  
– ProtecDon  against  government  intrusion  
– No  central  cerDficate  authoriDes  

• Customized  soluDon   HTTP  Security  

– Individual  decides  whom  to  trust,  and  how  much  
– MulDple  cerDficates  with  different  confidence  levels  

• Key-­‐signing  parDes!  
– Collect  and  provide  public  keys  in  person  
– Sign  other’s  keys,  and  get  your  key  signed  by  others  

3
 13! 14!

HTTP  Threat  Model   HTTP-­‐S:  Securing  HTTP  

• Eavesdropper     • HTTP  sits  on  top  of  secure  
HTTP  
– Listening  on  conversaDon  (confidenDality)   channel  (SSL/TLS)  
• Man-­‐in-­‐the-­‐middle     – h?ps://  vs.  h?p://   Secure  Transport  
Layer  
– Modifying  content  (integrity)   – TCP  port  443  vs.  80  
TCP  
• ImpersonaDon   • All  (HTTP)  bytes  encrypted  
– Bogus  website  (authenDcaDon,  confidenDality)   and  authenDcated   IP  
– No  change  to  HTTP  itself!  
Link  layer  
• Where  to  get  the  key???  

15! 16!

Learning  a  Valid  Public  Key   Hierarchical  Public  Key  Infrastructure  

• Public  key  cerDficate    
– Binding  between  idenDty  and  a  public  key  
• What  is  that  lock?  
– “IdenDty”  is,  for  example,  a  domain  name  
– Securely  binds  domain  name  to  public  key  (PK)   – Digital  signature  to  ensure  integrity  
• If  PK  is  authenDcated,  then  any  message  signed  by  that  
PK  cannot  be  forged  by  non-­‐authorized  party   • CerDficate  authority  
– Believable  only  if  you  trust  the  a?esDng  body   – Issues  public  key  cerDficates  and  verifies  idenDDes  
• Bootstrapping  problem:    Who  to  trust,  and  how  to  tell  if   – Trusted  parDes  (e.g.,  VeriSign,  GoDaddy,  Comodo)  
this  message  is  actually  from  them?  
– Preconfigured  cerDficates  in  Web  browsers  

4
 17! 18!

Public  Key  CerDficate  

Transport  Layer  Security  (TLS)  

Based  on  the  earlier  Secure  Socket  Layer  

(SSL)  originally  developed  by  Netscape  

19! 20!

TLS  Handshake  Protocol   TLS  Record  Protocol    

• Messages  from  applicaDon  layer  are:  
• Send  new  random  value,    
list  of  supported  ciphers   – Fragmented  or  coalesced  into  blocks  
• Send  new  random  value,          
– OpDonally  compressed  
digital  cerDficate  with  PK  
• Send  pre-­‐secret,  encrypted   – Integrity-­‐protected  using  an  HMAC  
under  PK  
– Encrypted  using  symmetric-­‐key  cipher  
• Create  shared  secret  key   • Create  shared  secret  key   – Passed  to  the  transport  layer  (usually  TCP)  
from  pre-­‐secret  and  random     from  pre-­‐secret  and  random  
• Switch  to  new  symmetric-­‐
• Sequence  #s  on  record-­‐protocol  messages  
• Switch  to  new  symmetric-­‐
key  cipher  using  shared  key   key  cipher  using  shared  key   – Prevents  replays  and  reorderings  of  messages  

5
 21! 22!

Comments  on  HTTPS  

• HTTPS  authenDcates  server,  not  content  
– If  CDN  (Akamai)  serves  content  over  HTTPS,  
customer  must  trust  Akamai  not  to  change  content  

• Symmetric-­‐key  crypto  aWer  public-­‐key  ops   IP  Security  

– Handshake  protocol  using  public  key  crypto  
– Symmetric-­‐key  crypto  much  faster  (100-­‐1000x)  

• HTTPS  on  top  of  TCP,  so  reliable  byte  stream  

– Can  leverage  fact  that  transmission  is  reliable  to  
ensure:  each  data  segment  received  exactly  once  
– Adversary  can’t  successfully  drop  or  replay  packets  

23! 24!

IP  Security   IPSec  
• There  are  range  of  app-­‐specific  security  mechanisms   • General  IP  Security  framework  
– eg.  TLS/HTTPS,  S/MIME,  PGP,  Kerberos,  …  

• But  security  concerns  that  cut  across  protocol  layers   • Allows  one  to  provide  
• Implement  by  the  network  for  all  applicaDons?   – Access  control,  integrity,  authenDcaDon,  originality,  
and  confidenDality    

• Applicable  to  different  selngs  

               Enter  IPSec!   – Narrow  streams:  Specific  TCP  connecDons  
– Wide  streams:    All  packets  between  two  gateways  

6
 25! 26!

IPSec  Uses   Benefits  of  IPSec  

• If  in  a  firewall/router:  
– Strong  security  to  all  traffic  crossing  perimeter  
– Resistant  to  bypass  
• Below  transport  layer  
– Transparent  to  applicaDons  
– Can  be  transparent  to  end  users  
• Can  provide  security  for  individual  users  

27! 28!

IP  Security  Architecture   EncapsulaDng  Security  Payload  (ESP)  

• SpecificaDon  quite  complex   • Transport  mode:  Data  encrypted,  but  not  header  
– Mandatory  in  IPv6,  opDonal  in  IPv4   – AWer  all,  network  headers  needed  for  rouDng!  
– Can  sDll  do  traffic  analysis,  but  is  efficient  
• Two  security  header  extensions:  
– Good  for  host-­‐to-­‐host  traffic  
– AuthenDcaDon  Header  (AH)  
• ConnecDonless  integrity,  origin  authenDcaDon   • Tunnel  mode:  Encrypts  enDre  IP  packet  
– MAC  over  most  header  fields  and  packet  body  
– Add  new  header  for  next  hop  
• AnD-­‐replay  protecDon  
– Good  for  VPNs,  gateway-­‐to-­‐gateway  security  
– EncapsulaDng  Security  Payload  (ESP)  
• These  properDes,  plus  confidenDality  

7
 29! 30!

Replay  ProtecDon  is  Hard  

• Goal:  Eavesdropper  can’t  capture  encrypted  packet  
and  duplicate  later  
– Easy  with  TLS/HTTP  on  TCP:    Reliable  byte  stream  
– But  IP  Sec  at  packet  layer;  transport  may  not  be  reliable  
DNS  Security  
• IP  Sec  soluDon:    Sliding  window  on  sequence  #’s  
– All  IPSec  packets  have  a  64-­‐bit  monotonic  sequence  number  
– Receiver  keeps  track  of  which  seqno’s  seen  before  
• [lastest  –  windowsize  +  1  ,    latest]  ;        windowsize  typically  64  packets  
– Accept  packet  if    
• seqno  >  latest      (and  update  latest)  
• Within  window  but  has  not  been  seen  before  
– If  reliable,  could  just  remember  last,  and  accept  iff  last  +  1  

Hierarchical  Naming  in  DNS   DNS  Root  Servers  

unnamed root • 13  root  servers  (see  h?p://www.root-­‐servers.org/)  
• Labeled  A  through  M  
com edu org ac uk zw arpa A Verisign, Dulles, VA
C Cogent, Herndon, VA (also Los Angeles)
generic domains country domains D U Maryland College Park, MD
in- G US DoD Vienna, VA
bar ac addr H ARL Aberdeen, MD K RIPE London (+ Amsterdam, Frankfurt)
J Verisign, ( 11 locations) I Autonomica, Stockholm
E NASA Mt View, CA (plus 3 other locations)
F Internet Software C. Palo
west east cam 12 Alto, CA (and 17 other m WIDE Tokyo
locations)

foo my usr 34
my.east.bar.edu usr.cam.ac.uk B USC-ISI Marina del Rey, CA
L ICANN Los Angeles, CA
56
12.34.56.0/24 31
32

8
 33! 34!

DoS  a?acks  on  DNS  Availability   Defense:  ReplicaDon  and  Caching  

• Feb.  6,  2007  

– Botnet  a?ack  on  the  13  Internet  DNS  root  servers  
– Lasted  2.5  hours  
– None  crashed,  but  two  performed  badly:  
• g-­‐root  (DoD),      l-­‐root    (ICANN)  
• Most  other  root  servers  use  anycast  

source: wikipedia!

35   36!

Denial-­‐of-­‐Service  A?acks  on  Hosts   PrevenDng  AmplificaDon  A?acks  

×40    amplificaDon  
ip spoofed packets!
open  
aKacker   amplifier  
DNS  Query  
SrcIP:  DoS  Target   DNS  Response  
!
ies
pl

       (60  bytes)   (3000  bytes)  

re

DNS   prevent   disable  

DoS   DoS  
Source  
Server  
Target   ip  spoofing   open  amplifiers  

580,000  open  resolvers  on  Internet    (Kaminsky-­‐Shiffman’06)  

victim!

9
 37! 38!

DNS  Integrity  and  the  TLD  Operators   DNS  Integrity:  Cache  Poisoning  
• If  domain  name  doesn’t  exist,  DNS  should   • Was  answer  from  an  authoritaDve  server?  
return  NXDOMAIN  (non-­‐existant  domain)  msg   – Or  from  somebody  else?  
• Verisign  instead  creates  wildcard  records  for   • DNS  cache  poisoning  
all  .com  and  .net  names  not  yet  registered   – Client  asks  for  www.evil.com  
– September  15  –  October  4,  2003   – Nameserver  authoritaDve  for  www.evil.com  returns  
addiDonal  secDon  for  (www.cnn.com,  1.2.3.4,  A)  
• RedirecDon  for  these  domain  names  to  Verisign  
– Thanks!    I  won’t  bother  check  what  I  asked  for  
web  portal:    “to  help  you  search”  
– And  serve  you  ads…and  get  “sponsored”  search  
– Verisign  and  online  adverDsing  companies  make  $$  

39! 40!

DNS  Integrity:  DNS  Hijacking   Let’s  strongly  believe  the  answer!  

• To  prevent  cache  poisoning,  client  remembers:  
Enter  DNSSEC  
– The  domain  name  in  the  request  
• DNSSEC  protects  against  data  spoofing  and  
– A  16-­‐bit  request  ID  (used  to  demux  UDP  response)    
corrupDon  
• DNS  hijacking  
– 16  bits:    65K  possible  IDs   • DNSSEC  also  provides  mechanisms  to  
– What  rate  to  enumerate  all  in  1  sec?    64B/packet   authenDcate  servers  and  requests  
– 64*65536*8  /  1024  /  1024  =  32  Mbps  
• DNSSEC  provides  mechanisms  to  establish  
• PrevenDon:  also  randomize  DNS  source  port  
authenDcity  and  integrity  
– Kaminsky  a?ack:  this  source  port…  wasn’t  random  
http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html!

10
 41! 42  

PK-­‐DNSSEC  (Public  Key)   Verifying  the  Tree  

• The  DNS  servers  sign  the  hash  of  resource   Ques'on:    www.cnn.com      ?  
record  set  with  its  private  (signature)  keys  
– Public  keys  can  be  used  to  verify  the  SIGs   m  
A  ?
 
.  (root)  
dns.cs.princeton.edu .co
. c nn
src.cs.princeton.edu   w
ww
• Leverages  hierarchy:  
                   ask  .com  server  
www.cnn.com  A  ?    SIG  (ip  addr  and  PK  of  .com  server)  
stub  
– AuthenDcity  of  name  server’s  public  keys  is    resolver   xxx.xxx.xxx.xxx   resolver   www.cnn.com  A  ?  
.com  
established  by  a  signature  over  the  keys  by  the   transac'on    
signatures  
ask  cnn.com  server        
SIG  (ip  addr  and  PK  of  cnn.com  server)  
parent’s  private  key   ww
add  to  cache   SIG w.
cn
– In  ideal  case,  only  roots’  public  keys  need  to  be    (x
xx
.xx
n.
co
m
x.x  A
distributed  out-­‐of-­‐band   xx
.xx
 ?  
x)  

cnn.com  

43!

Conclusions  
• Security  at  many  layers  
– ApplicaDon,  transport,  and  network  layers  
– Customized  to  the  properDes  and  requirements  
• Exchanging  keys  
– Public  key  cerDficates  
– CerDficate  authoriDes  vs.  Web  of  trust  
• Next  Dme  
– Interdomain  rouDng  security  
• Learn  more:  take  COS  432  in  the  fall!  

11