Your SlideShare is downloading. ×

Securing IoT Applications

1,078

Published on

Published in: Technology, Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,078
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
80
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Securing  the  Internet  of  Things   Paul  Fremantle   CTO,  WSO2  (paul@wso2.com)   PhD  researcher,  Portsmouth  University   (paul.fremantle@port.ac.uk)     @pzfreo  
  • 2. About  me   •  CTO  and  Co-­‐Founder   WSO2   – Open  Source  Middleware   plaLorm   •  Part-­‐Mme  PhD  looking  at   security   •  Working  in  Apache  for   14  years   •  Working  with  Cloud,   SOA,  APIs,  MQTT,  IoT   2  
  • 3. Firstly,  does  it  maQer?    
  • 4. “Google     Hacking”  
  • 5. hQp://www.forbes.com/sites/kashmirhill/2013/07/26/smart-­‐homes-­‐hack/    
  • 6. hQp://freo.me/1pbUmof  
  • 7. So  what  is  different  about  IoT?   •  The  longevity  of  the  device   –  Updates  are  harder  (or  impossible)   •  The  size  of  the  device   –  CapabiliMes  are  limited  –  especially  around  crypto   •  The  fact  there  is  a  device   –  Usually  no  UI  for  entering  userids  and  passwords   •  The  data   –  O_en  highly  personal   •  The  mindset   –  Appliance  manufacturers  don’t  think  like  security  experts   –  Embedded  systems  are  o_en  developed  by  grabbing  exisMng   chips,  designs,  etc  
  • 8. Physical  Hacks   A  PracMcal  AQack  on  the  MIFARE  Classic:     hQp://www.cs.ru.nl/~flaviog/publicaMons/AQack.MIFARE.pdf     Karsten  Nohl  and  Henryk  Plotz.  MIFARE,  LiQle  Security,  Despite  Obscurity  
  • 9. Or  try  this  at  home?   hQp://freo.me/1g15BiG    
  • 10. hQp://www.cl.cam.ac.uk/techreports/UCAM-­‐CL-­‐TR-­‐630.html    
  • 11. Hardware  recommendaMons   •  Don’t  rely  on  obscurity    
  • 12. Hardware  recommendaMons   •  Don’t  rely  on  obscurity   •  Don’t  rely  on  obscurity   •  Don’t  rely  on  obscurity   •  Don’t  rely  on  obscurity   •  Don’t  rely  on  obscurity   •  Don’t  rely  on  obscurity   •  Don’t  rely  on  obscurity    
  • 13. Hardware  RecommendaMon  #2     •  Unlocking  a  single  device  should  risk  only  that   device’s  data  
  • 14. The  Network  
  • 15. Crypto  on  small  devices   •  PracMcal  ConsideraMons  and  ImplementaMon   Experiences  in  Securing  Smart  Object  Networks   –  hQp://tools.ieL.org/html/dra_-­‐aks-­‐crypto-­‐sensors-­‐02  
  • 16. ROM  requirements  
  • 17. ECC  is  possible     (and  about  fast  enough)  
  • 18. Crypto   Borrowed  from  Chris  Swan:    hQp://www.slideshare.net/cpswan/security-­‐protocols-­‐in-­‐constrained-­‐environments/13    
  • 19. Won’t  ARM  just  solve  this  problem?  
  • 20. Cost  maQers   8  bits   $5  retail   $1  or  less  to  embed   32  bits   $25  retail   $??  to  embed  
  • 21. Another  opMon?  
  • 22. SIMON  and  SPECK   hQps://www.schneier.com/blog/archives/2013/07/simon_and_speck.html    
  • 23. Datagram  Transport  Layer  Security   (DTLS)   •  UDP  based  equivalent  to  TLS   •  hQps://tools.ieL.org/html/rfc4347  
  • 24. Key  distribuMon  
  • 25. CoAP   •  Constrained  ApplicaMon  Protocol   – hQp://tools.ieL.org/html/dra_-­‐ieL-­‐core-­‐coap-­‐18     – REST-­‐like  model  built  on  UDP   – Californium  project  coming  soon  to  Eclipse  IoT   •  No  authenMcaMon  or  authorizaMon   – Relies  on  DLTS  or  data  in  the  body      
  • 26. MQTT  
  • 27. MQTT   •  Very  lightweight  messaging  protocol   –  Designed  for  8-­‐bit  controllers,  SCADA,  etc   –  Low  power,  low  bandwidth   –  Binary  header  of  2  bytes   –  Lots  of  implementaMons   •  MosquiQo,  Paho,  RSMB  and  MoqueQe  from  Eclipse   –  Clients:   •  Arduino,  Perl,  Python,  PHP,  C,  Java,  JS/Node.js,  .Net,  etc   •  Plus  an  even  lighter-­‐weight  version  for  Zigbee   –  MQTT-­‐SN  (Sensor  Network)  
  • 28. MQTT   •  Relies  on  TLS  for  confidenMality   •  Username/Password  field  
  • 29. Passwords   •  Passwords  suck  for  humans   •  They  suck  even  more  for  devices    
  • 30. Tokens  
  • 31. Why  OAuth2?   •  Widely  implemented   •  PreQy  good     – Of  course  there  is  never  100%  agreement   – Or  certainty  with  security  protocols   •  Not  just  HTTP:   – hQp://tools.ieL.org/html/dra_-­‐ieL-­‐kiQen-­‐sasl-­‐ oauth-­‐12   – OAuth2  used  with  SSL      
  • 32. Why  FIAM  for  IoT?   •  Can  enable  a  meaningful  consent  mechanism   for  sharing  of  device  data   •  Giving  a  device  a  token  to  use  on  API  calls   beQer  than  giving  it  a  password   – Revokable   – Granular   •  May  be  relevant  for  both   – Device  to  cloud   – Cloud  to  app  
  • 33. Two  aspects  using  OAuth  with  IoT     •  On  the  device   – Tokens  are  good   – LimiMng  the  access  of  the  device   •  On  the  cloud   – Puvng  users  in  control  of  their  data   – Just  good  current  pracMce   •  Demo  with  MQTT     – But  not  just  for  MQTT   – Also  for  the  cloud,  CoAP,  and  other  protocols  too  
  • 34. Demo  components     MosquiQo   (Open  Source  MQTT   Broker)     AcMng  as  “Resource   Server”     MosquiQo_py_auth     mqQ-­‐oauth2.py   IdP     WSO2  IdenMty   Server   ESB   IntrospecMon   API   Refresher.py   Arduino   CreateToken.py   1 2 3 4 5 6
  • 35. WSO2  IdenMty  Server    
  • 36. Lessons  learnt   •  MQTT  and  MPU  /  I2C  code  is  97%  of  Duemilanove   –  Adding  the  final  logic  to  do  OAuth2  flow  pushed  it  to  99%   –  No  TLS  in  this  demo  is  a  big  issue   •  Different  Oauth2  implementaMons  behave  differently   (e.g.  changing  the  refresh  token  every  Mme  you  refresh)   •  Need  to  be  able  to  update  the  scope  of  token  if  this  will   work  for  long  term  embedded  devices   •  The  refresh  flow  should  not  really  go  via  the  Resource   server   –  Easy  fix     •  MQTT  should  have  a  well  defined  model  for  sending  a   message  to  just  one  client  (securely)  
  • 37. What  I  haven’t  covered  enough  of  
  • 38. Summary   •  Think  about  security  with  your  next  device   •  We  as  a  community  need  to  make  sure  that   the  next  generaMon  of  IoT  devices  are  secure   •  We  need  to  create  exemplars   – Shields   – Libraries   – Server  so_ware   – Standards  
  • 39. QuesMons?  

×