TechDoc: Securing your SmartSpaces

Posted on May 12, 2011

0


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:

  1. SmartSpaces Servers communication anything to anyone – Blabbering all your secrets to anyone who is listening in the right way
  2. 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
  3. 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:

  1. Injecting a Server into your Network – As a basic off the shelf SmartSpaces setup is using auto-detection for everything.
  2. 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:

  1. Securing your Wireless network – Using encryption via WPA 2,
  2. Assigning a non-related password to your Network – So that it can not be deciphered as done with Public SmartSpaces
  3. Keeping private Messages private – Using specific Hidden SandBoxes
  4. 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
  5. Addressing Servers directly – For Private Messages, instead of doing an auto-discovery
  6. 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
  7. Using TLS for all Socket Connections – To encrypt all data sent between Clients and Servers
TLS (or Secured Socket Layers) is listed as last, as it is the most “complicated” to do, but should be one of your first priorities as it will encrypt all data sent over your (already encrypted) wireless network.
To understand and place TLS in one sentence: When you do online banking, your browser and the Server of your bank will build up a TLS connection, which – by default – is encrypted.

Securing your Wireless Network

Your first and utmost priority is to have an Wireless Network that is secure. You do this by:
  1. 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.
  2. Are you building a private or public SmartSpace? – This defines greatly what key you will use to close the network for accidental users
    1. 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.
      1. 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.
    2. Private? – Only people you know personally are allowed to access your SmartSpace.
      1. 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:

  1. Cost reduction – It costs money to register an official SSL Certificate. “Unsafe” certificates are for free.
  2. Speed – It takes time for the certificate to be registered.
  3. Versatility – Your servers might be clients operating as clients. You want hem to work first, not to get stuck on burocraticness.
The SmartSpaces code is default set to ignore warnings on “potentially unsafe” certificates. The main goal of the architecture is to get an encrypted connection.

Using registered certificates

When you step up the game, you will register your SSL 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:

  1. The Server Location – Which can be an IP Address or the Hostname
  2. The name of the SandBox – Which can be anything of your choice.
The link looks like this:
“<hostname | IP Address>:<your SandBox name>” or “10.0.0.123:mySandBox” or “http://www.myHost.com:mySandBox

Securing your Server Network by stating Trusted Servers

By default, any Server plugged into the SmartSpaces Local Network will receive updates on which Public SandBoxes are hosted where. This is more information that you might want to share.
To secure your Server Network, you can limit this blabber between Servers by:
  1. 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

Public Sandboxes: can be discovered by requesting any Server. As each SmartSpaces Server is aware of all Public SandBoxes on all other SmartSpaces Servers, a SmartSpaces Client can easily dicover them.
SmartSpaces Servers are the weak link in your security: If you want to shield specific messages from your Clients, because they perform operations that can be harmful when intercepted and mimicked, you need extra protection. That protection exists in the shape of Private SandBoxes
Private SandBoxes: Are SandBoxes hidden from all other Servers. Their existence is not broadcasted. To connect to Private SandBoxes you need to:
  1. Know on which Server they run – See the previous topic: “Addressing Servers Directly”
  2. Know what password you need to enter the Private SandBox
  3. 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

As stated, Private SandBoxes can only be found and accessed when you know their location (Server) and the password to enter the SandBox.
Private SandBoxes are SandBoxes:
  1. Used for communication between devices – For instance to open doors, read sensors, manipulate devices
  2. Accessed only from machines you control – Using credentials you store on those machines.
  3. 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

When you configure a Private SandBox on your Server, you can also state the IP Addresses of the machines you want to grant access to the SandBox. This is when you really have to be very paranoid about who can and can not access your specific SandBoxes. For instance, when that SandBox runs all messages for your Nuclear Missiles, including the ones with which you can launch them. Or closer to home: to open your front door to anyone who can access that SandBox.

Who would those very special machines be?

When you secure on IP level, machines and interactions you allow in your Private SandBox might be running:
  1. RFID sensors on your front door – Granting access to anyone who has the right RFID card
  2. Database Queries – Retrieving, deleting, modifying and storing information in Databases you do not want to be corrupted
  3. 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:

  1. A secured and encrypted Wireless Network – Only available and accessable for people you know
  2. Encrypted data flows – within your secured Wireless Network, making it harder to intercept the contents of messages sent through your network
  3. 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
  4. 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
  5. 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

Whatever you do to secure your SmartSpace, your public SandBoxes remain your weak spot. They can be accessed by any client on your network and expose themselves to any Server hooked into the Network. There are many ways where you accidentally can create holes in your otherwise flawless layers and shields of secured Sandboxes and Servers:
  1. 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.
  2. 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

  1. SSL Client and Server Socket for .NETMSDN / Microsoft – code examples for Secured Socket Client and Server
  2. SSL for JavaStilius.net – Tutorial
Advertisements
Posted in: Uncategorized