Security-first architecture: deploying physically isolated active security processors for safeguarding the future of computing

It is fundamentally challenging to build a secure system atop the current computer architecture. The complexity in software, hardware and ASIC manufacture has reached beyond the capability of existing verification methodologies. Without whole-system verification, current systems have no proven security. It is observed that current systems are exposed to a variety of attacks due to the existence of a large number of exploitable security vulnerabilities. Some vulnerabilities are difficult to remove without significant performance impact because performance and security can be conflicting with each other. Even worse, attacks are constantly evolving, and sophisticated attacks are now capable of systematically exploiting multiple vulnerabilities while remain hidden from detection. Eagering to achieve security hardening of current computer architecture, existing defenses are mostly ad hoc and passive in nature. They are normally developed in responding to specific attacks spontaneously after specific vulnerabilities were discovered. As a result, they are not yet systematic in protecting systems from existing attacks and likely defenseless in front of zero-day attacks.To confront the aforementioned challenges, this paper proposes Security-first Architecture, a concept which enforces systematic and active defenses using Active Security Processors. In systems built based on this concept, traditional processors (i.e., Computation Processors) are monitored and protected by Active Security Processors. The two types of processors execute on their own physically-isolated resources, including memory, disks, network and I/O devices. The Active Security Processors are provided with dedicated channels to access all the resources of the Computation Processors but not vice versa. This allows the Active Security Processors to actively detect and tackle malicious activities in the Computation Processors with minimum performance degradation while protecting themselves from the attacks launched from the Computation Processors thanks to the resource isolation.

[1]  Roberto Maria Avanzi,et al.  The QARMA Block Cipher Family. Almost MDS Matrices Over Rings With Zero Divisors, Nearly Symmetric Even-Mansour Constructions With Non-Involutory Central Rounds, and Search Heuristics for Low-Latency S-Boxes , 2017, IACR Trans. Symmetric Cryptol..

[2]  Martín Abadi,et al.  Control-flow integrity , 2005, CCS '05.

[3]  Michael Shuey,et al.  StackGhost: Hardware Facilitated Stack Protection , 2001, USENIX Security Symposium.

[4]  Mathias Payer,et al.  Control-Flow Integrity , 2017, ACM Comput. Surv..

[5]  Ning Zhang,et al.  TruSpy: Cache Side-Channel Information Leakage from the Secure World on ARM Devices , 2016, IACR Cryptol. ePrint Arch..

[6]  Lucas Davi Code-reuse attacks and defenses , 2015 .

[7]  Hovav Shacham,et al.  Return-oriented programming without returns , 2010, CCS '10.

[8]  Leendert van Doorn,et al.  A Practical Guide to Trusted Computing , 2007 .

[9]  Chris Fallin,et al.  Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors , 2014, 2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA).

[10]  Alessandro Orso,et al.  A Classification of SQL Injection Attacks and Countermeasures , 2006, ISSSE.

[11]  Carlos V. Rozas,et al.  Innovative instructions and software model for isolated execution , 2013, HASP '13.

[12]  Fan Long,et al.  Control Jujutsu: On the Weaknesses of Fine-Grained Control Flow Integrity , 2015, CCS.

[13]  Dawn Xiaodong Song,et al.  SoK: Eternal War in Memory , 2013, 2013 IEEE Symposium on Security and Privacy.

[14]  Gernot Heiser,et al.  Last-Level Cache Side-Channel Attacks are Practical , 2015, 2015 IEEE Symposium on Security and Privacy.

[15]  Dennis Sylvester,et al.  A2: Analog Malicious Hardware , 2016, 2016 IEEE Symposium on Security and Privacy (SP).

[16]  Hovav Shacham,et al.  The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86) , 2007, CCS '07.

[17]  Ning Zhang,et al.  CacheKit: Evading Memory Introspection Using Cache Incoherence , 2016, 2016 IEEE European Symposium on Security and Privacy (EuroS&P).

[18]  Herbert Bos,et al.  Memory Errors: The Past, the Present, and the Future , 2012, RAID.

[19]  David A. Wagner,et al.  ROP is Still Dangerous: Breaking Modern Defenses , 2014, USENIX Security Symposium.

[20]  Jesse M. Ehrenfeld WannaCry, Cybersecurity and Health Information Technology: A Time to Act , 2017, Journal of Medical Systems.

[21]  Christof Fetzer,et al.  Intel MPX Explained , 2018, PERV.

[22]  Michael Hamburg,et al.  Spectre Attacks: Exploiting Speculative Execution , 2018, 2019 IEEE Symposium on Security and Privacy (SP).

[23]  Zhenkai Liang,et al.  Jump-oriented programming: a new class of code-reuse attack , 2011, ASIACCS '11.

[24]  Marcus Peinado,et al.  Controlled-Channel Attacks: Deterministic Side Channels for Untrusted Operating Systems , 2015, 2015 IEEE Symposium on Security and Privacy.

[25]  Carl A. Gunter,et al.  Leaky Cauldron on the Dark Land: Understanding Memory Side-Channel Hazards in SGX , 2017, CCS.

[26]  Christof Fetzer,et al.  Intel MPX Explained: An Empirical Study of Intel MPX and Software-based Bounds Checking Approaches , 2017, ArXiv.

[27]  Mathias Payer,et al.  Control-Flow Integrity , 2017, ACM Comput. Surv..

[28]  Balaram Sinharoy,et al.  Advanced features in IBM POWER8 systems , 2015, IBM J. Res. Dev..

[29]  Ahmad-Reza Sadeghi,et al.  Counterfeit Object-oriented Programming: On the Difficulty of Preventing Code Reuse Attacks in C++ Applications , 2015, 2015 IEEE Symposium on Security and Privacy.

[30]  Laurie A. Williams,et al.  Evaluating Complexity, Code Churn, and Developer Activity Metrics as Indicators of Software Vulnerabilities , 2011, IEEE Transactions on Software Engineering.

[31]  Pavol Zavarsky,et al.  Threat Modeling for CSRF Attacks , 2009, 2009 International Conference on Computational Science and Engineering.