A primer for securing your IoT devices and applications written in Node.js. This presentation covers all layers of security on your device implementation.
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.
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
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
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
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.