IoT Lockdown: Secure Your Device with Layered Security
•Download as PPTX, PDF•
1 like•452 views
A primer for securing your IoT devices and applications written in Node.js. This presentation covers all layers of security on your device implementation.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to IoT Lockdown: Secure Your Device with Layered Security
Similar to IoT Lockdown: Secure Your Device with Layered Security (20)
More from Adam Englander
More from Adam Englander (20)
Recently uploaded
Recently uploaded (20)
IoT Lockdown: Secure Your Device with Layered Security
- 2. IoT Lockdown Adam Englander, LaunchKey
- 3. Who Am I? • Director of Engineering for LaunchKey • Developer Community Activist • IoT Enthusiast • National Junior Basketball Coach
- 4. What Do I Do? • Security Consulting • SDK Development • API Development • Protocol Server Development • IoT Research
- 5. Know This • You will be attacked • You will be exposed to a Zero Day vulnerability Paris Tuileries Garden Facepalm statue by Alex E. Proimos - http://www.flickr.com/photos/proimos/4199675334/. Licensed under CC BY 2.0 via Commons.
- 6. Security is like an Ogre… …it has layers ©The Frollo Show – licensed under Creative Commons
- 7. Layered Security • Prevents single point of vulnerability • Increases the cost of penetration by an attacker “Swiss cheese model of accident causation” by Davidmack – Own work - Licensed under CC BY-SA 3.0 via Commons
- 10. Operating System Security • Randomize user passwords • Disable unused ports • Encrypt the file system “JolietPrisonGate” by Jacobsteinafm – Own work – Licensed under Public Domain via Commons
- 12. File System Security • Named application user • Remove “everyone” access where possible • Restrict app user to files necessary to run • Avoid write access – use pipes © Chris Smart license under Creative Commons BY-NC-ND
- 14. Isolation • Use web services for communication • Remove all non-essential services (SSH, FTP, etc) • Use authentication on remaining services • Be as secure as possible with service data “Joshuatree" by Joho345 - @U2 (www.atu2.com) - Joho345. Licensed under CC BY 2.5 via Wikimedia Commons.
- 16. Network Security • Devise a system with only outbound IP traffic • Restrict inbound and outbound IP traffic • Only allow paired Bluetooth devices to connect • Pair Bluetooth devices with challenge-response "FEMA - 40322 - Road Closed sign" by Patsy Lynch - This image is from the FEMA Photo Library.. Licensed under Public Domain via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:FEMA_-_40322_- _Road_Closed_sign.jpg#/media/File:FEMA_-_40322_-_Road_Closed_sign.jpg
- 18. Sensitive Data Exposure Escalation of Privilege Account Hijacking Denial of Service Remote Code Execution What You Are Preventing
- 19. Sensitive Data Exposure • Protect data in transit by: • utilizing TLS • not following redirects • pinning SSL certificates • using DNSSEC to verify DNS • encrypting data • Protect data at rest with encryption "Marilyn Monroe photo pose Seven Year Itch" by Published by Corpus Christi Caller-Times photo from Associated Press - Corpus Christi Caller-Times page 20 via Newspapers.com. Licensed under Public Domain via Commons - https://commons.wikimedia.org/wiki/File:Marilyn_Monroe_photo _pose_Seven_Year_Itch.jpg
- 20. SSL Pinning • Certificate verification via fingerprint res.socket.getPeerCertificate().fingerprint • Have backup fingerprints to quickly rotate when primary is compromised. • Additional certificates must use different private keys to have a different signature.
- 21. Encrypting Data • Data at rest can use symmetric encryption as secret is not shared but local. • Data in transit should use asymmetric encryption. It’s more complex and slower but does not require transmitting your secret. • Both are available natively via the “crypto” package. "Lorenz-SZ42-2". Licensed under Public Domain via Commons - https://commons.wikimedia.org/wiki/File:Lorenz-SZ42- 2.jpg#/media/File:Lorenz-SZ42-2.jpg
- 22. Symmetric Encryption • Uses shared “secret” key. • Uses initialization vector (IV). • Use crypto.randomBytes() for cryptographically random IV. • Always use some sort of block chaining or cipher feedback to ensure pseudo-randomness. • aes-256-cbc is a good standard "Tux ecb" by en:User:Lunkwill - http://en.wikipedia.org/wiki/Image:Tux_ecb.jpg. Licensed under Attribution via Commons - https://commons.wikimedia.org/wiki/File:Tux_ecb.jpg#/media/File:Tux_e cb.jpg
- 23. Asymmetric Encryption • Uses public/private key pairs. • Private and public key can encrypt and verify signature. • Only private key can decrypt and create a signature. • Private key should be password protected. • Key size at least 2048 bytes but 4096 bytes is preferred.
- 24. Account Hijacking • Never use plain text credentials • Use strong hashing: • PBKDF2 is in crypto package • 32+ character random SALT • 10,000+ iterations • sha256 digest • If you use email for username, hash the value for storage • Alert for changes to accounts "Hi-jacking Hot Spot!" by Herby Hönigsperger - https://www.flickr.com/photos/hmvh/58185411. Licensed under Attribution via Commons - https://creativecommons.org/licenses/by-nc-sa/2.0/
- 25. Encryption vs. Hashing • Hashing is one way • Encryption is reversible • Hashing is more secure than encryption • If you do not need to decrypt sensitive data, consider hashing it "Hi-jacking Hot Spot!" by Herby Hönigsperger - https://www.flickr.com/photos/hmvh/58185411. Licensed under Attribution via Commons - https://creativecommons.org/licenses/by-nc-sa/2.0/
- 26. Escalation of Privilege • Always use TLS • Set "secure" and "HttpOnly" flags for session cookies • Use a CSRF token (nonce) • Strict-Transport-Security • Expire your requests • Sign API requests including credential data and location "Holborn Tube Station Escalator" by renaissancechambara - http://www.flickr.com/photos/renaissancechambara/2267250649/. Licensed under CC BY 2.0 via Commons - https://commons.wikimedia.org/wiki/File:Holborn_Tube_Station_Escalator .jpg#/media/File:Holborn_Tube_Station_Escalator.jpg
- 27. Nonces • Used only once • Must be cryptographically random • Provided by crypto package with randomBytes() • Should expire "Cutting head of a paper shredder" by wdwd - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:Cutting_head_of_a_paper_shredder.jpg#/media/File:Cu tting_head_of_a_paper_shredder.jpg
- 28. Digital Signatures • Verifiable hash of supplied data • HMAC or RSA is provided by crypto • RSA is preferred • JOSE is IETF standard "Wacom STU-300 LCD Signature Tablet - Mar 2013 04" by WestportWiki - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:Wacom_STU-300_LCD_Signature_Tablet_- _Mar_2013_04.jpg#/media/File:Wacom_STU-300_LCD_Signature_Tablet_-_Mar_2013_04.jpg
- 29. Denial of Service • Detection • Honey Pot • Request frequency • Request signatures • Mitigation • Black list IPs • Black hole (no response) • Detect early in process "Motorcycles in Taipei" by Koika - Own work. Licensed under CC BY- SA 1.0 via Commons - https://commons.wikimedia.org/wiki/File:Motorcycles_in_Taipei.JP G#/media/File:Motorcycles_in_Taipei.JPG
- 30. Remote Code Execution • Content Security Policy • Restrict to local source • No inline CSS/JS • No eval(), ever! • Prepared statements in SQL • Code Object with Scope in MongoDB
- 31. Further Reading • https://en.wikipedia.org/wiki/Layered_security • https://en.wikipedia.org/wiki/Defense_in_depth_(comput ing) • https://www.owasp.org/index.php/OWASP_Internet_of_ Things_Project • https://en.wikipedia.org/wiki/JSON_Web_Token
Editor's Notes
- If you are fortunate enough to be successful, with your device and people use it, you will be attacked. It’s not if. It’s when. A zero day vulnerability is a security vulnerability that is not disclosed before it is exploited. Ethical or “white hat” hackers will give the software or hardware vendor a reasonable window with which to resolve a vulnerability before it is exposed to the public. Unethical or “black hat” hackers will either sell or utilize the vulnerability without any warning to the vendor. The only way to be sure that you are breached is to believe that you cannot be
- In order for layered security to succeed, you must create each layer assuming that the others have failed. Assume that each measure you put in place is the only remaining measure you have to reduce harm from a breach. You may use three different layers of encryption for the same data. This may seem like overkill but its how you keep your data safe.
- Have a user name unique to your application to be able to fine tune file access Even with a named user, if your files are “everyone”
- Restrict network access as much as possible The safest system accepts no inbound connections from the IP network. Look into other ways to configure network configuration and have you device connect to a service you devise on the Internet utilizing Web Sockets for communicating with the user. Restrict inbound IP traffic to not allow access to any services utilized by your application. Restrict outbound IP traffic to prevent your device from becoming a relay or slave node for an attack Paired Bluetooth devices have performed a key exchange to verify their identity. They also use those keys to encrypt communication data Use visual or audio announcing of the challenge. Pairing with a challenge-response reduces the risk of an attacker being able hijack your device during the pairing process
- TLS is the ground level basis for secure communication over the Internet. Make sure you use valid and verifiable certificates. Ignoring certificate errors is the best way to fall victim to a Man in the Middle attack. The primary way a successful Man in the Middle attack is carried out is by providing an invalid DNS response that redirects to another domain with a valid certificate. This can be easily avoided by not following redirects from remote service requests and pinning SSL certificates so that only known certificates are accepted. For more elaborate protection, you can also verify DNS with DNSSEC. I have not been able to find a DNSSEC implementation for Node.js. Data encryption is the last piece to protecting data in transit. If you are compromised by a man in the middle attack, having your data encrypted provides security for each piece of data. Data at rest should be encrypted as well. That goes for data in the file system, cache services, and databases.
- SSL pinning is probably the simplest way to prevent man in the middle attacks. Have multiple SSL certificates available for you API endpoints dealing in sensitive data. Have at least one backup certificate to be able to rotate. Two backups to allow for recovery time with an existing backup certificate. Always remember to request certificates with new primary keys to ensure finger prints are different.
- Encryption can be confusing. Don’t make the mistake of ignoring or doing it poorly. We’ll talk about it in a little more depth in the next slides.
- The size of the key and IV go a long way to adding pseufo-randomness and ,
- Hashing requires knowledge of the original data. Decryption only requires knowledge of the secrets and not the data. As such, if you determine the encryption keys used to encrypt one piece of data, you can use that decrypt the rest of the data. Cracking on hash does not give you any insight into any other hash. Hashing sensitive account data like email and user name can prevent account hijacking. Not having a unique way to link a user or an employer to an account will prevent from being able to utilizing spearfishing or whaling in their attack.