Dyadic’s  DSM  Web  Suite  Use-­‐Cases     Dyadic’s   web   suite   provides   all   the   functionality   necessary   for   protecting   web   applications.   This   includes   SSL   (the   protocol   used   for   protect   web   sessions),   application-­‐layer   encryption   (for   sensitive   client   data,   credit   card   numbers,   etc.),   password   protection,   and   cookie   encryption   and   signing.   Dyadic’s   DSM   protects   the   keys  used  in  these  operations  and  provides  password  protection  so  that  in  the  event  of   a   breach,   these   highly   valuable   assets   remain   protected.   Web   servers   and   web   applications   are   typically   the   most   vulnerable   to   attack,   and   current   methods   of   perimeter  protection  and  intrusion  detection  do  not  suffice  for  achieving  security.  Thus,   the  deployment  of  DSM  protection  in  this  scenario  is  a  must.  

Web  Transaction  Security  with  SSL   SSL/TLS   is   the   protocol   used   by   every   web   browser   to   protect   web   transactions.   It   is   also  used  in  multiple  other  scenarios  to  protect  traffic  sent  between  servers  and  clients.   The  SSL  protocol  has  two  parts.  The  first  part  is  called  the  handshake  protocol;  in  this   part   the   machines   running   the   protocol   generate   ephemeral   symmetric   session   keys,   using  a  long-­‐term  asymmetric  key.  In  most  installations,  RSA  is  used  in  this  step,  and  the   server  carries  out  a  single  RSA  operation.  The  second  part  is  called  the  record  layer,  and   it   is   responsible   for   the   encryption   and   authentication   of   all   of   the   traffic   sent.   The   symmetric  keys  generated  in  the  handshake  protocol  are  those  used  in  the  record  layer.     The   RSA   private   key   held   by   the   server   is   extraordinarily   sensitive.   If   it   is   stolen,   the   security   provided   by   SSL   is   completely   compromised.   In   the   majority   of   SSL   installations,   once   the   key   is   stolen   it   is   possible   to   decrypt   everything   sent   by   simply   eavesdropping   on   the   encrypted   traffic.   If   a   forward-­‐secure   ciphersuite   is   used,   then   active  man-­‐in-­‐the-­‐middle  attacks  are  possible.  In  particular,  it  is  possible  to  setup  a  false   website   that   is   a   perfect   forgery   of   the   real   one.   This   makes   phishing   and   targeted   phishing  attacks  very  effective  and  impossible  to  detect.     In  SSL  installed  over  Dyadic’s  DSM  the  single  RSA  private-­‐key  operation  carried  out  in   the  handshake  protocol  by  the  web  server  is  run  inside  the  DSM.  This  protects  the  key   and   prevents   it   from   being   stolen,   even   if   the   attacker   breaches   the   web   server   and   other  parts  of  the  network.  Since  only  a  single  RSA  operation  is  diverted  to  the  DSM,  and   the  record  layer  is  unchanged,   there  is  almost  no  influence  on  performance.  In  addition,   SSL   installations   can   be   modified   to   work   with   Dyadic’s   DSM   by   configuration   only,   and   without  changing  any  code.    

DYADIC - Preventing the breach | [email protected] | www.dyadicsec.com  

            To   summarize,   we   depict   the   current   methodology   for   the   SSL   handshake,   versus   Dyadic’s  DSM  secured  SSL.    

Current  SSL   SSL  with  Dyadic’s  DSM  

 

Application-­‐Layer  Data  Encryption   Web  applications  that  store  sensitive  data  need  to  encrypt  the  data  before  storing  it  in  a   database.   This   prevents   other   entities   from   accessing   the   data,   and   in   particular,   provides   protection   in   case   the   database   is   breached.   However,   since   the   web   server   needs   to   decrypt   the   data   before   using   it,   the   decryption   key   is   currently   stored   on   a   single   server,   typically   the   web   server   or   database.   This   current   method   of   operation   has   the   inherent   weakness   that   if   the   web   server   is   breached,   then   the   entire   encrypted   database   can   be   dumped   and   the   key   stolen.   Given   the   decryption   key,   the   protection   provided  by  encryption  is  completely  lost.     Dyadic’s   DSM   application-­‐layer   encryption   functionality   enables   the   web   server   to   encrypt   and   decrypt   data,   without   holding   the   secret   key.   Rather,   decryption   requests  

DYADIC - Preventing the breach | [email protected] | www.dyadicsec.com  

            are  sent  externally  to  the  DSM.  This  protects  the  key  and  means  that  even  if  the  entire   encrypted  database  is  stolen,  the  attackers  can  learn  nothing.  If  a  large  data  object  need   to  be  encrypted,  then  this  can  be  achieved  efficiently  by  encrypting  an  ephemeral  AES   key  with  the  DSM,  and  then  encrypting  the  data  object  (and  only  this  data  object)  with   the   ephemeral   key.   The   encrypted   ephemeral   key   is   stored   together   with   the   encrypted   data  object.  This  is  the  standard  “hybrid  encryption”  method  also  used  when  encrypting   with   asymmetric   encryption.   The   result   is   highly   efficient   and   effective.   On   4   pairs   of   8-­‐ core   2.1GHz   machines,   Dyadic’s   DSM   carries   out   3000   decryption   operations   per   second.     To   summarize,   we   depict   the   current   methodology   for   application-­‐layer   encryption,   versus  Dyadic’s  DSM  encryption.   Current  Application-­‐Layer  Encryption  

Encryption  with  Dyadic’s  DSM  

  DYADIC - Preventing the breach | [email protected] | www.dyadicsec.com  

       

 

 

Password  Protection   The   current   best   practice   for   protecting   passwords   is   hashing   and   salting   them   (technically,  this  means  that  random  salt  is  chosen  per  record,  stored  next  to  the  hashed   password,  and  included  in  the  hash  computation).  Cryptographic  hash  functions  can  be   easily   computed   but   not   inverted.   Thus,   if   an   attacker   obtains   the   hashed   password,   then   it   cannot   invert   the   function   to   find   the   password.   The   inclusion   of   salt   prevents   advanced   time-­‐space   tradeoffs   attacks,   like   rainbow   tables.   However,   the   unfortunate   fact  is  that  it  is  not  necessary  to   invert  the  hash  function  in  order  to  learn  the  password.   Rather,  it  suffices  to  try  many  password  guesses,  compute  the  hash  (together  with  the   salt)   and   see   if   the   result   matches.   In   order   to   slow   down   such   brute-­‐force   attacks,   hash   iterations  are  used.  Thus,  the  best  practice  today  is  to  store  (salt,  HASH1000(pwd,salt)).   As  appealing  as  this  sounds,  for  $10,000  it  is  possible  to  buy  a  machine  that  computes   approximately   five   billion   hash   function   computations   per   second.   Thus,   with   1000   iterations,   it   is   still   possible   to   verify  5   million   password   guesses   a   second.   The   result   is   that   90%   of   an   organization’s   passwords   are   revealed   in   very   short   time   with   these   attacks   (very   sophisticated   dictionaries   have   been   built   that   speed   up   this   process   by   guessing  more  probable  passwords  first).     Dyadic’s   password   protection   takes   the   hashed   and   salted   password   and   encrypts   it   with  a  highly  secure  Elliptic  curve  based  encryption  scheme.  The  novelty  of  the  solution   is  that  password  validation  takes  place  without   ever   decrypting   the   encrypted   password.   Rather,   when   a   user   logs   in,   the   encrypted   hashed   password   is   retrieved   from   the   database,  and  sent  together  with  the  password  sent  for  the  logon  to  the  DSM.  The  DSM   then   carries   out   an   advanced   protocol   that   verifies   whether   the   password   sent   was   correct,  without  ever  decrypting  the  ciphertext  or  bringing  the  key  together.  Thus,  even   if  an  attacker  breaches  the  web  server,  it  cannot  do  anything  but  query  the  DSM  asking   if  a  given  password  is  correct.  This  is  an  online  guessing  attack  and  is  not  effective  at  all   (it   takes   a   long   time,   is   easily   discovered,   and   is   easily   thwarted   by   using   standard   methods   like   a   retry   counter).   Indeed,   the   same   attack   can   be   carried   out   from   a   web   browser  outside  of  the  network  and  so  the  breach  is  completely  ineffective.  We  stress   that   an   attacker   who   steals   the   password   database   cannot   learn   anything   since   it   is   encrypted   with   a   highly   secure   encryption   key.   Thus,   the   huge   damage   of   massive   password   theft   is   completely   mitigated   using   Dyadic’s   solution.   We   also   remark   that   since   the   existing   hashed   password   is   encrypted,   user’s   do   not   need   to   change   their   password   and   do   not   even   need   to   know   that   any   change   has   been   made   to   the   system.   This  makes  deployment  very  easy.          

DYADIC - Preventing the breach | [email protected] | www.dyadicsec.com  

            To   summarize,   we   depict   the   current   methodology   for   password   protection,   versus   Dyadic’s  DSM  password  protection.     Current  Password  Protection  

    Password  Protection  with  Dyadic’s  DSM  

 

Secure  Cookies   Encrypted   and   signed   cookies   are   used   in   almost   all   websites   in   order   to   reduce   the   state   stored   at   web   servers.   The   security   of   cookies   is   paramount   to   the   security   of   a   website.  If  cookies  can  be  forged,  then  depending  on  their  purpose,  it  may  be  possible  to   bypass  the  authentication  mechanism  of  the  website,  it  may  be  possible  to  modify  prices   on   eCommerce   websites,   and   more.   In   current   configurations,   the   keys   used   for  

DYADIC - Preventing the breach | [email protected] | www.dyadicsec.com  

            encrypting  and  signing  cookies  are  stored  on  the  web  server,  and  thus  are  vulnerable  to   theft  in  the  case  of  a  breach.     Dyadic’s  DSM  enables  encryption  and  signing  of  cookies  inside  the  DSM.  This  prevents   theft  of  the  keys  used  for  securing  the  cookies,  thereby  restoring  the  security  to  the  web   application   afforded   by   unforgeable   cookies.   We   remark   that   for   cookie   signing,   it   is   only   the   signing   operation   that   takes   place   inside   the   DSM,   and   the   verification   operation  relies  only  on  a  public  key  and  so  can  be  carried  out  locally  by  the  web  server.   Since   the   cookies   signing   operation   takes   place   rarely   in   comparison   to   cookie   verification,  this  has  almost  no  affect  on  performance.     To   summarize,   we   depict   the   current   methodology   for   cookie   signing,   versus   Dyadic’s   DSM  cookie  protection.     Current  Cookie  Signing  

  Cookie  Signing  with  Dyadic’s  DSM  

 

DYADIC - Preventing the breach | [email protected] | www.dyadicsec.com