# A Framework for Constructing a Secure Domain of Sensor Nodes
## 5 Results and Discussion
### Performance Evaluation  
The demonstrator's preparation aimed to prove the usefulness and correctness of the concept of a security domain of sensor nodes and to assess the system's security. The evaluation of performance in terms of detailed computational requirements was not the primary goal of this work. Assuming the TPM performed all activities related to generating cryptographic keys, encrypting and decrypting data, and determining the value of the hash function, we made some related observations. The efficiency of the TPM module when performing these activities varied. For example, generating an asymmetric RSA-2048 key takes the most time and could take up to ninety seconds. Fortunately, this operation is only carried out in the phase of pre-preparation of the node, in which there is no time pressure. The remaining activities require from a few to several dozen milliseconds. The time of reading data from the NVRAM of the TPM, which is about 46 ms, is significant.  
**Memory utilizing**  
The basis for the construction of each sensor node is the Arduino Mega 2560 R3 module, which uses the AVR ATmega 2560 microcontroller. This microcontroller has 256 kB Flash, 4 kB EEPROM, and 8 kB RAM. Flash memory is used in about 60%. The EEPROM size limits to sixty the number of sensor nodes that can be registered in the domain. The size of RAM was a very big limitation for the implementation of the solution. Such a small memory forced the allocation of most data structures in dynamic memory and releasing it immediately after use. This approach, in particular, concerned data structures for cryptographic keys. It is worth realizing that the data structure containing the private and public part of one asymmetric RSA2048 key requires about 800 bytes of RAM--it is about 10% of accessible RAM. The use of dynamic memory allocation extends the initialization time of data structures, also because the cryptographic keys that are stored in the NVRAM of the TPM are necessary to initialize these structures. However, this approach allows for more effective use of RAM.  
**Delay of the cryptographic protection procedures**  
When creating software for the sensor node, it was assumed that the cryptographic keys would be stored in protected TPM resources, but in the explicit form in RAM they will only reside during the execution of procedures that require these keys. From the point of view of security, this approach is correct, but it extends the duration of the procedures utilizing the cryptographic keys. In order to check what delay causes cryptographic protection of the sent frame, an experiment was performed in which the same data collected from the distance sensor was sent to the G node first without cryptographic protection and then using the Advanced Encryption Standard (AES) algorithm. The data were sent in the sensor_packet_req frame and the confirmation of receipt of this data in the sensor_packet_ans frame. The results of the experiment are given in Table 4.  
The time needed to handle an encrypted frame is about 83 ms longer than serving an unencrypted frame. It is worth noting here that the reading time of the encryption key from NVRAM of the TPM is about 46 ms. Of course, it is possible to resign from downloading of the key from the NVRAM of the TPM whenever needed and keep this key in RAM, but such an approach is less secure and further increases the RAM deficit.