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.
Adam Englander, LaunchKey
Who Am I?
• Director of
• IoT Enthusiast
• National Junior
What Do I Do?
• SDK Development
• API Development
• Protocol Server
• IoT Research
• You will be
• You will be
exposed to a Zero
Paris Tuileries Garden Facepalm statue by Alex E. Proimos -
http://www.flickr.com/photos/proimos/4199675334/. Licensed under CC BY 2.0 via Commons.
• Prevents single
• Increases the cost
of penetration by
“Swiss cheese model of accident causation” by Davidmack – Own work - Licensed under CC BY-SA 3.0 via Commons
Operating System Layer
• Randomize user
• Disable unused
• Encrypt the file
“JolietPrisonGate” by Jacobsteinafm – Own work – Licensed under Public Domain via Commons
File System Layer
• Use web services for
• Remove all non-essential
services (SSH, FTP, etc)
• Use authentication on
• Be as secure as possible
with service data
“Joshuatree" by Joho345 - @U2 (www.atu2.com) - Joho345. Licensed under CC BY 2.5 via
• 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
"FEMA - 40322 - Road Closed sign" by Patsy Lynch - This image is from the FEMA Photo
Library.. Licensed under Public Domain via Wikimedia Commons -
What You Are
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
"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 -
• Certificate verification via fingerprint
• Have backup fingerprints to quickly
rotate when primary is compromised.
• Additional certificates must use
different private keys to have a
• Data at rest can use symmetric
encryption as secret is not shared
• 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
"Lorenz-SZ42-2". Licensed under Public Domain via Commons -
• 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
• 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 -
• Uses public/private key pairs.
• Private and public key can encrypt and
• Only private key can decrypt and
create a signature.
• Private key should be password
• Key size at least 2048 bytes but 4096
bytes is preferred.
• 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 -
Encryption vs. Hashing
• Hashing is one way
• Encryption is reversible
• Hashing is more secure
• 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/
Escalation of Privilege
• Always use TLS
• Set "secure" and "HttpOnly" flags
for session cookies
• Use a CSRF token (nonce)
• Expire your requests
• Sign API requests including
credential data and location
"Holborn Tube Station Escalator" by renaissancechambara -
Licensed under CC BY 2.0 via Commons -
• Used only once
• Must be
• Provided by crypto
• Should expire
"Cutting head of a paper shredder" by wdwd - Own work. Licensed under CC BY-SA 3.0 via
Wikimedia Commons -
• Verifiable hash of
• HMAC or RSA is
provided by crypto
• RSA is preferred
• JOSE is IETF
"Wacom STU-300 LCD Signature Tablet - Mar 2013 04" by WestportWiki - Own work. Licensed
under CC BY-SA 3.0 via Wikimedia Commons -
Denial of Service
• Honey Pot
• Request frequency
• Request signatures
• 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 -
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