## 2 Prior Research  
IMA is built on Trusted Computing Group (TCG) standards and TPM hardware [12; 13]. Similar solutions based on TCG/TPM have been proposed, such as the Next Generation Secure Computing Base (NGSCB) framework [14]. NGSCB provides the measurement function by dividing a disk into trusted and untrusted partitions, each running independent operating systems. However, due to a lack of flexibility and the incomplete coverage of measurement, NGSCB is limited in its use. Another trust computing architecture that implements integrity measurement in partition blocks on a hard disk is Terra [15]. However, Terra requires a large amount of measurement data to be stored and the consequential difficulty in processing the stored data. By implementing measurement functions at the kernel level, IMA overcomes these issues with a simpler approach. However, identifying IMA function security vulnerabilities reveals a potential attack surface where a block device with malicious firmware can subvert the protection mechanism [16]. By manipulating a disk cache at the firmware level, an attacker can deceive the IMA such that a measured file is incorrectly reported as not modified when it has been. The exploitation surface is limited to the firmware and so the means of exploiting a vulnerability may be limited to vendor channels or the supply chain. To provide a high-integrity Android operating system for mobile phones, a small set of SELinux policies and the PRIMA mechanism are combined [17; 18]. Depending on the IMA framework and the application of the class-level attestation, the measurement is implemented in both low-level system files and the binaries on top of the Android's Dalvik Virtual Machine (VM). This design may satisfy the requirement of fine-grained attestation. However, the absence of a root-of-trust device such as TPM may limit how the technique is applied in production. It has been claimed that a weakness is exposed in IMA if a large number of files need to be checked, resulting in the ML consuming too much storage space [19]. However, the assertion about storing ML in TPM does not recognise that it is only the aggregated value of ML that is stored in TPM, which takes very little space. However, the issue may exist for storage- and processing-constrained devices that may store ML, such as those on the Internet of Things (IoT). The IMA framework is often deployed as a stage in remote attestation. For example, Trusted Platform Service (TPS) is a policy-driven architecture that is a part of the general authorisation mechanism. TPS utilises IMA-based remote attestation to provide verification for system-wide integrity by combining IMA, TPM, Trusted Boot, and TPS [20]. To meet integrity requirements for VM environments such as Virtual Network Functions (VNF) and the underlying hypervisor, an IMA-based remote attestation solution may prove that the environment is trustworthy [21], but while a demonstration shows this may work, the approach has yet to be deployed in common hypervisors such as Xen and KVM. Similarly, a concern related to malware infiltration in a multi-tenanted cloud environment that puts the whole infrastructure at risk may be addressed through the application of a Tenant-Attested Trusted Cloud Service (Ta-TCS) [22]. Ta-TCS applies the IMA approach to address the needs of the trust mechanism for service consumers and providers in a way that provides minimal performance loss. Targeting performance, the scalability of remote attestation that relies on the IMA framework is influenced by time cost, recognised file coverage for executable code-diversity and configuration files, and unrecognised files, because they cannot be addressed by the file measurement database found on the remote party [23]. The influence of code diversity can be managed effectively, but system processes such as bootstrapping provide a significant time cost impact. Additionally, while bootstrapping, configuration files may not be recognised.