# Evaluating the Efficiency of Physical and Cryptographic Security Solutions for Quantum Immune IoT
## 7 Discussion
### Guidelines for Quantum Immune Security  
The simulation results indicate that physical layer security is, from the energy efficiency perspective, a viable alternative for the cryptographic algorithms. From the security level perspective, the strength of physical layer secrecy coding is still an open debate (like the security level of cryptographic alternatives is as well). Both cryptographic and physical approaches may contain hidden vulnerabilities. Therefore, multi-layered approaches with both physical and cryptographic protection are an option for systems needing stronger assurance. The results indicate that such complementing approaches are feasible at least from the energy efficiency perspective. When using physical layer security for key exchange, we need an additional authentication algorithm as secrecy coding is unauthentic. The authentication property may be implemented with a protocol based on cryptography. In the post-quantum era, this algorithm must be quantum immune against the active attacker. However, the design of the authentication protocol may be simplified as the confidentiality (eavesdropping-resistance) property is provided by the physical layer. Future developments may also introduce authentication capabilities into the physical layer. For instance, quantum location verification [61] is a promising approach in this direction. Architectural implications from our results come from the observation that the costs are divided asymmetrically between the agreeing parties. In IoT, a battery restricted \"thing\" should be given the less consuming role. In the case of cryptographic protocols, the \"thing\" should play [PERSON]'s role while [PERSON] plays the (cloud) server's role. In the case of physical layer secrecy coding, the \"thing\" should play the physical layer transmitter's role, while the access point end must play the receiver's role. The security protocol and algorithm design should support this requirement: the \"thing\"--whether it is the initiator or responder of the communication--should be given a lighter role. Many security protocols (such as TLS, Datagram TLS, and Secure Shell (SSH)) apply a client-server architecture where the client initiates the connections. They do not explicitly support such role selection. However, they support algorithm selection; thus, to enable role selection, two alternatives could be defined: an algorithm where a more consuming role is played by the connection initiator (client) and an algorithm where the more consuming role is played by the responder (server). Nevertheless, such algorithm selection is not possible in all cases, for instance, in the more optimized TLS v1.3 [62] the keying material may be delivered already in the first handshake message. In these cases, an application layer handshake is needed to trigger the IoT thing to act as Bob, i.e., as a TLS server. In the physical layer security approach, the key should be generated by the \"thing\" as transmission is more energy efficient. However, many resource-restricted devices may not have hardware capabilities for generating good random numbers that are required for good cryptographic keys. In addition, the resource-restricted devices may not typically have additional antennas that are needed for beamforming. Recall that, in secrecy coding schemes, the transmitter typically has many antennas for efficient beamforming and sending artificial noise. Consequently, in these cases, the \"thing\" must become a receiver that is the most optimal role from the resource efficiency perspective. Fortunately, this limitation does not make physical layer solutions infeasible, as the efficiency advantage on the receiver-side is still large when compared with cryptographic schemes. The physical layer secrecy coding protects only wireless communication that occurs between a device and access point, base station or another device. It cannot provide protection against threats, where the adversary is elsewhere within the end-to-end communication path, e.g., between an access point and a cloud server.