However, the large number of terminal devices involved in IoT challenges the regular way of maintaining cyber security. Additionally, the integration of cloud technology leaves IoT network vulnerable to cyber-attacks. With more and more cyber-attacks reported these years, security is of vital importance for IoT developers.
In order to overcome this tough task, uMesh has paid great attention to ensure the safe connection of devices and maintain the security and confidentiality of data in cloud. As the core component of AliOS Things, uMesh can be characterized as self-organized, self-repairing, and multi-hop. It is suitable for scenarios that need large-scale deployment and with high security demands, such as intelligent homes, smart lighting, and commercial buildings.
The main capabilities and features of uMesh include:
Seamless support for IPv4 and IPv6
Support for various communication media, such as Wi-Fi, BLE, IEEE 802.15.4
Heterogeneous networking among different communication media
Tree topology and mesh topology
Low energy-consumption
ID² platform to authenticate and authorize the access devices
AES-128 to encrypt and decrypt data
Compatible with Port-based Netwok Access Control IEEE802.1x and Extended Authentication Protocol(RFC3748)
When programing ID², the corresponding private key will be programed into the chip, while the public key uploaded to ID² authentication center. The private key can later be used to decrypt the encrypted data sent by authentication center. In this case, channel authentication and key agreement in application layer can be achieved. The combination of ID² with various connecting protocols (such as MQTT and CoAP) further guarantees the safety of the whole IoT system. The framework of ID² platform is shown below.
The ID² platform offers two authentication modes: <b>challenge-response based mode</b> and <b>timestamp-based mode</b>, which can prevent replay attack. Take challenge-response based mode as an example, the Service Provider (SP) server can work as proxy, to transmit message between devices and authentication center (devices are assumed to be pre-programed with ID²). The following flowchart describes the process and interaction of the authentication message.
The flowchart can be summarized as follows:
Devices send authentication request to the SP server, applying for challenge to ID² authentication center.
The SP server calls POP SDK Java API: getServerRandom(), getting challenge from authentication center and returning it to devices.
Devices receive challenge, and call TFS API: tfs_id2_get_challenge_auth_code() to generate auth code, with ID², challenge, and extra data (optional) as parameters.
Devices send auth code to SP server, which then forwards it to authentication center.
SP server calls POP SDK Java API：VerifyRequest() to complete authentication.
Process transaction in SP server based on the result of authentication.
In addition, for devices that have access to the Service Provider (SP) server, ID² ensures mutual authentication between devices and server. That is, on the one hand, SP server needs to decide whether or not the device with that identity information is allowed to access; on the other hand, the device needs to confirm whether the SP server has the legitimacy to provide certification service. Through this mutual authentication, devices that have legitimate identity information, but do not belong to SP server's services scope will be filtered out. Additionally, different vendors can define their specific way of access to SP server, though this part will be out of scope of this article.
Traditional AAA (Authentication, Authorization and Accounting) services require IT experts to create every certificate manually. In addition, the x.509 certificate will consume many preset flash resources and extra MCU resources when analyzing and authenticating ASN.1 (some may be larger than 1KBytes). Therefore, authentication based on certificates is not a best choice for resources-limited devices.
ID² is a light-weight platform based on identity. There is no need for IT experts to manually repeat the same process of deployment and configuration. Instead, you can just call the corresponding SDK to contact with ID² authentication center.
The authentication process of devices in uMesh is set according to challenge-response-based mode. It is compatible with Port-based Network Access Control (IEEE802.1x) and Extended Authentication Protocol (EAP). IEEE802.11 is used in data transmission. EAP also provides a basic protocol framework for further expansion and compatibility of other authentication measures, such as MD5, OTP and TLS.
The security authentication process in uMesh based on ID² platform can be illustrated as follows.
Raspberry Pi 3 (RPi 3), directly linked to the Access Point (AP), plays the role of leader in the framework. It generates a new uMesh and distributes 16 bits address for subsequently-joined devices, which is used for communication within this uMesh. Meanwhile, RPi 3 uses iptable to set up NAT to transmit the IP data packet between tun0 and eth0. This enables devices in uMesh to communicate with SP server through an external network, and thus completing the authentication process in ID² platform.
The security authentication process of devices in uMesh is described in the following flowchart.
Extensible authentication protocol (EAP) defines the standard type of authentication (such as MD5, OTP, GTC, TLS) as well as some expanded types (type=254) to accommodate the existing process in different vendors. EAP-ID² is one of them used in uMesh based on ID² system. The detailed header format for extension type is as follows.
The authentication system in uMesh based on ID² platform has been verified in test environments. Furthermore, uMesh's compatibility with IEEE802.1x and EAP gives it more flexibility to meet different vendors' needs. AliOS, along with uMesh, provides a secure and reliable way for businesses to adopt IoT technologies.