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

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

  • Comments

    • crameleon
      almost 2 years 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
        almost 2 years 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
        almost 2 years 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
          over 1 year 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
      almost 2 years 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

    A Flight Dynamics Library written in Rust with an Entity Component System architecture by vcuadradojuan

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


    Relm4-based user interface for Agama by IGonzalezSosa

    Motivation

    Disclaimer: the idea of this pr...


    toniowm by fabriziosestito

    toniowm is yet another window manager written i...


    A set of utilities to produce a "from scratch" OCI/Docker container using Opensuse/SLE rpms by ldragon

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


    Waysettings by dspinella

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


    Predefined app security policy template for NeuVector by feih

    Project Description

    Idea is to predefin...


    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a ...


    Port NeuVector zero-trust security functions to host/VM by feih

    Project Description

    Today, NeuVector on...


    Authenticated hashes for BTRFS by dsterba

    Project Description

    Implement a checksum ...