- freely available
J. Sens. Actuator Netw. 2019, 8(3), 42; https://doi.org/10.3390/jsan8030042
- Emphasize the importance of implementing hardware security among IoT devices.
- Discuss challenges in securing hardware for IoT devices.
- Highlight threats to hardware and introduce Hardware Trojan (HT).
- Provide detailed taxonomy of Hardware Trojan and discuss some insertion methods.
- Provide countermeasures, with focus on HT detection techniques and Design for Trust.
3. Hardware Security Threats
3.1. Hardware Trojan
3.2. Hardware Trojan Taxonomy
- Type: Type distributes Trojan into functional and parametric classes. Trojans that are introduced through addition or removal of gates or transistors fall into the functional category, whereas trojans introduced by modifying existing wires or logic belong to the parametric category .
- Size: Size of a trojan depends on the number of components in the chip added or deleted. The smaller the trojan, the higher its probability for activation .
- Distribution: This signifies the location of the Trojan in the chip. If a Trojan’s components are topologically close in physical layout of the chip, it is categorized into tight distribution. If a Trojan is dispersed across the layout of the chip, it falls into the loose distribution class .
- Structure: Adversaries try to make sure that insertion of a Trojan should not change the physical layout of the circuit in order to evade detection .
3.3. Hardware Trojan Insertion
- Model A: SoC developers cannot develop all necessary IPs in house, so they purchase third-party IP (3PIP) cores, which could contain Trojan. Untrusted third-party IP vendors are adversaries in this case.
- Model B: Untrusted design houses are adversaries in this model. Fabrication is outsourced by fabless design house to third-party foundries with advanced process technologies. An adversary can insert an HT in the foundry.
- Model C: Third-party Electronic Design Automation (EDA) tools or fraudster designers are adversaries in model C. These tools and engineers or designers are involved in the process to fulfil the demands created by the increased complexity of SoC designs.
- Model D: Commercial Off-The-Shelf (COTS) products are the products that don’t require custom development and are available off the shelf. They are cheaper but not trustworthy. None of the development stages are trusted in this model.
- Model E: This model considers all of the supply chain as a potential adversary except the foundry. The product could be designed or developed in an unfriendly foreign country, or a Trojan may be inserted by a counterfeiter into the original design after cloning the IC.
- Model F: This model assumes the entire supply chain to be adversary except the SoC developer. It combines Model A and B. Some companies integrate third-party IP cores into their SoC designs, and third-party foundries fabricate the chips. Only the SoC developer is trusted.
- Model G: This model applies to companies who outsource both application-specific integrated circuit (ASIC) design and fabrication. Therefore, both the system design integrator and foundry cannot be trusted. Clients receive the chips after they are fabricated, tested, and packaged.
3.4. Side-Channel Attacks
3.5. Hardware Trojan Based Side-Channel Attacks
4.1. Trojan Detection
- Functional test: These tests require the activation of Trojans by using test vectors, and then the responses are compared with the correct results. The stealthy trojans gone undetected during manufacturing test process can be detected during these tests. The Trojans that do not change the functionality of the original circuit may not get detected by the functional tests. References [12,24] discusses that in order to hide from accidental triggering and side-channel analysis, HTs try to choose inactive nets (nets that rarely switch) in order to keep power leakage or extreme nets (nets that spend most time on one state) toa minimum. Circuit-under-test (CUT) can be evaluated, and inactive nets can be found by calculating the probability of switching of all the nets. Reference  proposes a method to detect low active nets on a CUT on function mode.
- Side-channel analysis: This method takes advantage of side effects produced by additional circuits or Trojan activation, i.e., extra path delay, power, heat, etc., which are measured to detect HTs . An IC fingerprinting technique uses side-channel information such as power, temperature, EM, etc., to construct fingerprints with noise modeling for an IC family. Reference  demonstrates a research that was able to distinguish a genuine IC from the one with a Trojan down to 0.01% of the size of the main circuit using IC fingerprinting. Most of these techniques require comparison against golden ICs, which is not always available. Also, highly sensitive instruments are needed to measure small side-channel signals such as leakage current, as Trojans require very little current due to their size. References [14,35] present an HT detection method based on side-channel analysis which shows that measuring path delay on 20 paths can help detect more than 80% of HTs.
- ATPG (automatic test-pattern generation) method: This method uses the application of digital stimulus to the chip and analyzes the digital output. Reference  discusses a few researches made based in the automatic test-pattern generation (ATPG) tool to detect HT. One scheme called MERO (Multiple Excitation of Rare Occurrence) uses a statistical approach based on generating test vectors, which excite rare nodes simultaneously and increase the probability of an HT being triggered and detected easily. The research proposes the use of this technique with side-channel detection techniques to increase their impact. Another ATPG-based research discussed in  changes the design rules to detect HT that is inserted in the chip’s existing logic.
- Functional validation: This technique uses the same principle notion mentioned in the functional test described under postsilicon techniques. Functional tests are performed on a tester, which involves collecting output responses to each input pattern provided, but functional validation is conducted with simulation using existing functional testing techniques .
- Code/Structural analysis: Behavioral or structural codes are tested to detect any redundant statements or circuits that might be associated with a Trojan. These techniques do not offer detection guarantee and might require manual postprocessing diagnosis of suspicious signals or gates .
- Formal verification: This approach requires logic verification of target design that should satisfy a predefined set of security properties. This technique might not detect other unexpected functionalities caused by a Trojan beyond these predefined security properties .
- Proof Carrying Hardware (PCH): A PCH framework uses an interactive theorem prover to verify security properties on soft IP cores. Soft IP cores are synthesizable cores and exist as a netlist (a list of logic gates and interconnections used in an integrated circuit) or as a hardware description language (HDL) code. Reference  presents a theorem-proving and equivalence-checking approach using PCH to protect IP cores and verify the absence of malicious implants in the IP blocks.
4.2. Design for Trust
- Configurable Security Monitors: This approach uses security monitors to facilitate real-time functionality monitoring by adding reconfigurable logic in an SoC. The signal behavior is checked by feeding the signals to Security Monitors (SMs). The configuration of the SM is done to implement FSM, and it does not disturb the normal operation of the system. When an abnormality is detected, the checking occurs simultaneously with the other operations of the system and triggers countermeasures as needed. To perform different security checks, SMs can be reconfigured as well .
- Variant-Based Parallel Execution: This approach performs the simultaneous execution of multiple functionally equivalent variants on different processing elements (PEs), and the results are compared. On detecting a mismatch, a new PE is involved until a match is possible and Trojan-infected PEs are identified . The more efficient the generation of variants, the more effective is the process. This approach can help computers with multi-core processors achieve a high level of trust, but with an additional cost of computational, performance, and energy overhead.
- Hardware–Software Hybrid Approach: Trojan detection and tolerance by a software solution can provide efficient safety for systems with microprocessors . This approach uses design-verification tests to identify unused circuitry and marks it suspicious. This technique circumvents HTs by removing the suspicious circuitry and replacing it with exception logic . A software exception is triggered which allows the system to bypass the HT and operate normally .
Prevention of HT Insertion
- Obfuscation: This approach is based on making HT insertion difficult for an attacker by obscuring functionality and structural properties of a design. The obfuscation approach is based on applying a key-based obfuscation technique. This technique modifies a circuit’s state transition function, which makes it operate in two modes, i.e., a normal mode and an obfuscated mode. An obfuscated mode produces incorrect functional behavior, generating incorrect output, while the normal mode produces desired output. Thus, internal circuit nodes are obscured, and it makes it difficult to identify genuine functionality. This approach thwarts the ability of an adversary to insert Trojans without knowing the circuit functionality and right input vectors. Also, a Trojan might be active only in obfuscated mode, which makes it benign. The right function of the circuit appears only when the right key is applied. Logic obfuscation is classified into combinational and sequential logic obfuscation. In combinational logic obfuscation, the addition of XOR or XNOR gates in design is performed randomly. The key-gate is provided one functional input and one bit key input. Tamper-proof memory inside the design is used to store the correct key. For sequential logic obfuscation, the functional state of a finite-state machine is concealed by introducing additional states and transformations [20,24,39].
- Layout Filler: One of the common ways that attackers use to insert an HT in a circuit is by placing the Trojan in unused vacant spaces in the circuit. To prevent HT insertion, the empty spaces in the circuit layout are filled with functional filler cells using a built-in self-authentication (BISA) approach. The reason why filler cells are functional is so that the attacker cannot replace these filler cells with a Trojan without changing the functionality of the circuit. The functional filler cells form a combinational circuitry. Any abnormal function detected during testing indicates the replacement of filler cells with a Trojan [7,24].
4.3. Split Manufacturing
4.4. Other Hardware Security Techniques for IoTs
- Device Identity: Device identity is necessary to enforce accountability. Organizations are using Public Key Infrastructure (PKI) for securing their digital communication with digital certificates. Digital certificates are used to implement various security controls such as device authentications, securing host-to-host communication, and securing communications using TLS/SSL communication protocols. PKI’s ability to scale makes it a great infrastructure for device identity and authentication. However, due to the limited lifespan of digital certificates, the device manufacturer must consider the lifespan of these certificates and combine PKI with a proper certificate management method .
- Hardware Security Module (HSM): IoT devices that are easily accessible are prone to physical attacks, which is why there is a need to use tamper-protected hardware security modules to protect information such as cryptographic key and operations such as data encryption, PIN verification, etc. HSM is a physical device used to provide an extra layer of security around cryptographic keys, trade secrets, and other sensitive applications or data. The HSM device can be embedded in another hardware, connected to a server, or be used as a standalone device. Giving each device a unique electronic identity would increase the authenticity of the device, and this is achievable by injecting a semiconductor chip with a unique identity in each device. This process is called key injection. The integrity of the key injection process is of extreme importance and can be achieved by using HSMs as they establish a Root of Trust for this process. HSMs are capable of creating, securing, and managing these keys .
- Trusted Platform Module (TPM): Trusted Computing Platform Alliance (TCPA) came up with TPM as hardware instantiation of TCPA specification with a focus on ensuring privacy and enhancing security. TPM is a secure microprocessor with added cryptographic functionalities and comes in various shapes and sizes: as discrete or embedded hardware devices, or firmware implementations. TPM hardware provides platform root of trust and is capable of extending its trust to other parts of the platform by building a chain of trust. TPM has a built-in RSA engine, that can perform up to 2048-bit RSA encryption/decryption, which is used when it does digital signing and key wrapping. TPM contains a built-in hash function as well to compute hash values of small pieces of data. TPM uses a set of special-purpose Platform Configuration Registers (PCR), which store single cryptographic hash and are readable by external software. Each binary in the boot chain computes a hash of the subsequent binary and extends it into the PCRs, as well as records it in measurement log. The sequence of these measured values can be compared against current PCR values to check for integrity of the measurement log. TPM also provides attestation by signing the PCR values with its attestation key. Attestation Identity Keys (AIK) are used to provide platform authentication. Certificates available within TPM are used to create AIKs . TPM may hold three types of certificates:
- Endorsement certificate that contains a public key of EK, which stands for Endorsement Key (public/private key pair unique to every TPM) to provide attestation about the legitimacy of a TPM.
- The Platform certificate that provides attestation of a platform’s security components.
- The Conformance certificate that provides attestation by an accredited party of platform’s security properties .
- Roots of Trust (RoT): Roots of trust in a computing system are hardware/software components that are inherently trusted by the computer’s OS. It is a source that a cryptographic system can always trust. It must be implemented in hardware ideally and is trusted to protect cryptographic keys, perform device authentication, or verify software. RoT may include a variety of components such as security perimeter to define the requirements for SoC protection, secure CPU, runtime memory to protect runtime data, tamper resistance, True Random Number Generator (TRNG), secure clock, secure counter, and secure storage . RoT provides the functionalities behind trusted computing features such as drive encryption, storage protection, secure communication, key management, and secure monitoring, where hardware Root of Trust would notify the host about an attempt to add malicious insertion that has been made. Root of Trust is critical to create an embedded HSM for an IoT .
- Physical Unclonable Function (PUF): PUF is a lightweight security primitive that can be exploited for device identification, authentication, secret key generation, and storage. They are unique due to their unclonability and tamper-evident properties. PUFs are similar to one-way functions as the mapping between inputs and outputs is repeatable but also irreversible. “Challenge” is the electrical stimulus provided to a PUF which leads to a reaction called “response”. The set of challenge-response pairs (CRP) characterizes a PUF instance and represents a unique feature used for its identification. PUFs are considered to be tamper-evident, as any malicious modifications of the PUF structure are easily detectable. Reference  proposes a method for a hardware mutual authentication protocol using PUF. Reference  proposes a way to implement a secure communication protocol for an IoT based on PUF. Traditional security mechanisms used EEPROM (electrically erasable programmable read-only memory) and battery-backed nonvolatile SRAM in order to store secret keys, which are vulnerable to various attacks. Therefore, the use of tamper-resistant devices to store and defend keys from attacks is crucial. The resource limitation in IoT devices makes it difficult to use traditional methods to store these keys. Silicon PUFs provide a promising security alternative for IoT devices. The key generated by PUF is tamper resistant, as physical tampering damages underlying nanoscale structural disorder. Ring oscillator PUFs are a great choice for key generation as they produce a limited number of CRPs for authentication, which makes it very desirable for small-sized devices .
- Device Identifier Composition Engine (DICE): DICE is a security standard created by Trusted Computing Group (TCG) for hardware-based cryptographic device identity, attestation of device firmware, safe deployment, and data encryption. Its modest hardware requirements make it perfect for use in resource-constraint IoT devices for security and privacy and it can be implemented in hardware of security products during manufacturing. It uses a one-way hash function simple equation and can easily be implemented in a tiny microcontroller. DICE architecture is designed to address the need for security enhancement in IoT devices, especially where Trusted Platform Modules (TPM) may be unfeasible due to limited resources. It works by organizing the boot into layers. A unique “secret” is computed by each layer which is kept confidential by each layer. The configuration is based on Unique Device Secret (UDS). Whenever a different code is booted, the secrets change. If a secret is disclosed due to a vulnerability, the device is automatically re-keyed, and secrets are protected . Microsoft was the first to adopt DICE with Azure IoTs and new Device Provisioning Services (DPS) .
Conflicts of Interest
- Tao, H.; Bhuiyan, Z.; Abdalla, A.; Hassan, M.; Zain, J.; Hayajneh, T. Secured Data Collection with Hardware-Based Ciphers for IoT-Based Healthcare. IEEE Internet Things J. 2019, 6, 410–420. [Google Scholar] [CrossRef]
- Health IT Security. Available online: https://healthitsecurity.com/news/healthcare-ransomware-medical-device-security-key-2018-trends (accessed on 9 March 2019).
- Maple, C. Security and privacy in the internet of things. J. Cyber Policy Issue 2 Internet Things 2017, 2, 155–184. [Google Scholar] [CrossRef]
- Fremantle, P.; Scott, P. A security survey of middleware for the Internet of Things. Peer J. 2015, 3, e1521. [Google Scholar]
- Hayajneh, T.; Bassam, J.M. Lightweight Block Ciphers for IoT: Energy Optimization and Survivability Techniques. IEEE Access 2018, 6, 35966–35978. [Google Scholar]
- Bassam, J.M.; Hayajneh, T.; Vasilakod, A.V. A survey on lightweight block ciphers for low-resource devices: Comparative study and open issues. J. Netw. Comput. Appl. 2015, 58, 73–93. [Google Scholar]
- Bassam, J.M.; Hayajneh, T.; Khalaf, Z.A.; Yousef, K. Modeling and optimization of the lightweight HIGHT block cipher design with FPGA implementation. Secur. Commun. Netw. 2016, 9, 2200–2216. [Google Scholar]
- Hayajneh, T.; Bassam, J.M.; Yousef, K.; Khalaf, Z.A.; Bhuiyan, Z. Hardware Design and Modeling of Lightweight Block Ciphers for Secure Communications. Future Gener. Comput. Syst. 2017, 83, 510–521. [Google Scholar]
- Gusmeroli, S.; Piccione, S.; Rotondi, D. IoT Access Control Issues: A Capability Based Approach. In Proceedings of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS-2012), Palermo, Italy, 4–6 July 2012; pp. 787–792. [Google Scholar]
- University of Cincinnati. Available online: http://gauss.ececs.uc.edu/Courses/c6056/pdf/hardware.pdf (accessed on 4 March 2019).
- Rostami, M.; Koushanfar, F.; Karri, R. A Primer on Hardware Security: Models, Methods, and Metrics. Proc. IEEE 2014, 102, 1283–1295. [Google Scholar] [CrossRef]
- Zou, M.; Cui, X.; Shu, L.; Wu, K. Potential Trigger Detection for Hardware Trojans. IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst. 2018, 37, 1384–1395. [Google Scholar] [CrossRef]
- Venugopalan, V.; Patterson, C. Surveying the Hardware Trojan Threat Landscape for the Internet-of-Things. J. Hardw. Syst. Secur. 2018, 2, 131–141. [Google Scholar] [CrossRef]
- Wang, X.; Salmani, H.; Tehranipoor, M.; Plusquellic, J. Hardware Trojan Detection and Isolation Using Current Integration and Localized Current Analysis. In Proceedings of the IEEE International Symposium on Defect and Fault Tolerance of VLSI Systems, Boston, MA, USA, 1–3 October 2008; pp. 87–95. [Google Scholar]
- Kounelis, F.; Sklavos, N.; Kitsos, P. Run-Time Effect by Inserting Hardware Trojans, in Combinational Circuits. In Proceedings of the Euromicro Conference on Digital System Design (DSD), Vienna, Austria, 30 August–1 September 2017; pp. 287–290. [Google Scholar]
- Koley, S.; Ghosal, P. Addressing Hardware Security Challenges in Internet of Things: Recent Trends and Possible Solutions. In Proceedings of the 12th IEEE International Conference on Advanced and Trusted Computing (UIC-ATC-ScalCom-CBDCom-IoP), Beijing, China, 10–14 August 2015; pp. 517–520. [Google Scholar]
- Wang, X.; Tehranipoor, M.; Plusquellic, J. Detecting Malicious Inclusions in Secure Hardware: Challenges and Solutions. In Proceedings of the IEEE International Workshop on Hardware-Oriented Security and Trust (HOST), Anaheim, CA, USA, 9 June 2008; pp. 15–19. [Google Scholar]
- Bhunia, S.; Narasimhan, S.; Chakraborty, R. Hardware Trojan: Threats and emerging solutions. In Proceedings of the 2009 IEEE International High Level Design Validation and Test Workshop, San Francisco, CA, USA, 4–6 November 2009; pp. 166–171. [Google Scholar]
- Kumar, S.; Mahapatra, K. How to Protect Your Device from Hardware Trojans. In Proceedings of the Real World IoT Security Conference, Bangalore, India, 20 June 2017. [Google Scholar]
- Bhunia, S.; Hsiao, M.; Banga, M.; Narasimhan, S. Hardware Trojan Attacks: Threat Analysis and Countermeasures. Proc. IEEE 2014, 102, 1229–1247. [Google Scholar] [CrossRef]
- Yang, K.; Hicks, M.; Dong, Q.; Austin, T.; Sylvester, D. A2: Analog Malicious Hardware. In Proceedings of the IEEE Symposium on Security and Privacy (SP), San Jose, CA, USA, 22–26 May 2016; pp. 18–37. [Google Scholar]
- Wang, X. Hardware Trojan Attacks: Threat Analysis and Low-Cost Countermeasures through Golden-Free Detection and Secure Design. Master’s Thesis, Case Western Reserve University, Cleveland, OH, USA, 2014. [Google Scholar]
- Jin, Y.; Kupp, N.; Makris, Y. Experiences in Hardware Trojan Design and Implementation. In Proceedings of the IEEE International Workshop on Hardware-Oriented Security and Trust (HOST), San Francisco, CA, USA, 27 July 2009; pp. 50–57. [Google Scholar]
- Xiao, K.; Forte, D.; Jin, Y.; Karii, R.; Bhunia, S.; Tehranipoor, M. Hardware Trojans: Lessons Learned after One Decade of Research. J. ACM Trans. Des. Autom. Electron. Syst. (TODAES) 2016, 22, 6. [Google Scholar] [CrossRef]
- Chip Design. Available online: http://eecatalog.com/chipdesign/2018/10/04/iot-security-starts-with-threat-modeling-and-security-analysis/ (accessed on 4 March 2019).
- Pammu, A.; Chong, K.; Ho, W.; Gwee, B. Interceptive Side Channel Attack on AES-128 Wireless Communications for IoT Applications. In Proceedings of the IEEE Asia Pacific Conference on Circuits and Systems (APCCAS), Jeju, Korea, 25–28 October 2016; pp. 650–653. [Google Scholar]
- Spreitzer, R.; Moonsamy, V.; Korak, T.; Mangard, S. Systematic Classification of Side-Channel Attacks: A Case Study for Mobile Devices. IEEE Commun. Surv. Tutorials 2018, 20, 465–488. [Google Scholar] [CrossRef]
- Genkin, D.; Shamir, A.; Tromer, E. RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis. In Annual Cryptology Conference; Springer: Berlin/Heidelberg, Germany, 2014; Volume 3552, pp. 444–461. [Google Scholar]
- Breier, J.; He, W. Multiple Fault Attack on PRESENT with a Hardware Trojan Implementation in FPGA. In Proceedings of the IEEE International Workshop on Secure Internet of Things (SIoT), Vienna, Austria, 21–25 September 2015; pp. 58–64. [Google Scholar]
- Search Security. Available online: https://searchsecurity.techtarget.com/definition/differential-power-analysis-DPA (accessed on 2 March 2019).
- Lin, L.; Kasper, M.; Guneysu, T.; Paar, C.; Burleson, W. Trojan Side-Channels: Lightweight Hardware Trojans through Side-Channel Engineering. In Proceedings of the 11th International Workshop on Cryptographic Hardware and Embedded Systems CHES, Lausanne, Switzerland, 6–9 September 2009; pp. 382–395. [Google Scholar]
- Ender, M.; Ghandali, S.; Moradi, A.; Paar, C. The First Thorough Side-Channel Hardware Trojan. In Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security, Hong Kong, China, 3–7 December 2017; pp. 755–780. [Google Scholar]
- Chen, H.; Wang, T.; Zhang, F.; Zhao, X.; He, W.; Xu, L.; Ma, Y. Stealthy Hardware Trojan Based Algebraic Fault Analysis of HIGHT Block Cipher. Secur. Commun. Netw. 2017. [Google Scholar] [CrossRef]
- Agrawal, D.; Baktir, S.; Karakoyunlu, D.; Rohatgi, P.; Sunar, B. Trojan Detection using IC Fingerprinting. In Proceedings of the IEEE Symposium on Security and Privacy (SP’07), Berkeley, CA, USA, 20–23 May 2007; pp. 296–310. [Google Scholar]
- Amelian, A.; Borujeni, S. A Side-Channel Analysis for Hardware Trojan Detection Based on Path Delay Measurement. J. Circuits Syst. Comput. 2018, 27, 1850138. [Google Scholar] [CrossRef]
- Ranjani, R.S.; Devi, M.N. Malicious Hardware Detection and Design for Trust: An Analysis. Elektrotehniski Vestn. 2017, 84, 7–16. [Google Scholar]
- Guo, X.; Dutta, R.; Jin, Y. Pre-silicon security verification and validation: A formal perspective. In Proceedings of the 52nd Annual Design Automation Conference, San Francisco, CA, USA, 8–12 June 2015. [Google Scholar]
- Rooney, C.; Seeam, A.; Bellekens, X. Creation and Detection of Hardware Trojans Using Non-Invasive Off-The-Shelf Technologies. Electronics 2018, 7, 124. [Google Scholar] [CrossRef]
- Li, H.; Liu, Q.; Zhang, J. A Survey of Hardware Trojan Threat and Defense. Integr. J. 2016, 55, 426–437. [Google Scholar] [CrossRef]
- Allerin. Available online: https://www.allerin.com/blog/authentication-and-device-identification-in-iot-security (accessed on 9 April 2019).
- Utimaco. Available online: https://hsm.utimaco.com/solutions/applications/key-injection/ (accessed on 15 April 2019).
- Bajikar, S. Trusted Platform Module (TPM) Based Security on Notebook PCs—White Paper; Mobile Platforms Group Intel Corporation: Santa Clara, CA, USA, 2002. [Google Scholar]
- Synopsys. Available online: https://www.synopsys.com/designware-ip/technical-bulletin/understanding-hardware-roots-of-trust-2017q4.html (accessed on 9 April 2019).
- Barbareschi, M.; De Benedictis, A.; Mazzocca, N. A PUF-based hardware mutual authentication protocol. J. Parallel Distrib. Comput. 2018, 119, 107–120. [Google Scholar] [CrossRef]
- Chatterjee, U.; Chakraborty, R.; Mukhopadhyay, D. A PUF-Based Secure Communication Protocol for IoT. ACM Trans. Embed. Comput. Syst. 2017, 16, 1–25. [Google Scholar] [CrossRef]
- Zhang, J. Physical Unclonable Function-Based Key Sharing for IoT Security. Available online: https://arxiv.org/pdf/1807.10884.pdf (accessed on 15 April 2019).
- Mattoon, D. DICE: Foundational Trust for IoT. In Proceedings of the Microsoft Flash Memory Summit, Santa Clara, CA, USA, 8–10 August 2017. [Google Scholar]
- Electronic Design. Available online: https://www.electronicdesign.com/embedded-revolution/roundtable-qa-device-identity-composition-engine-dice (accessed on 15 April 2019).
|Trojan Type||Trigger Mechanism||Area Overhead (Flip-Flops & Lookup Tables (LUTs))||Detection Possibility||Insertion Module|
|1||Keyboard input “New Haven”||+0.8% & +6.8%||Probably not||Possible||Alphatop.v|
|2||“F12” key pressed||−9.4% & +0.024%||Probably not||Probably not||Kb2ascii.v|
|3||Word “Moscow” detected in plaintext||+3.3% & +2.4%||Probably not||Possible||Alphatop.v|
|4||Overflow of input buffer||+0.068% & +1.8%||Probably not||Possible||Alphatop.v|
|5||Change of key index||+0.75% & +1.4%||Almost impossible||Probably not||Async_transmitter|
|6||Inserted counter increment until it exceeds a predefined number||+0.34% & +0.17%||Almost impossible||Probably not||Alphatop.v|
|7||Unused RxD port||−4.4% & +4.9%||Almost impossible||Probably not||Async_Receiver.v|
|8||“Caps Lock” or another undefined key||−5.3% & +2.6%||Almost impossible||Probably not||Kb2ascii.v & kbtop.v|
|Model Number||Trojan Model||Untrusted Parties|
|A||Untrusted 3PIP (Third-party IP)||3PIP vendor|
|B||Untrusted fabless design house||Foundry|
|C||Untrusted SoC (System on a Chip) developer||SoC developer|
|D||Untrusted commercial off-the shelf (COTS)||3PIP vendor, foundry and SoC developer|
|E||Untrusted design||3PIP vendor and SoC developer|
|F||Untrusted outsourcer||3PIP vendor and foundry|
|G||Untrusted system integrator & foundry||System integrator and foundry|
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).