ARM and SOC makers have been very responsive to the revelation, says the team, but there is no single fix. As CLKSCREW requires some degree of timing precision in delivering the faults, one mitigation strategy is to introduce randomization (via no-op loops) to the runtime execution of the code to be protected. While this mitigates against attacks without a timing anchor such as an attack on an AES encryption key, it may have limited protection against attacks that use runtime profiling such as an attack on RSA keys. Several software-only defenses propose compiling code with checksum integrity verification and execution redundancy, and while these would be viable on high reliability systems, they are not typically deployed on commodity devices such as phones because they impact energy efficiency.
“Many of the design decisions that contribute to the success of the attack are supported by practical engineering concerns,” says the team. “The root cause is not a specific hardware or software bug but rather a series of well-thought-out, nevertheless security-oblivious, design decisions. To prevent these problems, a coordinated full system response is needed, along with accepting the fact that some modest cost increases may be necessary to harden energy management systems.”