Geekly Articles each Day
📜 ⬆️ ⬇️

Code Integrity Protection with PGP. Part 1. Basic concepts and tools

If you are writing code that goes into publicly accessible repositories, PGP may be useful. In this series of articles, the translation of the first of which we publish today, will address the use of PGP to ensure the integrity of the software code. These materials are mainly aimed at free software developers, although the principles outlined here are applicable in all situations where development is carried out by distributed programming teams.



The following topics will be covered here:
')

On the structure of materials


Each section of this series of materials is divided into two parts:

  1. A checklist that can be adapted to the needs of a specific project.
  2. Explanations, revealing the essence of the elements of the checklist, as well as instructions for working with programs.

Checklist Features


Items in each of the checklists include information about the level of priority of a particular item. We hope this will help you in making decisions on the use of the proposed recommendations.


Remember that all the lists listed here are only recommendations. If you feel that the prioritization levels do not reflect the security features of your project, you should adapt them to your needs.

Basic PGP Concepts and Tools


â–Ť Checklist


Here are the topics in which you need to navigate after successfully mastering the material in this section:

  1. The role of PGP in the development of free software (Important).
  2. Basics of public key cryptography (Important).
  3. Differences between encrypting and signing materials (Important).
  4. PGP key identification data (Important).
  5. The authenticity of the PGP keys (Important).
  6. Installing the GnuPG utilities (version 2.x) (Important).

â–Ť Explanations


The open source community has long relied on PGP to ensure the authenticity and integrity of the software being developed. You may not know about this, but whether you are working in a Linux, Mac or Windows environment, you have already used PGP to ensure the integrity of your computing environment.


This is very similar to the developer certificate and code signing mechanisms used by programmers working on closed source platforms. In fact, the basic concepts underlying these two technologies overlap. They differ mainly in technical implementation details and how they delegate trust. PGP does not rely on a centralized certification service; instead, this system allows users to independently assign a level of trust to each certificate.

Our goal is to help you control the origin of the code that enters your project and track its integrity with PGP. You can do this by following the recommendations for working with PGP and having learned the basic rules of safety.

PG PGP Job Overview


You do not need to know all the details about how PGP works. To successfully use this technology, it is enough to understand its basic concepts. PGP uses public key cryptography. Using cryptographic methods, for example, plain text can be converted to encrypted text. This process requires two different keys:


â–Ť Encryption


For encryption, PGP uses the public key of the person for whom the encrypted material is intended. During encryption, a message is created that can only be decrypted using the corresponding private key belonging to the recipient of the message.

The encryption process looks like this:

  1. The sender creates a random encryption key (session key).
  2. The sender encrypts the message contents using this session key (using a symmetric cipher).
  3. The sender encrypts the session key using the recipient's PGP public key.
  4. The sender sends the encrypted data and the encrypted session key to the receiver.

To decrypt an encrypted message, the following actions are taken:

  1. The receiver decrypts the session key using its PGP private key.
  2. The recipient uses the session key to decrypt the content of the message.

â–Ť Signing


To sign data, PGP public and private keys are used in the opposite way:

  1. The signer generates a checksum hash of some data.
  2. The signer uses her own private key to encrypt this checksum.
  3. The signer provides the encrypted checksum along with the data.

To verify the signature, perform the following actions:

  1. The reviewer generates its own checksum data.
  2. The verifier uses the signer's public key to decrypt the provided checksum.
  3. If the checksums match, the integrity of the content is confirmed.

â–Ť Sharing encryption and signing


Often, encrypted messages are also signed using the sender's own PGP key. This approach should always be used when encrypted messages are exchanged, since encryption without authentication does not make much sense (perhaps, anonymity in such things is needed only by secret agents and those who make certain information in the public domain).

Key identification data


Each PGP key must be associated with the identity of the key owner. Usually this is the full name of the person and the email address in the following format:

Alice Engineer <alice.engineer@example.com>

Sometimes credentials also contain comments, given in brackets, intended to inform the end user about the specific key:

 Bob Designer (obsolete 1024-bit key) <bob.designer@example.com>

Since people, owners of keys, can play many professional and personal roles, several sets of identification data can be present in the same key:

 Alice Engineer <alice.engineer@example.com> Alice Engineer <aengineer@personalmail.example.org> Alice Engineer <webmaster@girlswhocode.example.net>

When multiple sets of credentials are used, one of them is marked as primary, to simplify the search for the key.

â–Ť Key authenticity


In order to be able to use someone's public key for encryption or verification, you need to make sure that he really belongs to this person (Alice in this case), and not to the scammer (let the cheater be called Eve). In PGP, this is called key authenticity:


â–ŤNetwork of trust and the mechanism of "trust in the first use"


PGP includes a mechanism for delegating trust, known as the Web of Trust, WOT. At its core, this is an attempt to replace the need for centralized certification services such as those used in HTTPS / TLS. With this approach, the user makes decisions about who you can trust.

Unfortunately, very few people understand how the trust network works, and even fewer people care about this technology. And although trust networks remain an important aspect of the OpenPGP specification, existing versions of GnuPG (2.2 and higher) implemented an alternative approach, represented by the Trust on First Use (TOFU) mechanism.

TOFU can be compared with SSH. When you connect to a remote system for the first time using SSH, your system remembers the fingerprint of its key. If the key changes, the SSH client informs you of this and rejects the connection, prompting you to decide whether you trust the changed key or not.

The TOFU mechanism works in a similar way. When you first import someone's PGP key, it is considered trustworthy. If, after this, GnuPG encounters a new key with the same identification data, then both keys will be marked as invalid and you will have to decide for yourself which one should be saved.

In this tutorial, we will use the TOFU trust model.

â–ŤAbout terminology


Here we would like to note the importance of understanding the differences between terms such as PGP, OpenPGP, GnuPG and gpg:


Today, the term PGP is almost universally used in the sense of “OpenPGP standard” rather than as a program name, and thus PGP and OpenPGP are interchangeable. The terms GnuPG and gpg should be used only when referring to specific tools, not standards and other concepts with which we operate. For example:


Understanding these differences should help you communicate with other PGP users.

â–ŤInstall GnuPG


If you are using Linux, this means that GnuPG software is already installed on your system. On a Mac, you need to install GPG-Suite , or use the brew install gnupg2 . If you are a Windows user, then GPG4Win will suit you , and you will probably need to change some of the commands in this guide. If you use a Unix-like environment in Windows, you will not have to change commands. If you use any other platforms, then you will need to choose the appropriate implementation of GnuPG yourself.

â–ŤGnuPG versions 1 and 2


Both GnuPG v.1 and GnuPG v.2 implement the same standard, but they provide incompatible libraries and command line tools, with the result that many distributions come with both obsolete version 1 and newer version 2. You need to make sure That you always use GnuPG v.2.

First, to find out which version of GnuPG is hiding on your system under the name gpg , run the following command:

 $ gpg --version | head -n1

If you see something like gpg (GnuPG) 1.4.x , it means that with the command gpg GnuPG v.1 is invoked. In this case, gpg2 command:

 $ gpg2 --version | head -n1

If you see something like gpg (GnuPG) 2.xx , then everything is fine. Here we assume that you have GnuPG version 2.2 or later. If you are using GnuPG version 2.0, some of the commands that will be listed here will not work, so you should consider installing the latest version 2.2 of GnuPG.

â–ŤA pseudonym for GnuPG v.2


If you have both the gpg command and the gpg2 command on your system, it would be good to set everything up so that the gpg command gpg GnuPG v.2, and not the old software version. You can do this by creating a nickname:

 $ alias gpg=gpg2

This command can be placed in .bashrc in order for the GnuPG v.2 program to respond to the gpg command.

Results


Here we talked about the basics of PGP, which must be owned in order to successfully use PGP in code protection. Next time we will talk about creating and protecting PGP keys.

Dear readers! Do you use PGP to protect the code of your software projects?

Source: https://habr.com/ru/post/349618/

More articles:


All Articles