Network

 Security  Essen1als  
Chapter  3  

Fourth  Edi1on  
by  William  Stallings    
 
 Public  Key  Cryptography  and  RSA  
 

Every  Egyp)an  received  two  names,  which  were  known  

respec)vely  as  the  true  name  and  the  good  name,  or  
the  great  name  and  the  li9le  name;  and  while  the  
good  or  li9le  name  was  made  public,  the  true  or  
great  name  appears  to  have  been  carefully  
concealed.  
—The  Golden  Bough,  Sir  James  George  Frazer  
 Outline  
•  Message  authen1ca1on  
•  Public-­‐key  cryptography  
•  Digital  signatures  
 Message  Authen1ca1on  
•  message  authen1ca1on  is  concerned  with:    
–  protec1ng  the  integrity  of  a  message    
–  valida1ng  iden1ty  of  originator    
–  non-­‐repudia1on  of  origin  (dispute  resolu1on)  
•  the  three  alterna1ve  func1ons  used:  
–  message  encryp1on  
–  hash  func1on  
–  message  authen1ca1on  code  (MAC)  
Message  Authen1ca1on  Code  
•  MACM=F(KAB,  M)  
–  Message  not  altered  
–  The  alleged  sender  confirmed  
–  The  proper  sequence  of  messages  assured  
•  Similar  to  encryp1on  
–  NIST  recommends  the  use  of  DES  
–  One  difference:  authen1ca1on  algorithm  need  not  
be  reversible,  less  vulnerable  
 Hash  Func1ons  
•  condenses  arbitrary  message  to  fixed  size  
h = H(M)    
–  No  secret  key  needed  
–  usually  assume  hash  func1on  is  public  
–  hash  used  to  detect  changes  to  message  
•  want  a  cryptographic  hash  func1on  
–  computa1onally  infeasible  to  find  data  mapping  to  
specific  hash  (one-­‐way  property)  
–  computa1onally  infeasible  to  find  two  data  to  same  
hash  (collision-­‐free  property)  
 Two  Simple  Insecure  Hash  
Func1ons  
•  consider  two  simple  insecure  hash  func1ons  
•  bit-­‐by-­‐bit  exclusive-­‐OR  (XOR)  of  every  block  
–  Ci  =  bi1  xor  bi2  xor  .  .  .  xor  bim    
–  a  longitudinal  redundancy  check  
–  reasonably  effec1ve  as  data  integrity  check  
•  one-­‐bit  circular  shiW  on  hash  value  
–  for  each  successive  n-­‐bit  block  
•  rotate  current  hash  value  to  leW  by1bit  and  XOR  block  
–  good  for  data  integrity  but  useless  for  security  
Simple  Hash  Func1on  Using  Bitwise  
XOR  
Hash  Func1on  Requirements  
 AZacks  on  Hash  Func1ons  
Ø have  brute-­‐force  aZacks  and  cryptanalysis  
Ø a  preimage  or  second  preimage  aZack  
l find  y    s.t.  H(y) equals  a  given  hash  value    
Ø collision  resistance  
l find    two  messages  x  &  y  with  same  hash  so  
H(x) = H(y)    
Ø hence  value  2m/2  determines  strength  of  hash  
code  against  brute-­‐force  aZacks  
l 128-­‐bits  inadequate,  160-­‐bits  suspect  
MD5  Opera1on  
 Secure  Hash  Algorithm  
•  SHA  originally  designed  by  NIST  &  NSA  in  1993  
•  was  revised  in  1995  as  SHA-­‐1  
•  US  standard  for  use  with  DSA  signature  scheme    
–  standard  is  FIPS  180-­‐1  1995,  also  Internet  RFC3174  
–  nb.  the  algorithm  is  SHA,  the  standard  is  SHS    
•  based  on  design  of  MD4  with  key  differences    
•  produces  160-­‐bit  hash  values    
•  recent  2005  results  on  security  of  SHA-­‐1  have  raised  
concerns  on  its  use  in  future  applica1ons  
 Revised  Secure  Hash  Standard  
•  NIST  issued  revision  FIPS  180-­‐2  in  2002  
–  adds  3  addi1onal  versions  of  SHA:    
SHA-­‐256,  SHA-­‐384,  SHA-­‐512  
–  designed  for  compa1bility  with  increased  security  
provided  by  the  AES  cipher  
–  structure  &  detail  is  similar  to  SHA-­‐1  
–  hence  analysis  should  be  similar,  but  security  levels  are  
rather  higher  
•  NIST  FIPS  180-­‐3  (in  2008)  adds  SHA-­‐224  
•  RFC  4634  details  SHA-­‐224,  -­‐256,  -­‐384,  -­‐512  
 SHA  Versions  
SHA-­‐1   SHA-­‐224   SHA-­‐256   SHA-­‐384   SHA-­‐512    
Message  
digest  size   160   224   256   384   512  

Message  size   <  264   <  264   <  264   <  2128   <  2128    
Block  size   512   512   512   1024   1024  
Word  size   32   32   32   64   64  
Number  of  
steps   80   64   64   80   80  
SHA-­‐512  Overview  
 SHA-­‐512  Compression  Func1on  
•  heart  of  the  algorithm  
•  processing  message  in  1024-­‐bit  blocks  
•  consists  of  80  rounds  
–  upda1ng  a  512-­‐bit  buffer    
–  using  a  64-­‐bit  value  Wt  derived  from  the  current  
message  block  
–  and  a  round  constant  based  on  cube  root  of  first  
80  prime  numbers  
 Keyed  Hash  Func1ons  as  MACs  
Ø want  a  MAC  based  on  a  hash  func1on    
l because  hash  func1ons  are  generally  faster  
l crypto  hash  func1on  code  is  widely  available  
Ø hash  includes  a  key  along  with  message  
Ø original  proposal:  
KeyedHash = Hash(Key|Message)
l some  weaknesses  were  found  with  this    
Ø eventually  led  to  development  of  HMAC    
 HMAC  Design  Objec1ves  
Ø use,  without  modifica1ons,  hash  func1ons  
Ø allow  for  easy  replaceability  of  embedded  hash  
func1on  
Ø preserve  original  performance  of  hash  func1on  
without  significant  degrada1on  
Ø use  and  handle  keys  in  a  simple  way.  
Ø have  well  understood  cryptographic  analysis  of  
authen1ca1on  mechanism  strength  
 HMAC  
•  specified  as  Internet  standard  RFC2104    
•  uses  hash  func1on  on  the  message:  
HMACK(M)= Hash[(K+ XOR opad) ||
Hash[(K+ XOR ipad) || M)] ]
–  where  K+ is  the  key  padded  out  to  size    
–  opad,  ipad are  specified  padding  constants    
•  overhead  is  just  3  more  hash  calcula1ons  than  the  
message  needs  alone  
•  any  hash  func1on  can  be  used  
–  eg.  MD5,  SHA-­‐1,  RIPEMD-­‐160,  Whirlpool  
 HMAC  
Overview  
 HMAC  Security  
•  proved  security  of  HMAC  relates  to  that  of  the  
underlying  hash  algorithm  
•  aZacking  HMAC  requires  either:  
–  brute  force  aZack  on  key  used  
–  birthday  aZack  (but  since  keyed  would  need  to  
observe  a  very  large  number  of  messages)  
•  choose  hash  func1on  used  based  on  speed  
verses  security  constraints  
1-­‐(364/365)30  àabout  7.9%  
1-­‐365!/((365-­‐n)!.365n)  à  about  70%
 CMAC  
•  previously  saw  the  DAA  (CBC-­‐MAC)  
•  widely  used  in  govt  &  industry  
•  but  has  message  size  limita1on  
•  can  overcome  using  2  keys  &  padding  
•  thus  forming  the  Cipher-­‐based  Message  
Authen1ca1on  Code  (CMAC)  
•  adopted  by  NIST  SP800-­‐38B  
CMAC  Overview  
 Authen1cated  Encryp1on  
Ø simultaneously  protect  confiden1ality  and  
authen1city  of  communica1ons  
l oWen  required  but  usually  separate  
Ø approaches  
l Hash-­‐then-­‐encrypt:  E(K,  (M  ||  H(M))  
l MAC-­‐then-­‐encrypt:  E(K2,  (M  ||  MAC(K1,  M))    
l Encrypt-­‐then-­‐MAC:  (C=E(K2,  M),  T=MAC(K1,  C)    
l Encrypt-­‐and-­‐MAC:  (C=E(K2,  M),  T=MAC(K1,  M)  
Ø   decryp1on  /verifica1on  straighlorward  
Ø but  security  vulnerabili1es  with  all  these  
 Counter  with  Cipher  Block  
Chaining-­‐Message  Authen1ca1on  
Code  (CCM)    
•  NIST  standard  SP  800-­‐38C  for  WiFi    
•  varia1on  of  encrypt-­‐and-­‐MAC  approach  
•   algorithmic  ingredients    
–  AES  encryp1on  algorithm  
–  CTR  mode  of  opera1on  
–  CMAC  authen1ca1on  algorithm  
•  single  key  used  for  both  encryp1on  &  MAC    
 CCM  
Opera1on  
 Private-­‐Key  Cryptography  
Ø tradi1onal  private/secret/single  key  
cryptography  uses  one  key    
Ø shared  by  both  sender  and  receiver    
Ø if  this  key  is  disclosed  communica1ons  are  
compromised    
Ø also  is  symmetric,  par1es  are  equal    
Ø hence  does  not  protect  sender  from  receiver  
forging  a  message  &  claiming  is  sent  by  sender    
 Public-­‐Key  Cryptography  
•  probably  most  significant  advance  in  the  3000  
year  history  of  cryptography    
•  uses  two  keys  –  a  public  &  a  private  key  
•  asymmetric  since  par1es  are  not  equal    
•  uses  clever  applica1on  of  number  theore1c  
concepts  to  func1on  
•  complements  rather  than  replaces  private  key  
crypto  
 Why  Public-­‐Key  Cryptography?  
•  developed  to  address  two  key  issues:  
–  key  distribuMon  –  how  to  have  secure  
communica1ons  in  general  without  having  to  
trust  a  KDC  with  your  key  
–  digital  signatures  –  how  to  verify  a  message  
comes  intact  from  the  claimed  sender  
•  public  inven1on  due  to  Whilield  Diffie  &  
Mar1n  Hellman  at  Stanford  Uni  in  1976  
–  known  earlier  in  classified  community  
 Public-­‐Key  Cryptography  
•  public-­‐key/two-­‐key/asymmetric  cryptography  involves  
the  use  of  two  keys:    
–  a  public-­‐key,  which  may  be  known  by  anybody,  and  can  be  
used  to  encrypt  messages,  and  verify  signatures    
–  a  related  private-­‐key,  known  only  to  the  recipient,  used  to  
decrypt  messages,  and  sign  (create)  signatures  
•  infeasible  to  determine  private  key  from  public  
•  is  asymmetric  because  
–  those  who  encrypt  messages  or  verify  signatures  cannot  
decrypt  messages  or  create  signatures  
Public-­‐Key  Cryptography  
 Example  –  Ecash

1.  The  buyer  gets  a  digitally  signed  note  from  the  bank.  

2.  The  buyer  spends  his  note  to  a  seller.  
3.  The  seller  deposits  his  note  in  his  bank  account.
Symmetric  vs  Public-­‐Key  
 RSA  
•  by  Rivest,  Shamir  &  Adleman  of  MIT  in  1977    
•  best  known  &  widely  used  public-­‐key  scheme    
•  based  on  exponen1a1on  in  a  finite  (Galois)  field  over  
integers  modulo  a  prime    
–  nb.  exponen1a1on  takes  O((log  n)3)  opera1ons  (easy)    
•  uses  large  integers  (eg.  1024  bits)  
•  security  due  to  cost  of  factoring  large  numbers    
–  nb.  factoriza1on  takes  O(e  log  n  log  log  n)  opera1ons  (hard)    
 RSA  En/decryp1on  
•  to  encrypt  a  message  M  the  sender:  
–  obtains  public  key  of  recipient  PU={e,n}    
–  computes:  C = Me mod n,  where  0≤M<n  
•  to  decrypt  the  ciphertext  C  the  owner:  
–  uses  their  private  key  PR={d,n}    
–  computes:  M = Cd mod n    
•  note  that  the  message  M  must  be  smaller  
than  the  modulus  n  (block  if  needed)  
 RSA  Key  Setup  
•  each  user  generates  a  public/private  key  pair  by:    
•  selec1ng  two  large  primes  at  random:  p, q    
•  compu1ng  their  system  modulus  n=p.q
–  note  ø(n)=(p-1)(q-1)  
•  selec1ng  at  random  the  encryp1on  key  e
–  where  1<e<ø(n), gcd(e,ø(n))=1
•  solve  following  equa1on  to  find  decryp1on  key  d    
–  e.d=1 mod ø(n) and 0≤d≤n    
•  publish  their  public  encryp1on  key:  PU={e,n}    
•  keep  secret  private  decryp1on  key:  PR={d,n}    
 Why  RSA  Works  
•  because  of  Euler's  Theorem:  
–  aø(n)mod n = 1 where  gcd(a,n)=1  
•  in  RSA  have:  
–  n=p.q
–  ø(n)=(p-1)(q-1)    
–  carefully  chose  e  &  d  to  be  inverses  mod ø(n)    
–  hence  e.d=1+k.ø(n)  for  some  k  
•  hence  :  
 Cd = Me.d = M1+k.ø(n) = M1.(Mø(n))k
= M1.(1)k = M1 = M mod n    
 RSA  Example  -­‐  Key  Setup  
1.  Select  primes:  p=17 & q=11  
2.  Calculate  n = pq =17 x 11=187
3.  Calculate  ø(n)=(p–1)(q-1)=16x10=160
4.  Select  e:  gcd(e,160)=1; choose  e=7  
5.  Determine  d:  de=1 mod 160  and  d < 160  
Value  is  d=23  since  23x7=161= 10x160+1
6.  Publish  public  key  PU={7,187}
7.  Keep  secret  private  key  PR={23,187}
 RSA  Example  -­‐  En/Decryp1on  
Ø sample  RSA  encryp1on/decryp1on  is:    
Ø given  message  M = 88  (nb.  88<187)  
Ø encryp1on:  
C = 887 mod 187 = 11    
Ø decryp1on:  
M = 1123 mod 187 = 88    
 Diffie-­‐Hellman  Key  Exchange  
•  first  public-­‐key  type  scheme  proposed    
•  by  Diffie  &  Hellman  in  1976  along  with  the  
exposi1on  of  public  key  concepts  
–  note:  now  know  that  Williamson  (UK  CESG)  
secretly  proposed  the  concept  in  1970    
•  is  a  prac1cal  method  for  public  exchange  of  a  
secret  key  
•  used  in  a  number  of  commercial  products  
 Diffie-­‐Hellman  Key  Exchange  
•  a  public-­‐key  distribu1on  scheme    
–  cannot  be  used  to  exchange  an  arbitrary  message    
–  rather  it  can  establish  a  common  key    
–  known  only  to  the  two  par1cipants    
•  value  of  key  depends  on  the  par1cipants  (and  their  
private  and  public  key  informa1on)    
•  based  on  exponen1a1on  in  a  finite  (Galois)  field  
(modulo  a  prime  or  a  polynomial)  -­‐  easy  
•  security  relies  on  the  difficulty  of  compu1ng  discrete  
logarithms  (similar  to  factoring)  –  hard  
 Diffie-­‐Hellman  Setup  
•  all  users  agree  on  global  parameters:  
–  large  prime  integer  or  polynomial  q
–  a  being  a  primi1ve  root  mod  q  
•  each  user  (eg.  A)  generates  their  key  
–  chooses  a  secret  key  (number):  xA < q    
xA
–  compute  their  public  key:  yA = a mod q
•   each  user  makes  public  that  key  yA
 Diffie-­‐Hellman  Key  Exchange  
•  shared  session  key  for  users  A  &  B  is  KAB:    
x x
KAB = a A. B mod q
xB
= yA mod q (which B can compute)
xA
= yB mod q (which A can compute)
•  KAB  is  used  as  session  key  in  private-­‐key  encryp1on  
scheme  between  Alice  and  Bob  
•  if  Alice  and  Bob  subsequently  communicate,  they  will  
have  the  same  key  as  before,  unless  they  choose  
new  public-­‐keys    
•  aZacker  needs  an  x,  must  solve  discrete  log  
 Diffie-­‐Hellman  Example    
•  users  Alice  &  Bob  who  wish  to  swap  keys:  
•  agree  on  prime  q=353  and  a=3
•  select  random  secret  keys:  
–  A  chooses  xA=97, B  chooses  xB=233
•  compute  respec1ve  public  keys:  
97
–  yA=3 mod 353 = 40 (Alice)  
233
–  yB=3 mod 353 = 248 (Bob)  
•  compute  shared  session  key  as:  
xA 97
–  KAB= yB mod 353 = 248 = 160 (Alice)  
xB 233
–  KAB= yA mod 353 = 40 = 160 (Bob)  
 Key  Exchange  Protocols  
•  users  could  create  random  private/public  D-­‐H  
keys  each  1me  they  communicate  
•  users  could  create  a  known  private/public  D-­‐H  
key  and  publish  in  a  directory,  then  consulted  
and  used  to  securely  communicate  with  them  
•  both  of  these  are  vulnerable  to  a  meet-­‐in-­‐the-­‐
Middle  AZack  
•  authen1ca1on  of  the  keys  is  needed  
 Man-­‐in-­‐the-­‐Middle  AZack  
1.  Darth  prepares  by  crea1ng  two  private  /  public    keys    
2.  Alice  transmits  her  public  key  to  Bob  
3.  Darth  intercepts  this  and  transmits  his  first  public  key  to  Bob.  
Darth  also  calculates  a  shared  key  with  Alice  
4.  Bob  receives  the  public  key  and  calculates  the  shared  key  (with  
Darth  instead  of  Alice)    
5.  Bob  transmits  his  public  key    to  Alice      
6.  Darth  intercepts  this  and  transmits  his  second  public  key  to  
Alice.  Darth  calculates  a  shared  key  with  Bob  
7.  Alice  receives  the  key  and  calculates  the  shared  key  (with  Darth  
instead  of  Bob)  
Ø  Darth  can  then  intercept,  decrypt,  re-­‐encrypt,  forward  all  
messages  between  Alice  &  Bob  
 Digital  Signatures  
•  have  looked  at  message  authen1ca1on    
–  but  does  not  address  issues  of  lack  of  trust  
•  digital  signatures  provide  the  ability  to:    
–  verify  author,  date  &  1me  of  signature  
–  authen1cate  message  contents    
–  be  verified  by  third  par1es  to  resolve  disputes  
•  hence  include  authen1ca1on  func1on  with  
addi1onal  capabili1es  
Digital  Signature  Model  
 Digital  
Signature  
Model