Project description

The project Verifree is about GPG key server. The goal is build a Key server, where users are able to verify the GPG keys. Admins should be also delete non valid keys. Verifree servers will be an internal servers only and NOT connect into the public GPG infrastructure.

The reason for the "private" GPG key serves is, that at the moment, if we want to used GPG key we trust external GPG key servers and we have no control for data there.

GPG keys on the server will be only for employees and we as admins will be able to control them.

We should have more then one server in the infrastructure and regularly sync data.

The long term goal is made this as a security add-on/application and be able offer it to SUSE customers to run their own GPG key serves

Goal for this Hackweek

Build basic application running on SLE/openSUSE OS. * be able to install it via an RPM * configure the app and have basic functions there. * have a salted it to be able run other servers on demand * setup basic work flow for the key management and verification

Resources

Any help from others is welcome.

Looking for hackers with the skills:

rust gpg security cryptography

This project is part of:

Hack Week 21

Activity

  • about 2 months ago: fbonazzi liked this project.
  • about 2 months ago: dgedon liked this project.
  • about 2 months ago: jzerebecki liked this project.
  • about 2 months ago: jzerebecki added keyword "cryptography" to this project.
  • about 2 months ago: jzerebecki added keyword "gpg" to this project.
  • about 2 months ago: jzerebecki added keyword "security" to this project.
  • about 2 months ago: jzerebecki added keyword "rust" to this project.
  • about 2 months ago: jzerebecki joined this project.
  • about 2 months ago: crameleon joined this project.
  • about 2 months ago: crameleon liked this project.
  • 2 months ago: ConradBachman joined this project.
  • 2 months ago: moroni_flores started this project.
  • 2 months ago: mcaj originated this project.

  • Comments

    • crameleon
      about 2 months ago by crameleon | Reply

      It would be cool if it still had an option to verify keys or signatures against a public, external, GPG server to catch irregularities - the benefit of the federated key servers on the internet is that if one gets compromised, one could get suspicious if they find a different key for a person on a different keyserver. Since we are only going to run one single keyserver internally, if the infrastructure gets compromised, there is no other party to ask for trust.

      • jzerebecki
        about 2 months ago by jzerebecki | Reply

        There are dumps available, at least one of these sources seems to be current: https://github.com/SKS-Keyserver/sks-keyserver/wiki/KeydumpSources

      • mkoutny
        about 2 months ago by mkoutny | Reply

        Ideally, GPG keyserver should not be the source of trust. You have web of trust between individual keys and use the keyserver as an unreliable medium. You verify the keys locally with (sub)set of keys and you don't care if the server is or isn't compromised. (You only may be affected by its unavailability.)

        Also, in my understanding, the internal keyserver is not supposed to serve to distribute any key but just those associated to SUSE accounts.

        • jzerebecki
          about 2 months ago by jzerebecki | Reply

          Yes, GPG/OpenPGP currently has no mechanism to ensure one is up to date on revocations. So it is vulnerable against keyservers being made to not serve some revocations.

          In theory it is possible to fix this, but I know of no practical implementation.

          Even if you do not solve this, it is a good idea to ingest the updates from the keyserver gossip. If you do not you refuse information you can verify, which is even worse.

    • jzerebecki
      about 2 months ago by jzerebecki | Reply

      Note that hagrid is both not GDPR compliant and removes important information (e.g. signatures and revocations used for Web of Trust) in a failed attempt at GDPR compliance: https://gitlab.com/hagrid-keyserver/hagrid/-/issues/151

      I can think of two right now working ways for exchanging keys to avoid problems with GDPR: 1) Exchange keys by exporting, encrypting, ASCII armoring it and then attach it to a mail; exchange certification requests and confirmations by saving it as a text file, signing, encrypting, ASCII armoring it and then attach it to a mail. This reduce many things people stumbled over that were common even before the dos vulnerability of keyservers were more widely known. 2) Maintain the keys involved in a project in a git repository. Have the git repo contain a privacy policy that explains the consequences. For submitting their key people create a commit that is singed by the same key that it adds in ASCII armored form. This means the privacy policy is in the history of the commit they signed, so they could have read it. When someone ask for their info to be deleted, delete the repo and start a new history without this key. This has the advantage that everyone who already had a copy of the repo, notices on the next git pull and can easily understand which key was deleted. Without this advantage you could get into the situation where you never receive updates like revocation for a key without knowing it. (kernel.org uses a similar repo explained at https://lore.kernel.org/lkml/20190830143027.cffqda2vzggrtiko@chatter.i7.local/ .) You still need to use (1) for requesting and confirming certifications.

      One could use a CI to make additions and updates to a git repo like in (2) self-service. Thus you could create a pull request and once CI passes it gets automatically merged. This CI job would allow adding a key that is trusted by existing ones with commit signature by the added key, for anything else require commit signature is valid and from a key already in this repo, allow updating when import old in new key doesn't add anything, allow editing docs, check generated data matches if touched, deny anything else.

      The gpg reimplementation that hagrid uses as a library is https://docs.sequoia-pgp.org/sequoia_openpgp/ which is recommended.

    Similar Projects

    Rust in linux kernel by dsterba

    [comment]: # (Please use the project descriptio...


    Give back to Wezterm by mpagot

    [comment]: # (Please use the project descriptio...


    Learn Rust from scratch by pherranz

    Project Description

    As I do not work as a d...


    Improve zypp-gui tool by xiaoguang_wang

    zypp-gui is a gui tool to update the system and...


    rinit by dspinella

    [comment]: # (Please use the project descriptio...


    FIDO2 emulation by mkoutny

    [comment]: # (Please use the project descriptio...


    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a ...


    Explore Crev as collaborative code audit by pperego

    Project Description

    Crev [1] is a collabo...


    FIDO2 emulation by mkoutny

    [comment]: # (Please use the project descriptio...


    Learn more about Application Security (AppSec) Open Source Tools and Testing Techniques by heidi.bronson

    [comment]: # (Please use the project descriptio...


    Poking technologies for enrolling customer key to kernel trusted keyring by joeyli

    [comment]: # (Please use the project descriptio...


    FIDO2 emulation by mkoutny

    [comment]: # (Please use the project descriptio...


    OMEMO Hexchat plugin by dknorr

    [comment]: # (Please use the project descriptio...