3 MbedTLS Over Lwip

The lightweight TCP/IP (LwIP) stack is an open-source TCP IP stack used in embedded systems. The LwIP stack is designed to reduce memory usage and code size. LwIP follows a layered approach. The relaxed scheme for communication between layers is established by using a shared memory, which means the application process and the networking code can use the same memory or internal buffers. Internally packets are represented as Pbufs (Packet Buffers) in LwIP. These Pbufs contain the payload of the packet to be transmitted in the network. In a scenario where MbedTLS is not present, the Pbufs contain the actual application data that is to be transmitted. But in case of secure communication, this data needs to be secured by one of the many possible approaches such as encryption, hashing, and so forth.

The LwIP project already has inbuilt support for MbedTLS. With MbedTLS being enabled, the data which passes through the default TCP layer now takes an alternate route and is processed by an Alternate TCP/IP layer (also referred to as ALTCP layer). These layers have callback functions set. The callback functions determine the behavior of application on establishing connection, sending data, receiving data, closing connection, handling errors, and so forth. MbedTLS can be used with LwIP socket APIs, BSD Socket APIs, Netconn APIs. This broad usage is achieved by populating a general altcp_tls_config struct, which internally uses MbedTLS functions for cryptographic/SSL operations.

The struct altcp_tls_config holds state that is needed to create new TLS client or server connections. This TLS config is then directly passed to LwIP functions or other LwIP internal structures. For example, the data that would generally pass through a callback tcp_recv (in case of MbedTLS not being enabled) now passes through altcp_recv (in case of MbedTLS being enabled). These alternate implementations have additional code (by default inside lwip-stack). All the alternate layer implementations are defined in the files at the following path: MCU_PLUS_SDK/source/networking/lwip/lwip-stack/src/apps/altcp_tls.

The usage of MbedTLS with LwIP is controlled at the top level by a macro defined in lwip-config/lwipopts.h. Enabling MbedTLS here, enables ALTCP layer. When the LwIP library is then rebuilt (MbedTLS enabled) the ALTCP layer handles the data. The data passes through an Alternate TCP layer (altcp) when MbedTLS is enabled as demonstrated in Figure 3-1. The data passes through an Alternate TCP layer (altcp) when MbedTLS is enabled.

When the tcp_new() function is called, a new Protocol Control Block (TCP PCB) is created. This PCB is a new TCP connection identifier that can be either set to listen for new connection or explicitly connected to another host. In case of MbedTLS, an alternate PCB is used (altcp_pcb instead of tcp_pcb). The altcp_pcb structure contains altcp_functions, a reference to the next PCB, pointers to the arguments, state of the PCB, and application callbacks.

LwIP offers sample applications such as HTTP client and server, MQTT client, and so forth. The vanilla LwIP applications are not secured and the communication in the network is insecure, which in field would results in the device being an easy target for a cyberattack.

Having MbedTLS over LwIP ensures the data passing through a secured end to end transmission channel. MbedTLS performs a 3-way TLS handshake before the actual data is transmitted. TLS handshake ensures that the entities willing to communicate are authorized and trustable. TLS ensures encryption and integrity of data, and authentication of entities in the network. Furthermore, MbedTLS also provides 2-way SSL authentication as well if additional security is desired.

The change in memory footprint of LwIP after MbedTLS enablement is almost negligible. The memory footprint of MbedTLS itself in applications was observed to be approximately 176KB (which can further be reduced). Table 3-1 represents the memory footprint.