What you have when you started: 30 minutes and up and running
If you installed your SmartSpaces Cluster for the first time, running one or more Servers and everything happening Ad Hoc via the automatic Discovery Servers, you now have the following:
- SmartSpaces Servers communication anything to anyone – Blabbering all your secrets to anyone who is listening in the right way
- Messages sent from Clients to Servers in Clear Text Format – Including passwords and data and messages that might help hackers to break open your SmartSpaces Application and take over control
- An open space for hackers to take over control – As the SmartSpaces Framework is using all kinds of open protocols and open processes which are easy to use, easy to modify, easy to understand and easy to hijack
How you can lose control over your SmartSpace
The best and most easy way for other people to Hijack your SmartSpace and take over controls you never wanted to release in public is by:
- Injecting a Server into your Network – As a basic off the shelf SmartSpaces setup is using auto-detection for everything.
- Listening to the packages and messages sent over the Network – As all messages are Clear Text JSON objects, including all kinds of information you might want to keep secret (like passwords)
Stepping up the game
By following the following steps, you are stepping up your security one by one:
- Securing your Wireless network – Using encryption via WPA 2,
- Assigning a non-related password to your Network – So that it can not be deciphered as done with Public SmartSpaces
- Keeping private Messages private – Using specific Hidden SandBoxes
- Securing your Servers by stating Trusted Servers – Based on IP Addresses stored on the local drive of each Server, Servers will only accept other Servers form that Trusted List to share data with
- Addressing Servers directly – For Private Messages, instead of doing an auto-discovery
- Securing Sandboxes on IP level – To assure that even if a Client guesses your SandBox and SandBox password, it still will not be able to access that SandBox
- Using TLS for all Socket Connections – To encrypt all data sent between Clients and Servers
Securing your Wireless Network
- Using WPA2 – Which offers the most acceptable encryption. WEP and WPA are the predecessors and very easy to crack. As everything – including WPA2 – can be cracked and your key – in the end – is just a number, at least make it a bit harder.
- Are you building a private or public SmartSpace? – This defines greatly what key you will use to close the network for accidental users
- Public? – Anyone is allowed to access and whatever they do in your SmartSpace will be harmless / will not kill people / will not de-activate your fridge.
- Generate a public password that is related to your Network Name – SmartSpaces clients can use the name of the Network you want to connect to, to retrieve the Network Key or Network password.
- Private? – Only people you know personally are allowed to access your SmartSpace.
- Assigning a password that is completely unrelated – You might have read about public network keys for public SmartSpaces on this site. Don’t do that for your private SmartSpaces Network.
Using TLS / SSL3.1 and up
TLS – or SSL 3.1 and up, or Transparant Layer Security – is your basic shield for snooping hackers. Once a Socket Connection is established via TLS, all data sent between the Client and the Server is encrypted.
TLS (at least in the shape of Secured Socket Layers or SSL) comes standard with most programming platforms, including Java and C#.
If TLS is so relevant, why is it optional in the framework?
To run TLS you need to have a certificate. This TLS Certificate has to be generated, based on your server address or host-name.
To have a TLS certificate that is not creating all kinds of warnings, this certificate also needs to be registered by an official broker between your Clients and your Server.
To get started and running in 30 minutes, TLS is an option, switched off by default.
Using “potentially unsafe” certificates
When a SSL certificate is not signed and not registered to your Server, the Client Side SSL check will throw warnings. The communication between your Client and your Server will be encrypted anyway.
The main reasons to use unsigned certificates are these:
- Cost reduction – It costs money to register an official SSL Certificate. “Unsafe” certificates are for free.
- Speed – It takes time for the certificate to be registered.
- Versatility – Your servers might be clients operating as clients. You want hem to work first, not to get stuck on burocraticness.
Using registered certificates
Addressing Servers directly
As discussed before, the SmartSpaces Framework does autodiscovery to find Servers and SandBoxes. When you do nothing specific, your Sandbox will be assigned to the first machine available in your Network. All Servers will then be updated with the location of that SandBox. This is OK when nothing Lethal (like your killer robot) is assigned to that SandBox, but a disaster when there is.
To increase your security, you can address Servers directly.
You do this by stating at least two elements:
- The Server Location – Which can be an IP Address or the Hostname
- The name of the SandBox – Which can be anything of your choice.
Securing your Server Network by stating Trusted Servers
- Stating a list of Trusted Servers in your Server Manifest – This list is hosted as a file on each of your SmartSpaces Servers and loaded from the hard drive when the Server starts.
Using Public and Private SandBoxes
- Know on which Server they run – See the previous topic: “Addressing Servers Directly”
- Know what password you need to enter the Private SandBox
- Be in the IP list – If you increase security to that level. Meaning that only machines with a specific IP number in your Local Network can access that specific SandBox.
More about Private SandBoxes
- Used for communication between devices – For instance to open doors, read sensors, manipulate devices
- Accessed only from machines you control – Using credentials you store on those machines.
- Hidden from users – As they form the core of your SmartSpaces Application and you do not want to have them hacked, you want to hide them from your users.
Securing Sandboxes on IP level
Who would those very special machines be?
- RFID sensors on your front door – Granting access to anyone who has the right RFID card
- Database Queries – Retrieving, deleting, modifying and storing information in Databases you do not want to be corrupted
- Sensors and Devices – Monitoring the state of things and allowing things to happen – like opening doors and switching tings off and on.
Is it safe now?
If you followed the instructions in this document, your security is definitely much better. You will have:
- A secured and encrypted Wireless Network – Only available and accessable for people you know
- Encrypted data flows – within your secured Wireless Network, making it harder to intercept the contents of messages sent through your network
- A list of Trusted Servers on each SmartSpaces Server – To cut all blabbering of Servers (revealing which public SandBoxes are hosted where) to any other Server that gets injected in the Local Network of your Smart Space
- Hidden and Private SandBoxes – Which are kept secret from all other Servers and can only be found when you know which Server hosts them and what their name and password are. And – even deeper – only can be accessed by machines on an internal IP list connected to that Sandbox
- Applications addressing SmartSpaces Servers directly – Using a direct link and keeping any sensitive data from leaking to injected SmartSpaces Servers within your network, as they will only send that data to SmartSpaces Servers set up – and known by you.
Your public SandBoxes remain your weak spot
- Public Clients can send Messages that update the Database – Somehow your public clients are allowed to send Messages containing instructions that allow for data to be updated in your hidden database.
- Public Clients can send Messages that trigger the: “Open door” mechanism – Via a leak in your SandBoxes, via a Secured Machine, your user can send Messages that reach the Secured Private Sandbox and trigger the event you shielded off anyway.
SSL Research / sources
- SSL Client and Server Socket for .NET – MSDN / Microsoft – code examples for Secured Socket Client and Server
- SSL for Java – Stilius.net – Tutorial