>> µTLS - DEFINING LIGHTWEIGHT SECURITY FOR IoT (PART 2)

It is amazing how the rest of the world just disappears when I get stuck into something.

In my previous entry I covered the basic design of the µTLS communications protocol to provide privacy and data integrity between two devices - namely those with limited CPU and memory resources, such as the Arduino platform. The first phase of the project was to get a working framework in place, something that would be easy to extend if necessary.

For the server side of things; I went with PHP, namely since it is readily available and I am quite familiar with the scripting language. The exact choice of technologies really doesn't matter - the key thing is to adhere to the protocol that we defined earlier, remember it is simple insecure HTTP.

Initially; my focus was to build the server component - just to validate the concept. The design of the server can be summarized into a series of simple steps - regardless of the level of security that you wish to implement. At a high level; it can be expressed as follows:

SESSION CREATION

• identify the client, verify they are real
• create a secure session, initialize parameters
• send parameters to the client

SESSION UPDATE

• obtain the session id
• using the session id and secure protocol, decrypt the message
• process and store the message
• create response and send to the client

My initial design focused on using HEX strings for the transport of binary information within the JSON code; but I eventually went with Base64 as it is widely used within the web community, it also is not a difficult algorithm to implement on resource restricted devices.

The last thing I wanted was to have a convoluted mess of code that was difficult to add new modules when required - so I needed to find a way for php to give me some form of dynamic, function pointer system where I could load modules and execute in a generic sense.

I have been writing php code for well over a decade; but I wasn't familiar with anything that could do this until I found the system function call_user_func_array - that was perfect for the job. I knew I could couple it with a few other nifty tricks I have learnt over the years and make a flexible environment where I could add or remove modules as needed with ease.

The end result allowed me to define modules that were supported using:

include "security.none.inc";
include "security.rot13.inc";
include "security.rc4.inc";
include "security.rsa-1024.inc";

I could add more modules by doing additional include statements - calling functions as simple as:

// what security protocol has been defined for client validation
$sec = $json->security->protocol;
if (array_key_exists($sec, $func_index))
{
  // the security protocol uses a token and hash
  $buf = base64_decode($json->security->ihash);
  $out = base64_decode($json->security->ohash);

  // call the appropriate hash validation function
  if (call_user_func_array($func_hash[$sec],
                           array($ses, $buf, $out)))
  {
    $code = constants::ERR_UNAUTHORIZED;
    goto request_done;
  }

  // we are done with the variables now
  unset($tok);
  unset($hash);
}
else
  goto bad_request;

In the next entry; I will show how to define one of the modules and integrate them into the server - and run a few simulated client sessions to check if in fact, the server design and implementation does what it should. The answer of course is yes, but it is too much to explain in a single entry.

I am debating if this is worth commercializing this solution or not.

So far the results I am obtaining are very promising and this may be a great solution to push as a standard for securing devices with limited resources. It would make sense to ensure the code base is stable and extensible before making any promises on the future of the project. If you are interested; definitely reach out to me for further details and opportunities to collaborate.