Introduction

TinyONE is the implementation of a project which is based on several building blocks. The result is a DHCP and SNTP server which can be used for testing other projects. For example, in an enterprise environment it is difficult to quickly change the DHCP or SNTP server if these functions are to be tested in your own project. For this reason the project TinyONE was created.

As in my other Tiny projects, Tiny does not mean small here, only the functionality that was currently needed was implemented. And ONE stands for the first project I have created here, which connects all the building blocks together in a meaningful way.

TinyONE is secured by user / password login. There is no default password and you have to assign a password the first time you use it. The password requires at least one uppercase letter, one lowercase letter, one number and symbols. And the total length must be between 8-32. Only a salted hash is stored from this password. This is only the password for the administration (admin).

The project is no longer in a Proof of Concept status, but it is not yet fully developed also. As already mentioned, this is the first version, and there are still some areas of work to be done.

Btw, for the hardware a BeagleBone Black with TinyCTS instead of Linux was used.

Building Blocks

The software use the following components:

• TinyCTS/AL a Cooperative Task Scheduler
• FatFs a generic FAT Filesystem Module
• lwIP a Lightweight TCP/IP stack
• MicroHTTP a web server library
• Mbed TLS a SSL library
• zlib a compression library
• xfile a file system image generator
• xbin a bin file converter

SEGGER Embedded Studio v7.32a was used as the compiler.

By using many different components from different sources, it was not always easy to bring everything together. Therefore it might be more helpful if everything comes from one source,
and with professional support available. For this reason, you should perhaps take a look at the Segger’s products.

Bootloader

This bootloader here is a very simple version which copies a file "firmware.bin" from the SD card to the SDRAM and starts it. For integrity, the firmware header and the CRC are checked first. With the help of xbin, the "firmware.bin" file was prepared before and the header and CRC was added.

HTTPS protocol

With HTTPS the communication is encrypted by using the Trasnport Layer Security (TLS). The TLS functionality was implemented with the help of Mbed TLS.

In addition there is now the directory "certs" on the SD card. The following files must be copied into this directory later:

• intermed.crt (chain.crt is used instead)
• device.crt (chain.crt is used instead)
• device.key
• chain.crt

Without these files, only HTTP is supported. The information how the files can be created are available here.

Note: This is not a secure system with regard to "CyberSecurity" because the "device.key" is freely accessible here. The example is only intended to demonstrate the function of TLS.

Tiny Network Explorer (TNE)

Tiny Network Explorer (TNE) is based on the earlier version of NUTSetup. TNE sends a UDP broadcast to a specific port. TinyONE listens on this specific port and responds with its configuration settings. Some additional information like system name and version is also sent. With TNE the user can change the settings and sends them back to TinyONE. Here the new settings are saved and the device restarts. This procedure also works if an incorrect IP address or netmask was set. TNE finds only devices in the same subnet.

After starting the Tiny Network Explorer, all available TinyONE Server will be detected automatically. Assuming there are 3 TinyONE Server in the connected subnet of the PC and the Tiny Network Explorer will be started, the window will look like:

Remember, this will work even if the devices are configured with the wrong address and/or netmask, or with duplicated addresses. A double click on the MAC-Address will open the configuration window:

Here the options like DHCP, IP-Address, Netmask, Gateway and Location can be configured. But this can also be a security risk. Therefore this functionality can also be deactivated:

The remote setup option can be deactivated in the nework configuration dialog:

Here the option "Enable TNE Setup" was not activated

First time use

As already mentioned, a password must be set when using it for the first time:

After the initial setup, the login is required, with admin for the user:

After the login the windows looks like:

Oh, by the way, if you don't use the TinyONE's website for 10 minutes, you will be logged out automatically.

mDNS / LLMNR

Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server (Source: RFC6762).

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible (Source: RFC4795).

With the mDNS / LLMNR service it allows hosts to perform name resolution for hosts on the same local link. It is possible to address the host with e.g. "tiny.local".

This means in our case that by typing "tiny.local" in the browser you will forwarded to the website of a TinyONE Server if it is configured correctly in the network. The mDNS/LLMNR feature is also used in the Tiny Network Explorer when double clicking on an IP address.

Now the login is required, with admin for the user. After the correct login the result will look like:

This is the jump table into the TinyONE Network. The mDNS/LLMNR feature is also used when clicking on an IP address.

But this device must be unlocked with a correct login.

Here a click on the IP address 192.168.1.200 was executed. Take a look back at the Tiny Network Explorer. Here the device with the IP address 192.168.1.200 has the MAC address of XX:XX:XX:5B:08:31. Now take a look at the URL. Here you will find "tiny5B0831.local".

This means that you can reach a TinyONE Server with different ways:

• "tiny.local" for the URL
• "tiny.local" for the URL and than the link in the overview
• Double click on the IP address in the Tiny Network Explorer
• Direct with last 3 bytes of the MAC address, e.g. "tiny5B0831.local" for the URL
• Direct with the IP address for the URL

Terminal

At start the application will output some information over the UART (115200, 8, N, 1):

One of the most useful features is the task info:

But it is possible to check the runtime stack:

And the functionality to check the memory:

Another useful feature is the network info:

Here, DHCP was disabled, and the default IP address of 192.168.1.200 is used.

Statistic

The same functionality as before are also available under "Maintenance / Statistics". The values are updated every 5 seconds. For example, the Task Info looks like this:

Infos for Runtime Stack and Memory are available too.

DHCP Server

The DHCP Server can be configured and enabled by "Maintenance / DHCP Server":

The DHCP Server overview with a connected DHCP client looks like:

Btw, the DHCP Server can not be enabled if the TinyONE Server has enabled his own DHCP client.

SNTP Server

The SNTP Server can be controlled by "Maintenance / Time":

The SNTP Server overview looks like:

Update

The update functionality is available under "Maintenance / Update". Here it is possible to update the webpage and firmware. The firmware update looks like:

There is the possibility to choose one of two buffers for the update. One of the two can be activated later. The same functionality as here for the firmware is also available for the webpage.

zlib uncompress

In the moment only a compressed webpage image will be supported. With the help of zlib, the size of the TinyONE website could be reduced by compression from 142 to 25 KB. The compression is done by xfile. In the application only uncompress is required. The DEFLATE algorithm required the following resources here:

• ROM: 11 KByte
• RAM: 3 KByte
• Heap: 7 KByte

For a microcontroller with few resources, this may not be the best algorithm, but it is perfect for this application.

How to build

If the project was opened in SEGGER Embedded Studio, there are different project configurations to create the firmware. The configuration "RAM Release" must be used for later use with the bootloader.

After a successful build, the firmware must still be converted with the batch file "_create_fw.bat". This batch file can be find in the project folder:

The result of the conversion is stored in the "build" directory. The file "tinyone_fw_v110.bin" can be used to update the firmware via the website, as described above.

Password reset

Of course, there is also a way to reset the password if you have forgotten it. This is a multi-step process which can be started with "Password reset":

Next the username is needed for the account where the password should to be reset:

Press "Password reset" to continue. Next, a "Password reset request code" is displayed which is needed to calculate the actual "Reset Code". In addition the new password must also entered here:

The actual reset code is calculated using an appropriate algorithm from the reset request code. The required request and reset code is different for each device and cannot be used again.

In the current implementation, a simple algorithm is used for demonstration only. Here the request code must be used in reverse order to create the reset code.

Note: An own algorithm should definitely be used in a production system.

After pressing "Password reset", and with the correct reset code, you can login with the new password:

Change Password

Of course there is also a way to reset the password if you know the actual password. You will find this option under "Maintenance > Security > Change Password":

As usual, the current password and the new password are used here.

Manage TOTP (2FA)

Time-based one-time password (TOTP) is a method of adding additional security to your account. Here an additional factor (2FA) will be used to make the account more secure. More secure than using only one password as the only factor.

Because TOTP is time based, it is important that the device is in sync with the UTC time. TOTP makes only sense here if the time on the device is synchronized e.g. by NTP. You will find this option under "Maintenance > Security > Manage TOTP":

After successful activation, the login is additionally secured by the second factor.

Login step 1:

Login step 2:

The "Authentication code" is also required for the secondary factor.

Update Certificates

"Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate) which must be signed using the applicant's private key. The CSR also contains the public key chosen by the applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information." (Source: Wikipedia)

This way here is a manual process that can only be performed with the help of the network administrator. The certificate signing request (CSR) will be created by the device and must be entered on the website of TinyELCA, and the chained certificates will be created. The chained certificates that has now been created must then be installed on the device.

Of course, you can also use your own Certificate Authority (CA), TinyELCA is just one option here. As a result, a chained certificate must be created, with the Device certificate first and the Intermediate certificate second.

You will find this option under "Maintenance > Security > Update Certificates":

Press "Next" to start the process:

With the CSR, the Certificate Authority can now generate the chained certificate. In the next step, the new created chained certificate can now be entered:

After inserting the chained certificate, press "Next" again:

The contents of the chained certificate are displayed here. You can then accept the certificate and install it with "Install the new Certificates". The last step is for the device to update the certificates:

After the update, the device reboots to activate the new certificates:

Download

The repository for the BeagleBone Black board and other boards can be found at GitHub: