• About
• Latest Posts

Kyle Rankin

PGP ID: 0xB9EF770D6EFE360F
Fingerprint: 0DFE 2A03 7FEF B6BF C56F73C5 B9EF 770D 6EFE 360F
Librem Social

Latest posts by Kyle Rankin (see all)

• Bootstrapping Trust with Anti-Interdiction - March 22, 2023
• Where is My Librem 5? Part 3 - March 8, 2023
• My Top 10 Lapdock Kit Tips - February 27, 2023

This past week, as part of escalating sanctions between the West and Russia because of the war in Ukraine, the FCC added the security company Kaspersky (creator of the popular Kaspersky Anti-Virus software) to its “security threat list” which means products from that company aren’t eligible for FCC funds. It’s important to note that this wasn’t due to a particular backdoor that was discovered in Kaspersky products. Instead this was because of the threat that Kaspersky (a Russian company) could be coerced by the Russian government to add a backdoor. Because Kaspersky’s software is proprietary, it would be incredibly challenging to audit the software and all future updates for backdoors.

A Russian bank has issued a warning of its own, advising customers to avoid updating software, in response to actual malicious code a developer added to their NodeJS library. In this case, the guidance wasn’t to avoid using the software, just to avoid updating that software and if an update is necessary, to review the code carefully. This distinction is critical, and points to a fundamental freedom that free software provides (freedom 1, the freedom to study how the program works) that leads to another freedom: the freedom from coercion.

All proprietary code is at risk from coercion, not just from authoritarian governments and not just against local companies. The New York Times reported that China coerced Apple to grant the government backdoor access to iCloud data in China. The US government has also coerced technology companies to implement backdoors, demonstrated not just by the Snowden revelations, but by the fact that the NSA developed new rules for continuing these practices after the Snowden revelations. While there were congressional inquiries about the guidelines they weren’t around stopping the practice, but simply trying to learn what the new guidelines were.

It’s not that free software can’t have backdoors. Any software can. It’s simply much more difficult to hide backdoors in free software, especially long-term, and especially in software that receives a lot of scrutiny. If a backdoor in free software is discovered, there is a public audit trail leading to the source both of the malicious code and the person who added it. For instance, it didn’t take very long for the public to discover the malicious code added to the node-ipc library that targeted computers in Russia and Belarus, even though it was being obfuscated.

For these reasons, governments are naturally reluctant to coerce a developer to add a backdoor to free software. It’s much easier to coerce a tech company who makes proprietary software. It also offers plausible deniability. Sometimes this takes the form of a “debug mode” or “admin mode” that a developer “forgot” to remove from the final binary.

Defenses Against Tampering

Since you aren’t free to inspect proprietary code, the main defense against tampering in proprietary software is code signatures. Yet this only protects against tampering after the company ships the binary. A tech company that’s coerced to add a backdoor would also be coerced to sign it.

By contrast, free software has a number of defenses against tampering. First, distributions that ship that software also sign the binary packages just like with proprietary software. Then of course there is the ability to inspect the source code for changes. Beyond that, many free software projects also follow the modern best practice of signing code changes which you can also inspect.

Yet what if a company that produces a free software project was coerced to add a backdoor to the binary as part of the build process instead of the public code repository? This kind of tampering is even more challenging to detect both in free and proprietary software. Backdoors in the build system is where reproducible builds come in, and I argue they are the biggest security advantage free software offers over proprietary software.

With reproducible builds, the binary software always matches the corresponding code that built it regardless of whether it was built on a company’s servers or your laptop. This means you can take the source code you have already inspected for backdoors, compile it, and compare the binary with the one the company provides for that same version of code. They should match. Much of the software in PureOS already can be reproducibly built including 100% of the base operating system, with the goal to reach 100% coverage throughout.

Protect Yourself

What happened to Kaspersky this past week should serve as a warning to all proprietary software vendors. Your software might be banned not because you implanted a backdoor, but because you could be forced to in the future. Alternatively, a government in a particular region might ban you unless you add backdoors in their region. Free software gives your customers the freedom to audit, and gives you the freedom from coercion. Regardless of international conflicts or regional regulations, your customers don’t have to trust you to be safe. Your customers have options. They can pause critical updates until they, someone they hire, or the community, have vetted them.

As a software user, be thoughtful about the software you depend on, especially for security- or business-critical applications. Are you safe from coerced backdoors or software bans if governments lean on your vendors? Could you or someone you hire inspect the code in that case? The solution is free software and increasing your security self-sufficiency so you can identify those areas where you are dependent upon other companies, choose solutions that allow you to revoke trust easily, hold your own keys, and audit your digital supply chain.