Sigstore is the latest project of Linux Foundation, which is a new model of software signature based on Certificate Transparency Log.
Sigstore solves the problem of keeping private keys caused by traditional PGP signatures, it has excellent openness and scalability, and is known as the Let’s Encrypt of software signatures.
TL;DR
Briefly, what the Sigstore project implements is to record the information of each signature through the Certificate Transparency Log, and end users query the Log and verify it when they need to use it. Since the public key is recorded in the Log, a different key can be used for each signature. This greatly reduces the risk of private key leakage and the pain of keeping the private key.
Why we need Sigstore
The vulnerability of the open source supply chain
From the SolarWinds attack, which still continues to fester, to the newly emerging packet manager rename packet attack, you can see that while more and more vendors are adopting open source solutions, security issues are becoming increasingly serious. These few issues in the open source supply chain are becoming more prominent.
- Long tool chain: The attacks are broad and any one of them can cause problems, such as the SolarWinds incident, where the VSCode with poison caused problems with many packages upstream of the supply chain.
- Openness and Transparency: Open and transparent CI, open source code and open management mechanism give more opportunities to those who are interested.
- Uncontrollability: A significant number of links in the open source tool chain are under the control of the community or other companies, and not under the control of the end users and companies.
As Luke Hinds demonstrated in the video conference, there are considerable security risks in the supply chain of even large companies.
Problems with the traditional CA approach
Traditionally, companies use a CA system for software signing. For example, a developer/development company that wants their software to run on Windows 10 without risky alerts would have to spend a certain amount of money to purchase a certificate for signing from DigiCert, Symantec or similar CA (note that certificates issued by Let’s Encrypt can only be used for domain verification, not for software signing) to sign their software. They cannot be used for software signing) to sign their software. Of course, the flaw in this system is obvious: centralization. We rely on absolute trust in CAs to ensure that the programs we run are untampered with, and if we encounter a CA like WoSign then the security of this system is lost.
Is PGP a best practice?
A considerable number of ecosystems and package managers, among others, use PGP deeply as the basis for their trust systems, and it has indeed performed well in a considerable number of cases so far. But the PGP trust system also has its problems.
- Private Key Custody: A private key obviously cannot be kept in a human brain, so where to store it becomes a problem. If only one copy is kept, then if that copy is lost for some reason (physical damage, OVH room fires up, etc.), then rebuilding trust will be a nightmare. Storing more than one copy would pose a problem, and if the private key was leaked and exploited, then withdrawing those contaminated versions would also be a nightmare.
- Multiple developers: The screenshot below shows the GPG public keys in use and used by Node.js developers. With so many core developers distributing using each one’s own keys, end users who want to verify signatures have to import dozens of keys and trust them, which creates verification problems.
- Public key distribution: Most projects use simple HTTP or HTTPS for public key distribution. And these web servers are really vulnerable to hackers, and if these public keys are replaced, then security is no longer possible.
- Trust system establishment: The trust system of PGP is based on decentralized human relationships, usually people will know or meet each other in the real world before making mutual signature trust, which certainly brings trouble to the trust system establishment, especially at the time of the global pandemic of New Crown Pneumonia.
What Sigstore solves
Private key storage problem
As we mentioned at the beginning, Sigstore uses CT Log as the Trust Root, and since the public key information is included in the Log, developers do not need the same key for each signature. This eliminates the need for developers to keep their keys carefully. Due to the growth of Log, the added Log can be kept as Immutable data, which provides better security than the current GPG public key approach.
Ease of use
Due to the complexity of traditional software signing methods, many developers don’t bother to sign the software they distribute, and the vast majority of users are even less likely to verify the software. So how can we get everyone involved in building this trust system?
The key is ease of use. Even if a system is perfect, if it lacks convenience, then few people will ask for it. There is a good hypothesis to illustrate this matter, if Microsoft announced the development of a new system SecureOS absolute security, we assume that it is really as Microsoft said absolute security, but it is not compatible with Windows software, no GUI, and can not even run on x86-64 system processors, then how many enterprises will pay for this new operating system? The answer can be imagined.
Sigstore uses several approaches to ensure convenience and compatibility with existing systems in the domain to ensure that migration costs are minimized.
First, Sigstore uses identity providers such as Web PKI + OpenID Connect for authentication. New authentication methods may also be added in the future. This is certainly a huge cost savings, which allows enterprises to migrate to the new system led by Sigstore almost painlessly. This authentication is also completely possible without using this system, GPG, x509, MiniSign are all supported as long as the identity of the developer can be determined.
Second, Sigstore uses the x509 standard for this part of the signature. This allows Sigstore to even work with Let’s Encrypt to provide free signed credentials. Moreover, the x509 infrastructure is almost everywhere, which is certainly much easier than with solutions like MiniSign.
Third, end-client authentication is in the form of CT Log. This eliminates the need for customers to import trusted certificates or maintain a list of CAs by the operating system or browser, for example. Any record that appears on the CT Log is authentic and anyone can verify its validity. Security can also be further enhanced using different verification strategies, such as requiring the same version to be co-signed by at least three maintainers.
Conclusion
I had the idea of signing my software, but was dissuaded by the high price of the certificate (as a student, I couldn’t afford it). As a developer, I sincerely hope that the Sigstore project will grow, after all, with the support of the Linux Foundation, this system should save a lot of costs in this area when it is rolled out.