In the HotForestGreen “Internet of Things” and Distributed Application framework, you can choose to work with Public and Secured Sandboxes, Trusted Clients and Trusted Servers.
What is this about?
Without any form of authentication, any Client can tap into any SandBox, the moment that Client has found the name of that SandBox.
This can create a huge vulnerability of your “Internet of Things”/ Distributed Application for external attacks and Hijacking, making it open to abuse and tapping of data.
To prevent this easy access, we add an extra layer of security, based on the concept of “Trusted” and “Public” Clients.
- Public Clients – Are any set of Clients hooking in to your Application Cluster
- Trusted Clients – Are Clients you have chosen or created yourself and who know the two Secret Keywords you share within your Application Cluster
- Public SandBoxes – Are SandBoxes which can be accessed by anyone and do not check the Server Credentials
- Public Trusted SandBoxes – Are SandBoxes which can be accessed by anyone but used by a Trusted Client to assure that the Server it connects to can be Trusted
- Secured SandBoxes – Are SandBoxes which can only be accessed by Trusted Clients
SandBoxes are like walled gardens in which your data can play. Anything sent into a SandBox can not leak out. Anyone connected to that SandBox can observe the events fired within that SandBox and receive the content that is relevant.
Data from one Sandbox can not leak into another SandBox.
Observers connected to one SandBox can not see what is happening in all other SandBoxes they are NOT connected to.
This use of Sandboxes provides for a simple model where data is shielded.
Simple model of usage
Secured SandBoxes are used for the internal communication within your Application Cluster. The security handshake you are required to do to enter the Secured Sandboxes prevents an easy take-over of your Application by Hijackers.
You can create public SandBoxes for external Clients to connect to and use Trusted Clients to mediate between your Public SandBoxes and your Secured SandBoxes.
External (Public) Clients can be offered simple, harmless and public services like “turning the light on/off in a public space”.
The Trusted Clients deal with all Business logic required to keep inside your Application what needs to be kept inside, while making public access possible to those services you want to expose to the world.
Setting up a Public SandBox connection
To set up a Public SandBox connecttion, you need to do the following:
- Define the port – To which we connect to find our Sandboxes
- Connect to a Public Sandbox – With the provided method
// Define the port int port = 821; // Connect to a public sandBox called "sandBox" ApplicationSandBox.connectToPublicSandBox("sandBox", port,onconnected);
Setting up a Secured SandBox Connection
To setup a Secured SandBox connection we need to do more:
- Define the secret Keywords – we share with our Trustees in this Application Cluster
- Connect to the Secured SandBox – Using the instruction as provided and an extra keyword under which we expect to find the SandBox
// Define the keywords we use within the Cluster to contqact with whom we trust ApplicationCluster.setSecretKeywords("serverKeyword","clientKeyword"); // Define the port int port = 821; // Connect to a secured sandBox called "sandBox", shared under "mySecurityKeyword" ApplicationSandBox.connectToSecuredSandBox("securedSandBox", "mySharedSandBoxKey", port, onconnected);
Secret Keywords: How it works
Each Server you create has two secret passwords:
- A Client Side Keyword – Sent by the Client when the Client connects to the Server
- A Server Side Keyword – Sent by the Server when the Client opens the connection
These secret passwords can be used by the Client, to verify and authenticate a Server.
When you connect to a Server, the Server Manifest will contain:
- An “encrypted” Server Keyword – being a Hashcode of the Server side Keyword
- A random generated Server Token – Used to create a unique Hascode every next attempt to connect to a Server
The secret Keywords remains secret
Neither Client or Server send the Keywords themselves, as that will betray the secret. Instead, both Client and Server “encrypt” the Keyword, using data known at both sides.
- Both Client and Server send an “encrypted” Keyword – Using a random token Send by the Server
When Client or Server recieve the “encrypted” Keyword (a Hashcode), they compare that Hashcode to the Hashcode that would come out of the combination of:
- Client / Server side Keyword
- The Randomly generated Server Token
If the locally generated Hascode is the exact same as the remotely generated Hascode, this means that both Client and Server:
- Sharing the same secret keys – Being the Client and Server Keywords
- OK to Trust – Based on the probability that guessing the Keywords is hard enough to prevent security breaches
What is done to prevent easy keyword cracks?
The secret handshakes are made to be hard to crack. Nothing is impossible though. Like any static system, trying long and hard enough will enable a hacker to enter.
What is done to avoid cracking the secret Keywords?
- Rejection of connection – When a Client can not re-create the Hashcode the Server expects, the connection between the Client and Server is rejected and discarded
- A new Server Token for each new Connection Attempt – Each time a client connects, the Server will create a new and unique Server Token.
- The Accept Code for each next attempt is completely different – Based on the random Server Token, the Hascode the Client sends is always unique. So:
- Re-using a approved Hascode – Will not work
- Hammering the Server with Hascodes – Will maybe overload the Server, but as each next Hascode on each next Connection is based on a new Server Token will lead to nothing
Concluding: As long as you keep your Keywords a secret for any outside force, getting into a Trusted Group will be very hard.
Servers running on different ports
For testing purposes mainly I have created the option to connect to Servers running on different Ports, making it possible to run multiple Servers on one machine.
Inside the Scope of Trust
The Scope of Trust is as follows:
- Between Trusted Servers – When Servers communicate to each other, they share information you do not want to leak to the outside world.
- Between Trusted Servers and Trusted Clients – This can be every machine and application running within your Application Cluster.
Outside the Scope of Trust
Outside the Scope of Trust are:
- Any generic client or Server – Connecting to the Cluster without the proper credentials
Clients outside the Scope of Trust can not connect to:
- Secured SandBoxes – Created using the secret Keywords
- The Shared Sandbox between Trusted Servers – As they do not have the secret Keyword
- Secured Sandboxes – Created using the secret Keywords and the ” trusted” setting on the SandBox request
- To avoid Hijacking – Of your Application Cluster, by injection of malign and “unsigned” Servers
- To provide a simple but robust model for authentication – To make sure Servers in your Cluster only communicate by other Servers who know the secret password
- To keep it simple – To provide a simple internal Server Authentication system that is both safe and easy to use
Client side check
When the client scans for Sandboxes within a specific IP range, the following process is done:
- Is the Sandbox supposed to be Trusted? – If so: check if the Server itself can be Trusted
- If the Server can not be Trusted – Based on a false Server Keyword Hascode from the Server. Skip it. Do not attempt to connect
- Check is based on Server Manifest before connect – When we ping for Servers, we request a Server Manifest before we try and make a Socket Connection.
Server side Check
When a Client connects to a SandBox marked as “trusted” the following process is done:
- Can the client be Trusted? – When the client Initialized the Server Side Client Socket, we also send a Keyword Hashcode based on the Client Keyword.
- Hashcode does not comply – If this Hascode does not comply with what the Server expects, the Client Socket is refused and disconnected.
- Send a “rejection” message – To cater Clients who are of good intentions and help debugging, the Server will send a “You are rejected from a Trusted SandBox” message.
- Disconnect if the client tries to pass the Initialization – It is possible the Client is trying to pass the Init to use a vulnerability in the code. In that case the Client Socket will disconnect the Client.
Disconnection = rejection
- Any Client that can not Authenticate itself to a Secured SandBox is automatically disconnected –
- There are Public- and Secured Sandboxes
- There are Public- and Trusted Clients
- Public Clients can connect to Public SandBoxes – Allowing them to connect to any public service
- Public Clients can not connect to Secured SandBoxes – Preventing Public Clients from intercepting secret messages and reducing the options to Hijack your Application
- Trusted Clients can connect both to Public and Secured SandBoxes – Allowing them to get data from both Secured and Public Sandboxes
- Secured SandBoxes are registered under their name and Hashcode – Hiding them from public SandBoxes with the same name
- One Server can host multiple SandBoxes with different Hashcodes same name – As each Secured SandBox is registered under its specific Hashcode, one Server can serve multiple.
- Secured Sandboxes can only be created on Trusted Servers – To create a Secured SandBox, both Client and Server must share the same Application Keywords. If a Server does not share these keywords, the Server will be ignored for the Secured SandBox
- Servers create their own Internal Trusted SandBox – For their internal communication
- Your application can only be part of one Trusted Group – As we provide the Keywords on a global scale to an Application and to keep things simple, we only allow for one Trusted Server Group per application.