Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How I Learned to Stop Worrying and Trust Crypto Again


Published on

Video and slides synchronized, mp3 and slide download available at URL

Graham Steel takes a look at some of the cryptographic standards whose security is the subject of speculation and tries to separate rumor from fact. Then he examines some of most widely encountered crypto APIs, evaluating them on two important axes: facilities for flexible, secure key management and provision of modern cryptographic primitives. Filmed at

Graham Steel has been a researcher at INRIA, the French national agency for computer science research, since 2008. Based in Paris, he recently cofounded a spin-off company, Cryptosense, which provides vulnerability analysis tools for cryptographic systems to an international clientele in particular in the financial, industrial and government sectors.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

How I Learned to Stop Worrying and Trust Crypto Again

  1. 1. GRAHAM  STEEL December  2013   CRYPTOSENSE   @graham_steel   How  I  Learned  to  Stop  Worrying     and  Trust  Crypto  Again  
  2. 2. News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month Watch the video with slide synchronization on! /strategy-cryptographic-api
  3. 3. Presented at QCon London Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  4. 4. March  2014   CRYPTOSENSE   2  
  5. 5. 2013:  The  Paranoids  Were  Right March  2014   CRYPTOSENSE   3   BUT  “Properly  implemented  strong  crypto  systems  are  one  of   the  few  things  that  you  can  rely  on"  
  6. 6. How  does  cryptography  get  deployed?   Scenario  1:  Cryptographer’s  dream       Step  1:  Project  manager  and  client  evaluate   security  goals  and  threat  scenario   March  2014   CRYPTOSENSE   4  
  7. 7. How  does  cryptography  get  deployed?   Scenario  1:  Cryptographer’s  dream     Engineers  and  PM  choose  appropriate  security  noVon   March  2014   CRYPTOSENSE   5  
  8. 8. How  does  cryptography  get  deployed?   Scenario  1:  Cryptographer’s  dream     Engineers  consult  the  literature   March  2014   CRYPTOSENSE   6  
  9. 9. How  does  cryptography  get  deployed?   Scenario  2:  Cryptographer’s  nightmare     Engineers  plan  some  fun  crypto  stuff   March  2014   CRYPTOSENSE   7  
  10. 10. How  does  cryptography  get  deployed?   Scenario  2:  Cryptographer’s  nightmare     Engineers  consult  the  literature   March  2014   CRYPTOSENSE   8  
  11. 11. How  does  cryptography  get  deployed?   Scenario  2:  Cryptographer’s  nightmare   March  2014   CRYPTOSENSE   9  
  12. 12. How  does  cryptography  get  deployed?   Scenario  3:  Reality     Client  tells  PM  project  must  use  certain  crypto  APIs   for  compliance/hardware  interop/legacy  reasons   March  2014   CRYPTOSENSE   10  
  13. 13. How  does  cryptography  get  deployed?   Scenario  3:  Reality     PM  tells  engineer  to  use  that  API     March  2014   CRYPTOSENSE   11  
  14. 14. How  does  cryptography  get  deployed?   Scenario  3:  Reality     What  happens  next  is  the  subject  of  this  talk:     • How  good  are  the  common  APIs?   • How  can  we  use  them  securely?   March  2014   CRYPTOSENSE   12  
  15. 15. Lesson  1:  Beware  of  Proprietary  APIs March  2014   CRYPTOSENSE   13  
  16. 16. What  makes  a  good  crypto  API? At  least  the  following:   1.  Is  it  open  and  subject  to  review?   2.  Does  it  support  modern  cryptographic   primiVves?   3.  Does  it  support  flexible,  secure  key   management?   4.  Is  it  mistake-­‐resistant?   5.  Will  it  interoperate  with  other  stuff?   March  2014   CRYPTOSENSE   14  
  17. 17. PKCS#11   Almost  ubiquitous  for  cryptographic  hardware     Originally  an  RSA  standard,  moved  to  OASIS  in  2013       Version  1.0  of  PKCS#11  1995,  current  version  2.20   2004(!),  v2.40  due  RSN     Defined  as  a  C  header  file  +  400  page  document   describing  what  the  funcVons  should  do     The  standard  is  quite  loose:  every  implementaVon   is  different     March  2014   CRYPTOSENSE   15  
  18. 18. Assessment  of  PKCS#11 1.  Since  2013  the  API  is  open  (before  not  clear),   but  actual  implementaVons  may  be  closed   2.  v2.40  will  have  some  more  modern  crypto  (e.g.   GCM)  but  sVll  lots  of  legacy  stuff     3.  Key  management  is  provided  for  but  has  many   pinalls  (see  BCFS  CCS  ’10)   4.  Not  very  mistake  resistant  (low  level)   5.  Good  interoperability  across  planorms   March  2014   CRYPTOSENSE   16  
  19. 19. Java  JCA/JCE   The  standard  Java  crypto  interface       Consists  of  APIs  (,  javax.crypto  etc.)   and  providers  that  implement  those  interfaces   (SunRSASign,  SunJCE,  Bouncy  Castle  etc.)     Widespread  adopVon  in  enterprise  Java  world       Hardware  support  limited  (needs  proprietary   extensions  or  alternaVve  APIs  to  handle  login,   sessions,  most  key  management  funcVons).   March  2014   CRYPTOSENSE   17  
  20. 20. Assessment  of  Java  JCE/JCA 1.  The  API  is  under  Oracle’s  control.  Providers   someVmes  open  (like  Bouncy  Castle)   2.  API  extensible,  providers  support  some  modern   crypto  (e.g.  GCM)  but  also  much  legacy  stuff   (e.g.  RC2)   3.  Some  key  management  via  Keystore.  Not  much   public  security  analysis  of  this.   4.  Not  especially  mistake  resistant     5.  Interoperability  between  providers  good,  also   can  have  e.g.  PKCS#11  provider   March  2014   CRYPTOSENSE   18  
  21. 21. OpenSSL   Originally  an  open  source  implementaVon  for  TLS/ SSL,  now  used  for  almost  anything   1.  Source  available,  but  decision  process  murky   2.  Contains  legacy  crypto  (as  does  SSL!)  as  well  as   some  modern  extensions   3.  Minimal  key-­‐management  faciliVes   4.  Very  easy  to  get  wrong  (see  references)   5.  Compiled  everywhere,  TLS  interop  ok   March  2014   CRYPTOSENSE   19  
  22. 22. MS  CAPI/CNG CNG  slowly  replacing  CAPI  on  MS  planorms   1.  Proprietary,  most  providers  closed   2.  CNG  contains  some  modern  crypto,  CAPI  not  so   much   3.  No  management  of  persistent  symmetric  keys   4.  Plenty  of  things  to  get  wrong  (e.g.  contains  the   NSA  backdoored  RNG)   5.  Not  very  interoperable     March  2014   CRYPTOSENSE   20  
  23. 23. W3C  Crypto  API   A  new  project  of  the  W3C  to  make  crypto  available   in  the  browser  to  HTML5  apps     Contains  modern  crypto,  but  despite  fresh  start,   also  contains  legacy  crypto.     Some  key-­‐management  (details  sVll  being   hammered  out)     Some  effort  to  make  it  easier  to  use  (SubtleCrypto   vs  WorkerCrypto,  IV  management,…)   March  2014   CRYPTOSENSE   21  
  24. 24. Other  libraries   NaCl  –  a  crypto  lib  by  Dan  Bernstein     Nice  high  level  design  but  favours  Dan  Berstein   primiVves  (which  may  well  be  secure  but  have  not   been  subject  to  as  much  review  as  e.g.  AES)     cryptlib  –  C  crypto  library  by  Peter  Gusman     Supports  many  standard  protocols  with  nice  high   level  interface,  but  no  OAEP,  no  SHA-­‐2     March  2014   CRYPTOSENSE   22  
  25. 25. Crypto  API  Gotchas   So  you’ve  chosen  a  “good”  API,  a  sound   implementaVon,  what  could  possibly  go  wrong?     Everything.     Given  good  APIs,  even  domain  experts  make   mistakes  in  implemenVng  cryptography.     The  following  is  a  list  of  common  mistakes.   Avoiding  these  does  not  mean  your  crypto  is   secure,  but  it  should  reduce  your  consultancy   bill  ;-­‐)     -­‐  will  also  demonstrate  that  security  is  fractal   (Butler  Lampson)   March  2014   CRYPTOSENSE   23  
  26. 26. Examples  of  crypto  API  gotchas   • Legacy  algorithms,  modes,  oven  used  by  default   • e.g.  ECB  “mode”   “All  these  other  modes  need  iniValizaVon  vectors.  ECB   doesn’t.  I’ll  use  ECB”       March  2014   CRYPTOSENSE   24  
  27. 27. More  Crypto  API  Gotchas • Other  Block  cipher  modes:  IV  management  oven   lev  to  applicaVon.  Easy  to  get  wrong.   • Requirements  are  different  for  each  mode   • UnauthenVcated  encrypVon   • Don’t  think  you  need  it?  You  need  it.   • Less  error-­‐prone  (IMO)  to  use  an  authenVcated  mode   (like  AES-­‐GCM  or  RSA-­‐OAEP)  than  patch  a  MAC  around   AES-­‐CBC  or  RSA-­‐PKCS#1v1.5     • Random  number  generators  incorrectly  iniValized   ◦ Famous  recent  asacks  (Debian  OpenSSL,  GCD  RSA..)     March  2014   CRYPTOSENSE   25  
  28. 28. Protocols   Typically  crypto  operaVons  are  part  of  a  protocol     (think  SSH,  TLS,…)     If  you  roll  your  own  protocol,  even  if  all  your   crypto  is  secure  when  considered  in  isola6on,   probability  of  a  security  error  in  the  first  dra9  is  1.     Even  mature  protocols  have  flaws  (e.g.  TLS  –  yet   another  set  of  flaws  announced  Monday)     But  you’re  s6ll  be>er  off  following  a  standard   protocol  than  making  one  up.     March  2014   CRYPTOSENSE   26  
  29. 29. Conclusions   To  maximise  your  chances  of  producing  “strong   crypto  properly  implemented”   • Favour  open  API  standards  over  proprietary   • Look  out  for  legacy   • Check  out  the  well-­‐known  pinalls,  avoid  them   • Review,  review,  review!   March  2014   CRYPTOSENSE   27  
  30. 30. References Egele  et  al.,  “An  empirical  study  of  cryptographic   misuse  in  android  applicaVons.”  CCS  2013.   Fahl  et  al.  “Why  eve  and  mallory  love  android:  An   analysis  of  android  SSL  (in)security”  CCS  2012   Bortolozzo  et  al.  “Asacking  and  Fixing  PKCS#11   Security  Tokens”  CCS  2010   Meyer  &  Schwenk  “Lessons  Learned  from  Previous   SSL/TLS  Asacks”  S&P  2013   Most  recent  TLS  asacks  secure-­‐     March  2014   CRYPTOSENSE   28  
  31. 31. March  2014   CRYPTOSENSE   29   Thanks   @graham_steel  
  32. 32. Watch the video with slide synchronization on! cryptographic-api