Verified Boot
Donate
Boot chain and integrity guarantees. What is Verified Boot, Secure Boot, Trusted Boot, dm-verity? Advantages, restrictions for user freedom, and more.
What is Verified Boot?[edit]
Verified boot is a security feature.
- Purpose: Verified boot ensures that a system boots using only authorized and untampered software. Each stage of the boot process verifies the integrity and authenticity of the next stage before it is executed. This protects against attacks that modify the bootloader, kernel, or other critical parts of the system.
- Process: During boot, the system checks cryptographic signatures on firmware and system components like the bootloader, kernel, and drivers. If the signatures don't match or have been tampered with, the boot process can be halted, or recovery measures can be triggered.
In theory, if used right, it improves the security of the user without restricting user freedom. In practice however, for a large part, verified boot is used to enforce user-freedom restrictions.
Let's start with the advantages, and a bit of technical background of verified boot.
Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions including system, vendor, and optionally oem partitions. During device boot up, each stage verifies the integrity and authenticity of the next stage before handing over execution.
[...] Rollback protection helps to prevent a possible exploit from becoming persistent by ensuring devices only update to newer versions of Android.
In addition to verifying the OS, Verified Boot also allows Android devices to communicate their state of integrity to the user.Android Verified Boot
Articles:
- https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/
- https://www.solcept.ch/en/blog/critical-systems/secure-boot/
User Freedom[edit]
Freedom Software can be compatible with verified boot. No user freedom restrictions required. While verified boot is often used to restrict user freedom, to prevent the user from modifications and installing another operating system, verified boot is not inherently bad.
It depends on the details, if if the keys used to enforce verified boot are controlled by the vendor or by the user as well as on how the operating system implements verified boot. User-controlled keys are possible.
Nexus and Pixel lines support Verified Boot with user-controlled keysMike Perry, The Tor Project Blog
Verified Boot Comparison of Third-Party Controlled versus User-Controlled[edit]
| Category | Vendor-Controlled Verified Boot | User-Controlled Verified Boot |
|---|---|---|
| Improves security | Yes | Yes |
| Does not restrict user freedom | No | Yes |
| Does not hinder the user auditing their system for compromises. | No | Yes |
| Synonym 1 | Tyrant Security | Freedom Security |
| Synonym 2 | Enterprise Security | Cypherpunk Security |
| Empowers | Corporates | Individuals |
Compromised Verified Boot Vendor Key[edit]
How does verified boot work?[edit]
It's based on digital software signatures. Only operating systems that come with a valid digital software signature that is signed with a public key that is trusted by the device are booted. Otherwise, the device will refuse to boot.
Lower stage (such as firmware) and hands over control to the next level (such as bootloader). However, every stage will verify the digital software signature of the next stage.
The stage are approximately (simplified):
hardware trust root → firmware → bootloader → kernel → kernel modules → initrd → init
Or specifically on some Linux desktop distributions:
hardware trust root → firmware → shim -> grub bootloader → Linux kernel → kernel modules → initrd → systemd init
Should at any stage the digital software verification fail, then the boot process will be aborted.
There is no technical requirement for each stage to be signed with the same key. Each stage can ship its own keys and/or key management system.
What are the advantages of verified boot?[edit]
Due to this integrity check, unauthorized malware will be gone after reboot (if the device is capable to revert to a clean backup image) or the device will refuse to boot.
Conceptually this improves security because the user runs only applications that have a valid digital signature. This obviously excludes third-party unauthorized malware since this would not be signed with a valid digital signature.
What are the limitations of verified boot?[edit]
Unauthorized malware? Is there such a thing as authorized malware, is this even a thing? Yes. For example the pre-installed Google Play Services on Google Android. See massive espionage data harvesting on Google Android. Verified boot is a security technology but conceptually cannot stop malware that is built-into the operating system by its producer. That does not take away from its useful potential as a security improvement for users.
Who uses verified boot?[edit]
At the time of writing, there was no Freedom Software Linux desktop distribution that implemented full verified boot which means a full chain of digital software verification starting form the hardware trust root up to all pre-installed applications that come with the Linux distribution. Only kernel module digital software verification is supported. The verified boot for initrd and beyond is not yet implemented. (Other Distributions implementing Verified Boot )
By comparison, for example Android and iOS supports full verified boot.
What are the dangers of verified boot?[edit]
The main risks are mistreatment of users, user software freedom restrictions, taking power away from users and handing it over to operating system and application developers.
As verified boot is currently implemented, for the vast supermajority of users the key is controlled by the operating system vendor. Users enrolling their own keys in the hardware key store or at any later stage of the boot process is often literally impossible [1], undocumented, not well supported, and even discouraged.
Many user-freedom restrictions are enforced using verified boot, locked bootloaders and non-root enforcement. This includes Android Anti-Features, prevention of replacing the stock operating system on mobile devices and many other mobile devices restrictions.
Verified Boot Compatibility with Rooted Phones[edit]
Yes, verified boot can be compatible with rooted devices.
Verified boot with root support and even with user-locked bootloader would be possible if support for that is built-in into the boot process (bootloader, recovery image). But how to modify the system partition without breaking verified boot? Modern root solutions such as for example Magisk support "systemless" root, via file system overlays. It's called "systemless" because Android has a partition /system that remains unmodified when using "systemless".
Verified boot would be compatible with root if an approach similar to such as for example Magisk is using built into the bootloader / recovery image prior signing it.
Furthermore, for compatibility with verified boot, user modifications to the system partition could be reset at device reboot boot time from a known signed good image. This is technically very doable because Android already does something similar with its A/B update mechanism. [2] Then how would the user make their system modifications persistent? Via file system overlays and/or automation scripts that run after the boot process. There could even be an boot menu option to boot with versus without user system modifications.
Related forum discussion:
https://forums.whonix.org/t/overview-of-mobile-projects-that-focus-on-either-and-or-security-privacy-anonymity-source-available-freedom-software/4557/46
Rooted Security versus Non-Rooted Security[edit]
Quote [3]
And what the hell? Root with verified boot? That's like having the most secure castle while leaving the door open for anyone, you can't have both worlds.Anti user freedom viewpoint.
Root doesn't mean you give root permissions to any dumb app. I implied proper permission management and authorization, of course.
Then it's just like a secure castle where the user can go into all of the rooms, to some with a special key. You don't have to go into those rooms, but you have the option to at any time. And, depending on the implementation, you may change the special room, but if you return after the next reboot, it will be reverted back.
Actually, the castle analogy goes further: Unfortunately, many seem to interpret "verified boot" and "most secure" as "protects the dumbest user from shooting themselves in the foot on purpose by locking them into that castle. That is exactly where the recent apple scandal is coming from: The user is subservient to the OS vendor, and the OS vendor can abuse the user as they please.
Security is very important. Why? In order to not be exploited by strangers (criminals, spys...) against my interests. If security enables exploitation against my interests (by whomever, be it the OS vendor, the movie industry, or the government), it is not the security I want. This one OS is different than all the other evil ones? That's what Apple said before...Pro user freedom viewpoint.
If you're rooted your security is way lower. Simple as that. Rooting can be used against you, it can lead to exploitation, and likely has been. Note: you can have secure boot without root and using your own Android build, such as CalyxOS. Not rooting doesn't imply using the stock firmware, never has been.Anti user freedom viewpoint.
I honestly don't understand why it should be "Simple as that"? If you have the phone rooted, as long as you don't grant root to any application, why should it be less secure than if you hadn't rooted it? (assumed everything else the same, specifically the rom supporting verified boot with root) Then, by granting root permissions to apps, of course the attack surface gets larger, but this is a thing you control yourself. Your note was always understood. Of course not rooting doesn't imply using the stock firmware. It however implies that you are submitting to a different master. Who may be different, and maybe a bit more lenient than Google/Samsung/whoever, but that other master will still enforce any dumb app's will against you.Pro user freedom viewpoint.
Ideological Considerations[edit]
Before discussion the technical implementation details and security it might make sense to lay out one's position on who should have more power. Device owners or vendors.
- Should the operating system obey the user? Yes | No
- Should the user should have ultimate control? Yes | No
- Should the operating system make guarantees to app developers in case these guarantees are to the disadvantage of the user? Yes | No
- Does one oppose the war on War on General Purpose Computing? Yes | No
- Does one support the right to general computing? Yes | No
It is primarily a project goal and policy decision.
Technical excuses are mood. If there's a commitment pro freedom and against anti-features, then there's a way. Security needs to take the backseat if it curtails user freedom. A prison cell is more secure from car accidents but yet we don't want to live in a golden cage. If you want, you will find a way, if you don't want to, you will find reasons.
For example, in case of GrapheneOS non-root enforcement is a project goal and policy decision.
It doesn't sound like you want GrapheneOS since you don't care about the core security goals. I recommend using something else.GrapheneOS lead developer
GrapheneOS is not aimed at power users or hobbyists aiming to tinker with their devices more than they can via the stock OS or AOSP.
(resign-android-image is a script that attempts to provide root access for GrapheneOS.)
Verified Boot Security[edit]
https://source.android.com/docs/security/features/verifiedboot/verified-boot
Verified Boot Discussion[edit]
Does verified boot necessarily require an immutable (read-only) image? Does verified boot make any sense with read-write?
Can verified boot be useful for a general-purpose operating system?
The main problem when attempting to combine verified boot with full read-write access is that the user (or malware) can modify any file in /etc or /usr.
Let's consider running a tool that can show modified files in /etc and /usr, debsums -ce. Sample output might include:
/etc/xdg/Thunar/uca.xml
This means that configuration file /etc/xdg/Thunar/uca.xml has been modified for some reason. Users have many legitimate reasons to modify files. However, malware might also modify files. Malware might drop a startup unit in /etc/systemd/system/, but so might the user.
On top of that, it would need to be ensured that there aren't any new files or deleted files that could be planted by malware for the purpose of a persistent backdoor. For example, a drop-in into /etc/profile.d or a systemd unit file or drop-in. These can serve many legitimate purposes but can also be abused by malware.
The main problem with verified boot without immutability is that both the user and an adversary can change pretty much anything on the hard drive.
Potential misconception:
Verified boot makes sure the code that is booted is safe, and then from that point on its job is done.
Quote https://source.android.com/docs/security/features/verifiedboot/verified-boot
verification is a continuous process happening as data is loaded into memory
One concept to implement verified boot is an immutable, minimal root image. That, however, is mostly suitable for specialized appliances. The disadvantage is a lot of lost user functionality and freedom. It would be a hard and dictatorial decision about what goes into the root image. It would kind of force some specific technology on the user (for example, going all in on Flatpak).
Freedom to modify in-place and security are at odds with each other. Anything that is secured by verified boot becomes immutable.
Is it possible to at least get the compromise of non-persistence from verified boot? Yes, but then one ends up with things like "I rebooted and now all the software I installed is gone." Verified boot with reset after reboot would be similar to live mode. So even if full apt-get install access was permitted, that would be gone after reboot.
Can user-installed packages using apt-get install persist + verified boot?
debsums alike functionality? [5] One would have to trust everything in the apt repository to make that safe, which might be an acceptable assumption, and somehow prevent the user from adding additional repositories or installing deb packages that they built themselves.
Some problems when considering a mutable (read-write) verified boot are:
- Just how mutable? Should systemd units be mutable or immutable? If immutable, many packages won't be installable. If mutable, setting up a persistent backdoor becomes easy. If "live-immutable," software will break after a reboot.
- Verified boot with mutability will be too easy to bypass. If someone leaves, for instance,
/usr/local/binmutable because "of course it should be mutable, that's where user-installed software goes," malware might plant a malicious executable there that will now be persistent and override calls to an executable in an immutable/usr/bin. - System updates? Verify and copy files to the "fake-immutable" base filesystem after a successful update? What if a non-persistent compromise manages to compromise the updater so it copies malicious files to the base partition?
With a real immutable filesystem, updates become hard. It would require system image updates rather than apt packages for the base system, but somehow maintain compatibility with apt packages too.
For real immutability, we would need to invent A/B updates for Debian. Vanilla OS is doing A/B updates with Debian Sid.
So verified boot can only always be specialized operating systems, not general-purpose operating systems? As in "This is a nice verified boot image, start the browser, reboot, any potential malware compromise will self-heal."
Suppose there is this minimal immutable base image... And then a chroot where the user can do anything? We might not get too much from that. It requires an entire ecosystem. And the Debian ecosystem doesn't really have verified boot on the radar.
The approach Fedora Silverblue takes, only they also allow Flatpak and root fs modification via rpm-ostree (security impact?).
With a read-write (rw) image and verified boot, at best maybe what one could get is a simple factory reset in the boot menu. The user could choose factory reset, which resets all changes in the root image. Nice, but not that great of a feature.
One cannot do dm-verity on a "normal" filesystem. Only on images, block devices. Any changes and it breaks. Quote:
> Device-Mapper’s “verity” target provides transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API. This target is read-only.
One ends up with a read-only filesystem.
To allow this to be mutable, one needs to have some way of applying changes to it, which requires some way of automatically signing those changes, which exposes a key to malware should it infect the system.
Quote systemd-sysext:
Files and directories contained in the extension images outside of the /usr/ and /opt/ hierarchies are not merged, and hence have no effect when included in a system extension image. In particular, files in the /etc/ and /var/ included in a system extension image will not appear in the respective hierarchies after activation.
Or systemd-confext for /etc.
How useful would it be to have verified boot for Kicksecure ISO? Since it's read-only anyhow.
It's hard to modify an ISO read/write. There is no public software available to really mount an ISO read/write. But it's possible in theory. The ISO should be considered read-write for attackers but read-only for the public. There is Open Source growisofs. Also, other attacks are conceivable such as repacking the ISO, which is documented in the Debian wiki and much easier than ISO. (TODO: repacking link)
Suppose someone writes the ISO to USB. Then the live session is compromised. By clever ISO read/write editing, the ISO compromise is made persistent. Would verified boot be able to come to the rescue here?
The machine needs to have the proper keys somewhere to verify the ISO image and detect if it is compromised. In practical terms, one might need to rely on Microsoft's keys. This means the attacker must not be able to access a leaked Microsoft key.
This approach doesn’t benefit a Linux distribution much since they must use their own key to verify the filesystem image. That image is created by the distribution, so it must be signed with their Microsoft's key.
The main issue is that an EFI executable, such as shim, cannot have two signatures. Either the distribution signs it, and the user uses the distribution's key in the BIOS (EFI), or the user manages their own keys (which is even less realistic), or the distribution relies on the Microsoft key (e.g., the default Debian shim).
Microsoft would likely be willing to sign a new Linux distribution shim. The Linux distribution "just" need to fork shim and then go through the shim review process. Many distributions have managed to get their shims signed, though the requirements for doing so are strict (e.g., key storage must be physically secure and require biometric authentication).
The root of trust ultimately resides with Microsoft. There isn’t a single universal shim. Even large distributions like Pop!_OS lack Secure Boot; only major distributions (e.g., Ubuntu, Debian, Fedora, openSUSE) have implemented it.
Kicksecure is Secure Boot compatible, thanks to Debian's shim, but this relies on appearing as Debian. If Kicksecure needs our own key for signing verified boot images, we would lose this compatibility. The "only one signature allowed on an EFI binary" restriction is preventing that.
One solution could be selling certified hardware with the project-specific key while removing the Microsoft key. But that is likely unrealistic. Another approach could involve a single ISO with two bootloaders, or separate ISOs for Microsoft-key-compatible and project-specific-key-compatible boot options. However, this adds complexity.
A potential compromise could be a fallback mechanism with two shims: one based on the Microsoft key and another on the project-specific key. The system could transparently switch to the secondary shim if the primary fails. But implementing this is a significant challenge.
When machines certified for other distributions (e.g., Ubuntu) are preinstalled, they include an Ubuntu-specific key from Canonical alongside the Microsoft key. However, relying on Secure Boot for verified boot while keeping compatibility with the Microsoft key poses challenges.
It’s possible to design a process where the Microsoft shim loads the kernel, the kernel then determines compatibility with the project-specific key, and the system reboots into a secondary bootloader signed by the project. But this approach requires additional firmware capabilities.
Another consideration is whether removing the Microsoft key is beneficial. While it would lock systems to the Linux distribution's key for Secure Boot, this might restrict compatibility further than Microsoft’s own Secure Boot implementation. A firmware option to enable or disable Microsoft or project-specific keys could address this.
Measured Boot, an alternative to Secure Boot, avoids the Microsoft key issue. While Secure Boot prevents unauthorized code from running, Measured Boot provides tamper evidence, which may be sufficient for many use cases. However, implementing this requires firmware support and careful design.
A feasible workflow might involve Secure Boot launching shim (signed by Microsoft), shim launching a measured boot utility (e.g., stboot), and stboot verifying the kernel and root filesystem. This would provide a chain of trust extending from firmware to userland. However, integrating stboot into this process is complex.
Ultimately, projects relying on their own key for signing or implementing Secure Boot independently of Microsoft face significant technical and logistical hurdles. While it’s possible to use external storage for managing measurements, this increases user complexity and introduces new risks.
Kicksecure Verified Boot Development Ideas[edit]
Verified VM Boot Sequence without Secure Boot[edit]
Talking about VMs only in this concept.
We could boot from a virtual, read-only (write-protected) boot medium such as another virtual HDD or ISO. Such a boot medium, which only contains a bootloader (shim or grub?), has the sole task of verifying the bootloader on the main hard drive that contains the bootloader, kernel, and Debian. That boot medium (such as ISO) could be shipped on Kicksecure Host through a deb package: /usr/share/verified-boot/check.iso.
Presuppositions
- The virtual BIOS cannot be flashed/compromised.
- Host is not compromised.
Boot Sequence
VM powered on → virtual BIOS loads boot DVD ISO (or alternatively another hard drive) (contains a bootloader only) → this initial bootloader signature is not verified but secure since booting from a read-only medium → verify bootloader on main hard drive → bootloader of main hard drive does signature verification of kernel → continue boot.
Requirements
grub-pc(notgrub-efi) with signature verification. [6]
By not booting from that initial boot medium (for testing or if it was broken), users could perform regular boots without verification of the bootloader on the main drive. From the perspective of the main drive, nothing would change, except we'd enable grub signature verification of the kernel on the main drive.
Simplification
The boot medium should not load the actual kernel for simplicity of implementation. Since it is read-only, it cannot be easily updated. Kernel packages change, and during kernel upgrades, /boot and grub.cfg on the main disk change. If /boot were write-protected, that would fail. Therefore, the initial boot medium is only a simplified alternative to EFI Secure Boot. By making the initial boot medium as simple as possible, i.e., only chainloading the next bootloader, it does not need frequent updates and does not need to be updated when kernel versions change.
If we could make grub-pc (not grub-efi) use check_signatures=enforce, then perhaps we don't need to port to EFI and/or Secure Boot soon or perhaps never.
enable Linux kernel gpg verification in grub and/or enable Secure Boot by default
Disadvantages
- Less secure than dm-verity which does continuous verification.
- initrd could still be compromised because at time of writing it is not signed yet by any Freedom Software Linux desktop distribution.
Hash Check all Files at Boot[edit]
Higher security level than Secure Boot.
This concept applies only to virtual machines (VMs).
We could boot from a virtual, read-only (write-protected) boot medium, such as another virtual HDD or ISO. Such a boot medium could run a minimal Linux distribution, which then compares against checksums from the Debian repository on the main boot drive:
- The MBR (Master Boot Record)
- The VBR (Volume Boot Record)
- [A] The bootloader
- [B] The partition table
- [C] The kernel
- [D] The initrd
- [E] All files shipped by all packages
There are tools that can help with checking all files on the hard drive, such as debsums. However, debsums, while more popular, is unsuitable. [7]
A tool such as debcheckroot might be more suitable for this task.
During the development of Verifiable Builds, experience was gained in verifying the MBR, VBR, bootloader, partition table, kernel, and initrd. Source code was created to analyze such files. [8]
Extraneous files would be reported, with options to delete them, move them to quarantine, and/or view them.
The initrd, by default in Debian, is auto-generated on the local system. Hence, there is nothing to compare it with from the Debian repository. However, after verifying everything (all files from all packages), it would be secure to chroot into the verified system and re-generate the initrd, then compare both versions. This step might not be required if the initrd can be extracted and compared against files on the root disk.
That boot medium (such as ISO) could be shipped on the Kicksecure Host through a deb package located at /usr/share/verified-boot/check.iso.
A disadvantage of this concept is that it might be slower than dm-verity. On the other hand, an advantage of this concept is that it does not require an OEM image. Additionally, it might be more secure since it does not verify against an OEM image but instead verifies the individual files. Another advantage is that users are free to install any package and are not limited by a read-only root image. Users do not have to wait for the vendor to update the OEM image.
dm-verity[edit]
Once the boot chain is verified, the kernel should verify the rest of the OS with a mechanism similar to dm-verity. Verified boot that covers only the boot chain is mostly useless, with some exceptions. [9]
We can implement two separate partitions: one for the base system and another for user-installed applications. The base system partition can be mounted as read-only and verified with dm-verity. The apps partition can be mounted as /apps, and chroot into it. The apps partition, however, will not be verified.
For example:
mount /path/to/unverified_image /apps for dir in bin sbin usr lib lib64 var etc do mkdir "/apps/${dir}" mount -o bind "/${dir}" "/apps/${dir}" done mkdir /apps/{proc,sys,dev} mount proc /apps/proc -t proc mount sysfs /apps/sys -t sysfs mount devtmpfs /apps/dev -t devtmpfs mount devpts /apps/dev/pts -t devpts apt install -o Dir=/apps $program chroot /apps $program
Verified Boot for User but not for Admin[edit]
This idea integrates well with Role-Based Boot Modes (user versus admin) for Enhanced Security and noexec.
- When booting into user
user, enable verified boot by default.- User user will not be able to modify
/etc,/usr. - Therefore the user will not have the ability to successfully execute
sudo apt install package-name.
- User user will not be able to modify
- When booting into user
admin, disable verified boot by default.- After booting into admin mode, admin can run
sudo apt install package-nameetc. - Based on dpkg trigger or shutdown, a new dm-verity has tree will be created, that will be used next time booting into user mode.
- After booting into admin mode, admin can run
Status[edit]
- Help welcome to implement this.
- https://forums.whonix.org/t/no-longer-add-virtual-dvd-drive-to-vm-by-default/9337 needs to be undone or considered. Could auto-add a DVD drive as long as needed.
Other Distributions implementing Verified Boot[edit]
- https://docs.clip-os.org/clipos/boot_integrity.html
- https://source.android.com/security/verifiedboot/
- https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
- https://blogs.oracle.com/solaris/post/solaris-verified-boot
- https://web.archive.org/web/20201126091953/https://coreos.com/blog/verifying-os-at-runtime.html
- https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/
- https://fedoraproject.org/wiki/Changes/FsVerityRPM
Immutable Linux Distributions[edit]
Vanilla OS, an immutable desktop Linux distribution designed for developers and advanced users,https://lwn.net/Articles/989629/
Forum Discussion[edit]
- https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894
- https://forums.whonix.org/t/fs-verity-in-linux-5-4/8911
See Also[edit]
Footnotes[edit]
- ↑ Many Android devices come with locked bootloaders. Many Android phones could not have been modded by the modding community because no way to break the verified boot chain and gain full read/write access to their own devices could be found.
- ↑
https://source.android.com/docs/core/ota/ab
- ↑
https://news.ycombinator.com/item?id=28096914
- ↑
https://archive.ph/94YVQ
- ↑
debsums -cedebsumsis not secure yet. It uses insecure checksums. But that might be fixable with an alternative implementation. - ↑
- ↑
Quote https://www.elstel.org/debcheckroot/
Usage of debsums instead of Debian-checkroot is strongly discouraged because debsums uses locally stored md5sums which can be modified by an attacker along with the files themselves. It has been meant for integrity checking, not for security issues! Debsums furthermore does not provide an output as clean and neatly structured as checkroot and does not spot files additionally added to your system by someone else.
- ↑
https://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/5100_create-report
- ↑ For example, Kicksecure loads apparmor.d from the initramfs, which it will cover.
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!