TapNLink Firmware Architecture
Request flow schematic
This schematic shows the main blocks implemented during a communication session with TapNPass. The main blocks are:
- The Host protocols group (mainly wireless) receives requests from the outside world: a mobile phone or a remote interlocutor,
- The Command processor processes requests from a Host protocol,
- The Control blocks can be addressed by specific requests. They also filter requests, and possibly code or decode them, validate or refuse them....
- Target protocols link to the target system.
These protocols can receive the requests via 2 channels:
- cable (UART). This channel is mainly reserved for initial configuration in the factory (customization or provisioning), or in test and development. It can be disabled by the configuration (like any other protocol).
- wireless. NFC is available in all versions, and can be supplemented by BLE or WiFi, or LoRa.
This central element receives requests from Host protocols, processes them, and returns a response (at least a return code). These commands are always formatted packets:
- They can be encrypted. In this case, they are re-injected after decryption and the responses are encrypted before being returned.
- These are usually commands available in high-level APIs, reformatted to be understood and decoded. These commands can be addressed to target protocols, or to security and configuration blocks.
- Before being redirected to their destination, an authorization check is systematically performed. This usually involves determining whether the profile that issued the request is authorized to execute this command.
Target protocols allow for dialogue with an application:
SWD is the standard debug protocol for Cortex-M-based microcontrollers. Using this protocol allows you to build a PoC in a few minutes on an existing application. This protocol can still (when enabled) be used to perform a remote debug session.
S3P protocol is used to filter addresses and to secure communication to the target. It uses 2 GPIOs (like SWD).
On most Cortex-M microcontrollers it can be used on a debug port (that was disabled for protection).
On other microcontrollers (non-Cortex) it can be used on any pair of GPIOs as long as one of them is an interrupt input.
UART and modbus handler
UART is a configurable asynchronous serial I/O (baudrate, parity, handshake mechanism...). It can be used either to address Modbus variables (which are then subject to access control) or as a transparent serial channel.
All these blocks work together to coordinate the protection of the system and its data:
- By validating that each order is compatible with the rights of the active profile,
- By ensuring the security of end-to-end communications through authentication and encryption.
Other functional blocks
Not everything is represented on this diagram. It is necessary to mention in addition:
- Singlepacket (1) processing block transmits secure singlepackets in delayed time. They are used, for example, to transmit a firmware update or a temporary login token for an occasional user.
- Data log processing block samples data from a bundle at a predefined time interval, stores it and then transmits it, in a singlepacket(1), from the Tap to a dedicated server.
(1) Singlepackets can contain one order, or a set of orders. They are like secure emails transmitted to, or received from, a remote interlocutor (usually a server connected to an MQTT broker).