On malleability of security software

A typical procurement process of security software might look something like the following. You find a vendor that makes a product providing particular security guarantees you need. You negotiate a license for the use of the software and perhaps stipulate that the software needs to be audited by a third-party auditor at your expense.

The auditor creates a nice report asserting the security provided by this particular software matches your requirements. Satisfied, you proceed with the installation and integration of the security product and think you can rest assured that you’re safe.

Don’t be convinced by this auspicious tale.

When software is responsible for enforcing security policies, those policies can be undone by a simple software update.

This is a security policy bypass attack.

An example of a software-enforced security policy can be found in Apple’s iOS, the iPhone operating system.

iOS version 8 and up encrypt flash memory with a key derived from a PIN chosen by the user.

To prevent brute-force attacks against the PIN, iOS can be configured to wipe the device after 10 failed unlock attempts. Users might think they’re safe this way, yet Apple can remove this policy with a software update.

But why would Apple do this?

They probably wouldn’t voluntarily.

Early 2016, a U.S. district court ordered Apple to do exactly this. That is, create new software that removed this brute-force protection and present it as a software update (to an iPhone in evidence).

Apple didn’t want to do this, and their CEO even wrote an open letter discussing why they thought this was a bad idea. Ultimately, the U.S. government found another way in and no longer needed Apple to do this.

Nevertheless, the fact remains that Apple could have weakened its iPhone security architecture with a simple software update.

Software-as-a-Service users are even more vulnerable to security policy bypass attacks.

As a SaaS user you have little to no visibility into the actual software version on the server side, let alone the actual software.

Fortanix leverages remote attestation and cryptographic sealing mechanisms to prevent this. Remote attestation is the ability to prove to others what software you’re running. Sealing is the ability to encrypt data that can only later be decrypted by the exact same software running on the exact same hardware.

Remote attestation and sealing ensure that once private data has been entrusted to a particular hardware/software combination, it remains secure. A future software update will not be able to weaken the promise of security, even in the cloud.