KinomaJS on Microcontroller

KinomaJS on Micro-controller
Introduction
Running JavaScript on micro controllers is challenging mainly because of the memory restric-
tion. Those who have written an interpreter can easily imagine how much heap memory will be
necessary and how big the interpreter can be. For micro controllers, we cannot assume that the
operating system supports virtual memory or even a dynamic loading mechanism. In fact, the
memory management system coming with RTOS is nothing but a simple malloc function. The
system, drivers, middleware and all applications share only one heap space. It is easy to imag-
ine that the memory fragmentation will be a big concern — if someone allocates a long-lived
memory block somewhere (even if it is tiny), the heap memory can be easily fragmented and
quickly becoming useless. Not only the heap memory but the footprint size is also a concern --
all objects, including the operating system, network stack, SDKs, and applications, need to be
linked into into one executable on operating systems like RTOS. Overlay can be possible but
this is for switching the personality of applications. It is not useful for implementing something
like a JavaScript engine which has to be kept in memory all the time.
Besides the resource limitation, we cannot assume that micro controllers have user interface
devices like a display and keyboard, let alone a fancy touch screen, either. This makes it difficult
even to configure the device to join a WiFi network. Many network routers, for example, run a
HTTP server so that users can configure the device using a Web browser. IoT devices can do
the same but what we can do with a Web browser is very limited. For example, just in order to
update software on a device (sometimes it is called firmware update), users need to download a
software update from a server themselves and upload it to the device by hand. Our mobile app
solution make it easy and secure, which is powered also by KinomaJS.
Our KinomaJS powered IoT devices are designed to work out of the box — no cross compilers
or a SDK is necessary. All you need is Kinoma Studio. You write the code for both micro con-
trollers and mobile apps in JavaScript on the same tool. Once you finish debugging the code,
your device code can be installed directly to the device using Kinoma Studio or saved in the
mobile app as a resource so that it is uploaded to the device when users launch the mobile app.
This way, the firmware update can be done with the software update of the mobile app. The lat-
est Javascript byte code is installed into the mobile app and delivered to the users’ mobile de-
vices. When the mobile app is launched, the latest firmware will be sent out to the device.
IoT security is becoming a big issue. As above, IoT devices tend to lack fundamental security
features, like memory protection, access control, secure vault and cryptographic functions which
tend to take up a lot of memory. Without those functions supported by the system, even a sim-
ple sandboxing will be difficult to be implemented. Using JavaScript has an advantage on this
front. Unlike C, JavaScript cannot access random memory and only APIs that are safe to use
are opened for user applications. As long as carefully avoiding the use of global variables, your
instance variables cannot be accessed or altered by other applications. As for the network secu-
rity, supporting even SSL is not easy for the IoT device because of the limited resource. We will
see how we have overcome this issue in detail taking SSL for example.
1

On-demand JavaScript Loader
In this section, we will look at how the dynamic loading system works with JavaScript. The “re-
quire” directive was introduced and have been used to include non-standard libraries. We ex-
tended this function to load not only JavaScript code but native code bound to the JavaScript
code as well. KinomaJS supports a mechanism to extend JavaScript functions with native code.
This is useful for writing CPU intensive processes, like cryptographic functions and handling bi-
nary data. In fact, our cryptographic library, big number processor, and some device drivers like
I2C and GPIO are implemented in C and exposed as a JavaScript object and functions. Those
modules are loaded with “require” only when it is necessary. This way, the main executable
does not have to include those additional functions. Its footprint can be much smaller and the
saved memory can be used for loading a module and reused for another module. Basically the
standard JavaScript objects, like RegExp, Math, Date, etc. are implemented in the same way so
we put some standard objects to extensions as well to keep the footprint small. Those loaded
extensions will be unloaded automatically when the object is garbage-collected by the Java-
Script engine. The garbage collector is kicked in only when memory is scarce, therefore loaded
modules will stay there as long as memory is available and will not be re-loaded even when it is
“required” again. It is safe to say this memory-speed trade-off is fair. The effort to make code
smaller will be paid off.
Let’s see how this mechanism save the memory usage in detail, taking a simple HTTPS opera-
tion for example. The following graph represents the memory usage during the SSL operations
with HTTP. When a client and a server establish a TCP connection, SSL starts the handshake
process to authenticate and exchange a session key. If everything goes well, it sits between the
upper level protocol i.e., HTTP and the socket layer. All data sent through the SSL layer will be
encrypted.
On the graph, when an application starts HTTPS, only necessary modules are loaded, and as
the process goes through, other modules like cryptographic functions, will be loaded on-de-
mand.
2

SSL starts the handshake process with exchanging the “hello” message between the server and
client. During these protocols, both parties negotiate the cipher suite which designate a public
key algorithm, symmetric algorithm, and hash algorithm. Note that at this point, none of those
algorithms is loaded as the graph shows. Cryptographic functions will be loaded only when it is
needed in the later process. When the negotiation is done and the server has sent out its certiﬁ-
cate, the client generates a temporary key and sends it encrypting with the server’s public key.
This process involves hashing with MD5 and SHA1 to generate the master secret, and encrypt-
ing the temporary key with a public key algorithm. As the graph shows, this process takes up the
memory most as many Cryptographic modules are loaded, which includes the public key algo-
rithm that can be big. Once this process is done, the public key algorithm is no longer needed.
In fact, in the next protocol, which is called “change cipher” that is the trigger to start encrypting
data, all those algorithms are unloaded and the memory is freed, as the symmetric key algo-
rithm and the digest algorithm are swapped in. Finally, both parties share a session key, and
prepare for encrypting / decrypting data. Those symmetric and hash algorithms will stay until the
session is closed.
Here is a code snippet of the actual SSL implementation in JavaScript.
3
0
35
70
105
140
hello
cert
hello
done
change
cipher
ﬁnished
data
heap xs

switch
(cipher.cipherAlgorithm)
{

case
FskSSL.cipherSuite.DES:

var
enc
=
new
Crypt.DES(o.key);

break;

case
FskSSL.cipherSuite.TDES:

var
enc
=
new
Crypt.TDES(o.key);

break;

case
FskSSL.cipherSuite.AES:

var
enc
=
new
Crypt.AES(o.key);

break;

case
FskSSL.cipherSuite.RC4:

var
enc
=
new
Crypt.RC4(o.key);

break;

…

The code is selecting a symmetric algorithm in the “change cipher” process. The Crypt object
looks like this:
<object
name="Crypt">

<function
name="get
AES">

return
require("Crypt_AES");

</function>

<function
name="get
TDES">

return
require("Crypt_TDES");

</function>

…

</object>

This way, only the selected algorithm is loaded into the memory while you can support as many
algorithms as you want without a concern of the memory limitation.
Mobile App
As having looked at how JavaScript code is loaded, it is easy to write a loadable code in Kino-
maJS. It is natural to incorporate such code into a mobile app. Mobile devices have rich user
interface. The loadable code can be seen as a part of the whole application. Only difference is
the interface between the UI part and the device code — it may sound a little like RPC. In this
case, the micro controller will be a server. The protocol is arbitrary, depending on the applica-
tion. KinomaJS on micro controller supports HTTP and WebSocket at the moment. As for the
discovery service, SSDP and mDNS are supported.
A typical application using micro controller is control and monitor censors. A standalone device
will have a set of APIs to interface with the censor. In our mobile solution, we will run the UI on
the mobile platform and the censor processing on the micro controller.
4
UI
sensor IO
UI
sensor IO
networkfunction call

Here is a code snippet of the UI part. The sensor data retrieved via an API or sent from the con-
troller via WebSocket is stored in an instance variable for later use. onTimeChanged is called
periodically to update the screen.
<behavior><![CDATA[

function
onTimeChanged(canvas)
{

//
draw
objects
at
this.axes
on
canvas

}

function
onAxesChanged(canvas,
axes)
{

this.axes
=
axes;

}

]]></behavior>

The following code is a part of the standalone version of the mobile app. This will poll the axis
data from a censor periodically and distributes the data to the above callback.
<handler
path="/gotAxes">

<behavior><![CDATA[

<method
id="onInvoke"
params="content,
message"><![CDATA[

var
data
=
message.requestObject;

if(
data
!=
null
)

application.distribute(
"onAxesChanged",
data
);

</method>

]]></behavior>

application.invoke(
new
MessageWithObject("pins:configure",
{

adxl345:
{

require:
"ADXL345",

pins:
{

adxl:
{
sda:
27,
clock:
29
}

}

}

}));

application.invoke(
new
MessageWithObject(

"pins:/adxl345/read?repeat=on&callback=/gotAxes&interval="
+
params.polling

));

This code is a part of the distributed version of the mobile app. It is corresponding to the above
code — when a WebSocket connection is established, it starts the polling on the controller. The
controller will sends back data periodically and the receiver distributes the data one by one to
the UI part.
<behavior><![CDATA[

function
connect(hostname)
{

this.ws
=
new
WebSocket("ws:"+
hostname);

this.ws.onconnect
=
function()
{

this.send(
“polling”
);

};

this.ws.onmessage
=
function(ev)
{

var
result
=
JSON.parse(ev.data);

application.distribute(
"onAxesChanged",
result);

};

}

]]></behavior>

5

Security
Sandboxing is easy with Javascript and beyond that, dynamic loading and collaboration with
mobile app make the whole system more secure. Taking SSL for example again, there are more
than 30 options for algorithms and if all of them are implemented in the ordinary way, the code
of those algorithms will take up so much memory. A research reports that “70 percent [of IoT1
devices] did not encrypt communications to the Internet and local network.” The report does not
point out the reason clearly but it must be related to the lack of resources of the IoT device. With
KinoamaJS, all cryptographic algorithms can be implemented as loadable and only when it be-
comes necessary it is loaded on the memory. This way, necessary security measures can be
practically executed while applications are given enough memory.
Needless to say, security update is inevitable. A security researcher, Bruce Schneier warns2
about the (in)ability of software update on micro controllers. The mobile app solution makes it
easy and can keep the device code updated. When a user launch the mobile app, if it has an
update it will be automatically sent out to the device and the renewed module will be used right
away.
Another example is "personalization" of the device. Personalization is a process to make your
device different than others. More speciﬁcally, the process usually involves installing a unique ID
and individual keys. This is necessary in a case like the device connects a cloud service. The
cloud service needs to know who is connecting to the service and make sure it is an authorized
party. To do that, usually the client needs to keep its own private key or an unique password.
But, it is not practical to burn those keys or password into a storage or NVRAM at the manufac-
turing time as we do not know what kind of service users want to use with the device. Extra cost
to personalize cannot be ignored either. Our mobile solution can make it easy as well, like the
following scenario that is to install a key pair to the device:
1. Log in to a service with a user ID / password on a mobile phone,
2. Once the service authorizes the user, it sends back a key pair for the device owned by the
user,
3. Then the mobile device passes the key to the IoT device. Now the device can connect the
cloud service using the key standalone and can send / receive data securely.
Theoretically it is possible to do a similar process using web but letting users handle a sensitive
data like keys can lead the whole system to a failure. Once again, the mobile code and device
code can be written together on Kinoma Studio. Not only when a new software is being devel-
oped but when it is updated, it is easy to make sure the server and client process the same pro-
tocol. The following example shows how the key can be installed from the mobile to the device
using HTTP. A code snippet of a HTTP service on the device will look like:
var
HTTPServer
=
require(“HTTPServer”);

this.httpServer
=
new
HTTPServer(port);

this.httpServer.onRequest
=
function(http)
{

var
o
=
http.decomposeUrl(http.url);

if
(o.path.length
<
1)

return;

switch
(o.path[0])
{

http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA5-4759ENW&cc=us&lc=en1
https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html2
6

case
"install":

env.set(“key”,
http.content);
//
save
the
key
on
the
secure
storage
for

later
use

break;

…

}

On the client side, i.e., on the mobile device, KPR supports the device discovery service by de-
fault, and once the device is discovered, it can simply send the key data via HTTP:
var
message
=
new
Message(“https://“
+
hostname
+
“/install”);

message.requestChunk
=
Files.readChunk(“keyFile”);

message.method
=
"POST";

application.invoke(message,
Message.TEXT);

You can extend the protocol this way yourself. It has to be consistent between the server and
client, but it will be easy to do with KinomaJS on Kinoma Studio.
7

KinomaJS on Microcontroller

More Related Content

Viewers also liked (12)

Similar to KinomaJS on Microcontroller (20)

KinomaJS on Microcontroller