Kernel maintainer PGP guide

Linux kernel 개발에서 PGP의 역할

이 문서는 Linux 커널 개발자, 특히 하위 시스템 maintainer를 위한 PGP 안내서다. Linux Foundation의 Protecting Code Integrity 문서에서 커널 작업에 필요한 부분을 추려 설명하며, 각 주제의 더 깊은 배경은 원문 안내서에서 확인할 수 있다.

PGP의 첫 번째 목적은 커널 개발 공동체가 생산한 코드의 무결성을 보장하는 것이다. 두 번째로 PGP 서명 이메일을 이용해 개발자 사이의 신뢰 가능한 통신 경로를 만드는 데 도움을 준다.

Linux 커널 소스는 분산 Git 저장소와 정기 release tarball의 두 형태로 배포된다. 공식 release를 만드는 개발자는 Git tag에 PGP 서명을 넣고, tarball에는 detached PGP signature를 함께 제공한다. 이 서명은 kernel.org나 mirror에서 받은 내용이 release 개발자의 workstation에 있던 내용과 동일하다는 암호학적 근거가 된다.

2011년 kernel.org 핵심 시스템 침해 이후 Kernel Archives 프로젝트는 인프라의 어느 부분도 언제든 침해될 수 있다고 가정한다. 호스팅 시스템의 보안 수준과 무관하게 신뢰의 종착점은 서버가 아니라 개발자와 개발자의 키여야 한다.

그러나 신뢰 대상을 개발자로 옮기는 것만으로는 사고 책임을 개인에게 전가하는 결과가 될 수 있다. 이 안내서의 목적은 개발자가 안전한 작업 환경을 만들고 커널 무결성을 증명하는 PGP 키를 보호할 수 있도록 구체적인 운용 규칙을 제공하는 것이다.

• Protecting Code Integrityhttps://github.com/lfit/itpol/blob/master/protecting-code-integrity.md

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>`
:Translator: Alessia Mantegazza <[email protected]>

.. _it_pgpguide:

=========================================
La guida a PGP per manutentori del kernel
=========================================

:Author: Konstantin Ryabitsev <[email protected]>

Questo documento è destinato agli sviluppatori del kernel Linux, in particolar
modo ai manutentori. Contiene degli approfondimenti riguardo informazioni che
sono state affrontate in maniera più generale nella sezione
"`Protecting Code Integrity`_" pubblicata dalla Linux Foundation.
Per approfondire alcuni argomenti trattati in questo documento è consigliato
leggere il documento sopraindicato

.. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md

Il ruolo di PGP nello sviluppo del kernel Linux
===============================================

PGP aiuta ad assicurare l'integrità del codice prodotto dalla comunità
di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione
affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP.

Il codice sorgente del kernel Linux è disponibile principalmente in due
formati:

- repositori distribuiti di sorgenti (git)
- rilasci periodici di istantanee (archivi tar)

Sia i repositori git che gli archivi tar portano le firme PGP degli
sviluppatori che hanno creato i rilasci ufficiali del kernel. Queste firme
offrono una garanzia crittografica che le versioni scaricabili rese disponibili
via kernel.org, o altri portali, siano identiche a quelle che gli sviluppatori
hanno sul loro posto di lavoro. A tal scopo:

- i repositori git forniscono firme PGP per ogni tag
- gli archivi tar hanno firme separate per ogni archivio

.. _it_devs_not_infra:

Fidatevi degli sviluppatori e non dell'infrastruttura
-----------------------------------------------------

Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio
generale del progetto Kernel Archives è stato quello di assumere che qualsiasi
parte dell'infrastruttura possa essere compromessa in ogni momento. Per questa
ragione, gli amministratori hanno intrapreso deliberatemene dei passi per
enfatizzare che la fiducia debba risiedere sempre negli sviluppatori e mai nel
codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
pratiche di sicurezza messe in atto.

Il principio sopra indicato è la ragione per la quale è necessaria questa
guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori
non sia fatto semplicemente per incolpare qualcun'altro per future falle di
sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli
sviluppatori possano seguire per creare un ambiente di lavoro sicuro e
salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
stesso.

.. _it_pgp_tools:

GnuPG와 gpg-agent

배포판에 기본 설치된 GnuPG의 버전을 먼저 확인한다. 이 이탈리아어 원문은 GnuPG 2.2 이상을 기준으로 하며, 이전 version에서는 이 안내서의 일부 명령이 동작하지 않을 수 있다.

$ gpg --version | head -n1

gpg-agent는 gpg 명령을 사용할 때 자동으로 시작되어 백그라운드에서 private key passphrase를 cache한다. default-cache-ttl은 마지막 키 사용 뒤 cache가 유지되는 시간이며, 만료 전에 같은 키를 사용하면 countdown이 다시 시작된다. 기본값은 600초다.

max-cache-ttl은 최초 passphrase 입력 이후의 절대 최대 cache 시간이다. 그 사이에 키를 계속 사용했더라도 이 시간이 지나면 다시 passphrase를 입력해야 한다. 기본값은 30분이다.

# ~/.gnupg/gpg-agent.conf
# 일반 TTL 30분, 최대 TTL 2시간
default-cache-ttl 1800
max-cache-ttl 7200

현대 GnuPG에서는 shell session을 시작할 때 gpg-agent를 수동 실행할 필요가 없다. 이전 버전을 위해 rc 파일에 넣어 둔 agent 시작 코드가 있다면 현재 동작과 충돌하지 않는지 확인하고 제거한다.

Strumenti PGP
=============

Usare GnuPG 2.2 o successivo
----------------------------

La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
verificare che stia utilizzando la versione abbastanza recente. Per controllate
usate::

    $ gpg --version | head -n1

Se state utilizzando la version 2.2 o successiva, allora siete pronti a partire.
Se invece state usando una versione precedente, allora alcuni comandi elencati
in questa guida potrebbero non funzionare.

Configurare le opzioni di gpg-agent
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta
che userete il comando ``gpg`` e funzionerà in *background* con l'obiettivo di
individuare la passphrase. Ci sono due opzioni che dovreste conoscere
per personalizzare la scadenza della passphrase nella cache:

- ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima
  che il time-to-live termini, il conto alla rovescia si resetterà per un
  altro periodo. Di base è di 600 (10 minuti).

- ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo
  uso della chiave da quando avete inserito la passphrase, se il massimo
  time-to-live è scaduto, dovrete reinserire nuovamente la passphrase.
  Di base è di 30 minuti.

Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi),
potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri
valori::

    # set to 30 minutes for regular ttl, and 2 hours for max ttl
    default-cache-ttl 1800
    max-cache-ttl 7200

.. note::

    Non è più necessario far partire l'agente gpg manualmente all'inizio della
    vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che
    riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
    bene il loro compito.

.. _it_protect_your_key:

Primary key 보호와 offline backup

이 문서는 이미 커널 개발용 PGP 키가 있다고 가정한다. 키가 없으면 Protecting Code Integrity의 생성 절차를 따르고, 기존 RSA 키가 2048비트보다 약하다면 새 키를 만든다.

PGP key는 보통 하나의 keypair가 아니라 서로 독립된 여러 subkey의 묶음이다. 생성할 때 각 subkey에 capability를 부여한다. [S]는 서명, [E]는 암호화, [A]는 인증, [C]는 다른 키를 인증하는 용도다.

[C] capability를 가진 키를 흔히 master key라고 부르지만, 다른 subkey를 대신할 수 있다는 오해를 부른다. 실제로 [C] 키가 [E] 또는 [S] 키의 private operation을 대신할 수 없으므로 이 문서는 Certify key라고 부른다.

• 각 private subkey는 완전히 독립적이다. 하나를 잃어버리면 같은 key chain의 다른 private key로 복원하거나 다시 만들 수 없다.
• Certify key를 제외하면 같은 capability의 유효한 subkey를 여러 개 둘 수 있다. 한 [E] subkey로 암호화한 메시지를 다른 [E] subkey로 복호화할 수는 없다.
• 하나의 subkey가 여러 capability를 가질 수 있다. 예를 들어 [C]와 [S]를 함께 가진 [SC] 키가 가능하다.

Certify key만 key chain의 관계를 바꿀 수 있다. S/E/A subkey 추가와 폐기, UID 추가·변경·폐기, 자신과 subkey의 만료일 변경, Web of Trust를 위한 다른 사람 키 서명을 수행한다.

GnuPG 기본 생성 결과는 Certify와 Sign을 함께 가진 [SC] key 하나와 별도 [E] subkey 하나다. gpg --list-secret-keys 출력의 sec 아래 긴 40자리 문자열이 fingerprint이며, 아래 명령에서 [fpr]로 표시한 자리에 이 값을 사용한다.

sec   ed25519 2022-12-20 [SC] [expires: 2024-12-19]
      000000000000000000000000AAAABBBBCCCCDDDD
uid           [ultimate] Alice Dev <[email protected]>
ssb   cv25519 2022-12-20 [E] [expires: 2024-12-19]

GnuPG는 disk에 저장하는 private key를 passphrase로 암호화한다. .gnupg 디렉터리 전체가 유출되어도 공격자가 passphrase를 얻지 못하면 private key를 바로 사용할 수 없다. 따라서 강한 passphrase는 필수이며 다음 명령으로 설정하거나 바꾼다.

$ gpg --change-passphrase [fpr]

# [SC]만 있다면 독립된 signing subkey 생성
$ gpg --quick-add-key [fpr] ed25519 sign

목표는 Certify key를 offline media로 옮기고 일상 signing 작업에는 별도 [S] subkey를 쓰는 것이다. [SC] 결합 키만 있다면 먼저 signing subkey를 추가한다.

다른 개발자에게 받은 서명이 많을수록 key identity를 잃었을 때의 복구 비용이 커진다. 디지털 저장장치 전체가 손상되는 재해에 대비해 private key의 종이 백업을 만든다.

paperkey는 private key의 핵심 데이터를 출력 가능한 형식으로 만드는 도구다. 형식과 다른 방식보다 나은 점은 man paperkey에서 확인하며, 대부분의 배포판에서 package로 제공한다.

$ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt

파일을 출력하고 그 당시의 passphrase를 종이 여백에 손으로 기록하는 것을 강하게 권장한다. 출력된 key material도 passphrase로 암호화되어 있으며, 이후 passphrase를 바꾸면 백업을 만들던 때의 값을 기억하지 못할 가능성이 높다.

출력물과 수기 passphrase를 봉투에 넣어 집과 떨어진 은행 금고 같은 안전한 장소에 둔다. key data가 passphrase로 암호화되어 있으므로 cloud 연동 printer를 통한 출력도 상대적으로 안전하다고 원문은 설명한다.

paperkey는 재해 수준의 최후 복구본이고, 일상적인 key 변경에 사용할 수 있는 외부 백업은 별도로 필요하다. UID 편집, subkey 추가·폐기, 만료일 변경, conference나 summit 뒤 다른 사람 키 서명에는 Certify key가 든 이 복사본을 사용한다.

가급적 두 개의 외부 media를 준비하고 배포판 안내에 따라 LUKS 암호화 partition을 만든다. 암호화 passphrase는 PGP key와 같은 값을 사용할 수 있다고 원문은 제안한다. 장치를 mount한 다음 .gnupg 전체를 속성과 함께 복사한다.

$ cp -a ~/.gnupg /media/disk/foo/gnupg-backup

# 복사본을 직접 사용해 읽기 시험
$ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]

오류 없이 key가 표시되는지 반드시 시험한다. 장치를 unmount하고 실수로 덮어쓰지 않도록 분명히 표시해 안전한 곳에 보관한다. 다만 Certify 작업 때마다 꺼내야 하므로 재해 복구용 종이보다 접근 가능한 위치여야 한다.

home directory는 새 workstation을 위한 임시 복사, 시스템 관리자의 실수나 악의, 취약한 backup, browser·PDF viewer 같은 desktop app의 malware, 국경 통과 중 강제 조사 등 여러 경로로 유출될 수 있다.

강한 passphrase는 위험을 낮추지만 keylogger, 어깨너머 관찰과 다른 수단으로 노출될 수 있다. 따라서 Certify key는 일상 homedir에서 제거해 offline storage에만 둔다. 이 작업 전에 전체 .gnupg 백업이 정상 동작하는지 다시 확인해야 한다.

먼저 Certify key의 keygrip을 찾는다. 출력에서 pub 줄과 Certify fingerprint 바로 아래에 있는 Keygrip이 대상이다. 각 keygrip은 ~/.gnupg/private-keys-v1.d의 같은 이름 .key 파일에 대응한다.

$ gpg --with-keygrip --list-key [fpr]

pub   ed25519 2022-12-20 [SC] [expires: 2022-12-19]
      000000000000000000000000AAAABBBBCCCCDDDD
      Keygrip = 1111000000000000000000000000000000000000
uid           [ultimate] Alice Dev <[email protected]>
sub   cv25519 2022-12-20 [E] [expires: 2022-12-19]
      Keygrip = 2222000000000000000000000000000000000000
sub   ed25519 2022-12-20 [S]
      Keygrip = 3333000000000000000000000000000000000000

$ cd ~/.gnupg/private-keys-v1.d
$ ls
1111000000000000000000000000000000000000.key
2222000000000000000000000000000000000000.key
3333000000000000000000000000000000000000.key

# 백업을 검증한 뒤 Certify key 파일만 제거
$ rm 1111000000000000000000000000000000000000.key

이후 gpg --list-secret-keys에서 sec#가 표시되어야 한다. #은 public 정보는 있지만 해당 private key가 현재 homedir에 없다는 뜻이다. [E]와 새 [S] subkey는 ssb로 계속 표시된다.

$ gpg --list-secret-keys
sec#  ed25519 2022-12-20 [SC] [expires: 2024-12-19]
      000000000000000000000000AAAABBBBCCCCDDDD
uid           [ultimate] Alice Dev <[email protected]>
ssb   cv25519 2022-12-20 [E] [expires: 2024-12-19]
ssb   ed25519 2022-12-20 [S]

이전 GnuPG가 남긴 ~/.gnupg/secring.gpg에도 private key가 들어 있을 수 있으므로 제거한다. private-keys-v1.d가 없다면 아직 GnuPG v1의 legacy secring.gpg를 쓰는 상태다. passphrase 변경이나 subkey 추가 같은 key 변경을 수행하면 새 형식으로 자동 변환되며, 변환과 백업 확인 뒤 obsolete secring.gpg를 삭제한다.

Proteggere la vostra chiave PGP primaria
========================================

Questa guida parte dal presupposto che abbiate già una chiave PGP che usate
per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo
al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima.

Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048
bit (RSA).

Le sottochiavi PGP
------------------

Raramente le chiavi PGP sono composte da una singola coppia -- solitamente, sono
una collezione di sottochiavi indipendenti usate per diversi scopi in funzione
delle capacità assegnate al momento della creazione. Una chiave PGP può avere
quattro capacità:

- **[S]** può essere usata per firmare
- **[E]** può essere usata per criptare
- **[A]** può essere usata per autenticare
- **[C]** può essere usata per certificare altre chiavi

La chiave con la capacità **[C]** viene spesso chiamata chiave "passepartout"
(*master key*), ma è una terminologia fuorviante perché lascia intendere che la
chiave di certificato possa essere usate in sostituzione delle altre (proprio
come le vere chiavi passpartout in grado di aprire diverse serrature). Dato che
questo non è il caso, per evitare fraintendimenti, in questa guida ci riferiremo
a questa chiave chiamandola "La chiave di certificazione".

I seguenti punti sono molto importanti:

1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave privata
   non potrete recuperarla usando le altre.
2. Ad eccezione della chiave di certificazione, ci possono essere più
   sottochiavi con le stesse capacità (per esempio, potete avere 2 sottochiavi
   per criptare, 3 per firmare, ma solo una per una sola per certificare). Tutte
   le sottochiavi sono indipendenti -- un messaggio criptato usando una chiave
   **[E]** non può essere decriptato usano altre sottochiavi **[E]**.
3. Una sottochiave può avere più capacità (per esempio, la chiave **[C]** può
   anche essere una chiave **[S]**).

La chiave con capacità **[C]** (certificazione) è la sola che può essere usata
per indicare relazioni fra chiavi. Solo la chiave **[C]** può essere usata per:

- aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A;
- aggiungere, modificare o eliminare le identità (unids) associate alla chiave;
- aggiungere o modificare la propria data di scadenza o delle sottochiavi;
- firmare le chiavi di altre persone a scopo di creare una rete di fiducia.

Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue:

- Una chiave la capacità di certificazione che quella di firma (**[SC]**)
- Una sottochiave separata con capacità di criptare (**[E]**)




Se avete usato i parametri predefiniti per generare la vostra chiave, quello
sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``,
per esempio::

    sec   ed25519 2022-12-20 [SC] [expires: 2024-12-19]
          000000000000000000000000AAAABBBBCCCCDDDD
    uid           [ultimate] Alice Dev <[email protected]>
    ssb   cv25519 2022-12-20 [E] [expires: 2024-12-19]

La lunga riga sotto la voce ``sec`` è la vostra impronta digitale --
negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa
stringa di 40 caratteri.

Assicuratevi che la vostra passphrase sia forte
-----------------------------------------------

GnuPG utilizza le passphrases per criptare la vostra chiave privata prima
di salvarla sul disco. In questo modo, anche se il contenuto della vostra
cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli
attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza
aver prima ottenuto la passphrase per decriptarle.

È assolutamente essenziale che le vostre chiavi private siano protette da
una passphrase forte. Per impostarla o cambiarla, usate::

    $ gpg --change-passphrase [fpr]

Create una sottochiave di firma separata
----------------------------------------

Il nostro obiettivo è di proteggere la chiave primaria spostandola su un
dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata
**[SC]** allora dovreste creare una sottochiave di firma separata::

    $ gpg --quick-add-key [fpr] ed25519 sign

Ricordate di informare il keyserver del vostro cambiamento, cosicché altri
possano ricevere la vostra nuova sottochiave::

    $ gpg --send-key [fpr]

.. note:: Supporto ECC in GnuPG

   Tenete presente che se avete intenzione di usare un dispositivo che non
   supporta chiavi ED25519 ECC, allora dovreste usare "nistp256" al posto di
   "ed25519". Più avanti ci sono alcune raccomandazioni per i dispositivi.

Copia di riserva della chiave primaria per gestire il recupero da disastro
--------------------------------------------------------------------------

Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
al fine di effettuare un recupero da disastro.

Il modo migliore per creare una copia fisica della vostra chiave privata è
l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
delle distribuzioni.

Eseguite il seguente comando per creare una copia fisica di riserva della
vostra chiave privata::

    $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt

Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
una penna e scrivete la passphare sul margine del foglio.  **Questo è
caldamente consigliato** perché la copia cartacea è comunque criptata con
la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
momento della creazione di quella copia -- *garantito*.

Mettete la copia cartacea e la passphrase scritta a mano in una busta e
mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
magari in una cassetta di sicurezza in banca.

.. note::

    Probabilmente la vostra stampante non è più quello stupido dispositivo
    connesso alla porta parallela, ma dato che il suo output è comunque
    criptato con la passphrase, eseguire la stampa in un sistema "cloud"
    moderno dovrebbe essere comunque relativamente sicuro.

Copia di riserva di tutta la cartella GnuPG
-------------------------------------------

.. warning::

    **!!!Non saltate questo passo!!!**

Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere
una copia di riserva pronta all'uso. Questo sta su un diverso piano di
prontezza rispetto al recupero da disastro che abbiamo risolto con
``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la
vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.

Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
riferimento alla documentazione della vostra distribuzione per capire come
fare.

Per la passphrase di criptazione, potete usare la stessa della vostra chiave
primaria.

Una volta che il processo di criptazione è finito, reinserite il disco USB ed
assicurativi che venga montato correttamente. Copiate interamente la cartella
``.gnugp`` nel disco criptato::

    $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup

Ora dovreste verificare che tutto continui a funzionare::

    $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]

Se non vedete errori, allora dovreste avere fatto tutto con successo.
Smontate il disco USB, etichettatelo per bene di modo da evitare di
distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà
di tanto in tanto per modificare le identità, aggiungere o revocare
sottochiavi, o firmare le chiavi di altre persone.

Togliete la chiave primaria dalla vostra home
---------------------------------------------

I file che si trovano nella vostra cartella home non sono poi così ben protetti
come potreste pensare. Potrebbero essere letti o trafugati in diversi modi:

- accidentalmente quando fate una rapida copia della cartella home per
  configurare una nuova postazione
- da un amministratore di sistema negligente o malintenzionato
- attraverso copie di riserva insicure
- attraverso malware installato in alcune applicazioni (browser, lettori PDF,
  eccetera)
- attraverso coercizione quando attraversate confini internazionali

Proteggere la vostra chiave con una buona passphare aiuta notevolmente a
ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte
attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi,
nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra
cartella home e la si archivia su un dispositivo disconnesso.

.. warning::

    Per favore, fate riferimento alla sezione precedente e assicuratevi
    di aver fatto una copia di riserva totale della cartella GnuPG. Quello
    che stiamo per fare renderà la vostra chiave inutile se non avete delle
    copie di riserva utilizzabili!

Per prima cosa, identificate il keygrip della vostra chiave primaria::

    $ gpg --with-keygrip --list-key [fpr]

L'output assomiglierà a questo::

    pub   ed25519 2022-12-20 [SC] [expires: 2022-12-19]
          000000000000000000000000AAAABBBBCCCCDDDD
          Keygrip = 1111000000000000000000000000000000000000
    uid           [ultimate] Alice Dev <[email protected]>
    sub   cv25519 2022-12-20 [E] [expires: 2022-12-19]
          Keygrip = 2222000000000000000000000000000000000000
    sub   ed25519 2022-12-20 [S]
          Keygrip = 3333000000000000000000000000000000000000

Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto
all'impronta digitale della chiave primaria). Questo corrisponderà direttamente
ad un file nella cartella ``~/.gnupg``::

    $ cd ~/.gnupg/private-keys-v1.d
    $ ls
    1111000000000000000000000000000000000000.key
    2222000000000000000000000000000000000000.key
    3333000000000000000000000000000000000000.key

Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
della chiave primaria::

    $ cd ~/.gnupg/private-keys-v1.d
    $ rm 1111000000000000000000000000000000000000.key

Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave
primaria non compare più (il simbolo ``#`` indica che non è disponibile)::

    $ gpg --list-secret-keys
    sec#  ed25519 2022-12-20 [SC] [expires: 2024-12-19]
          000000000000000000000000AAAABBBBCCCCDDDD
    uid           [ultimate] Alice Dev <[email protected]>
    ssb   cv25519 2022-12-20 [E] [expires: 2024-12-19]
    ssb   ed25519 2022-12-20 [S]

Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella
``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG.

Se non avete la cartella "private-keys-v1.d"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre
chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato
da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come
cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire
automaticamente il vecchio formato ``secring.gpg``nel nuovo
``private-keys-v1.d``.

Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``,
che continua a contenere la vostra chiave privata.

.. _it_smartcards:

Smartcard와 offline Certify key 운용

Certify key를 offline으로 옮겨도 [S]와 [E] subkey가 homedir에 남아 있으면 passphrase를 아는 공격자가 서명을 위조하거나 통신을 복호화할 수 있다. GnuPG operation 때 private key가 system memory에 올라오므로 Meltdown과 Spectre 같은 고급 공격으로 memory에서 탈취될 가능성도 고려해야 한다.

smartcard는 private key를 chip 안에 저장하고 암호 연산을 card 자체에서 수행한다. key 내용이 card 밖으로 나오지 않으므로 연결된 computer OS가 private key 자체를 읽을 수 없다. mount 중인 암호화 외장 media에서는 OS가 private key를 읽을 수 있다는 점과 근본적으로 다르다. 암호화 media는 smartcard의 대체재가 아니다.

가격, 지역 배송 가능성, open 또는 proprietary hardware에 대한 요구를 기준으로 선택한다. MAINTAINERS에 등재되었거나 kernel.org 계정이 있는 개발자는 Linux Foundation이 제공하는 무료 Nitrokey Start 대상이 될 수 있다.

• Nitrokey Starthttps://shop.nitrokey.com/shop/product/nitrokey-start-6
• Nitrokey Pro 2https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
• Yubikey 5https://www.yubico.com/product/yubikey-5-overview/
• GnuKhttps://www.fsij.org/doc-gnuk/
• 커널 개발자용 Nitrokey Starthttps://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html

현대 Linux workstation에서는 smartcard USB 장치를 연결하면 보통 바로 인식된다. gpg --card-status로 card 세부 정보가 표시되는지 확인한다. 인식 실패 원인 분석은 장치와 배포판별 지원 문서를 따른다.

$ gpg --card-status

$ gpg --card-edit
[...omitted...]
gpg/card> admin
Admin commands are allowed
gpg/card> passwd

card menu에서 user PIN(1), Admin PIN(3), Reset Code(4)를 설정하고 안전한 장소에 기록한다. 특히 자주 쓰지 않는 Admin PIN과 card를 완전히 초기화할 수 있는 Reset Code를 잊지 않게 보관해야 한다. 이름, 성별, login data 같은 값은 필수가 아니며 card 분실 시 불필요한 개인정보를 노출할 수 있다. PIN이라는 이름과 달리 숫자만 사용할 필요는 없다.

일부 장치는 passphrase를 바꾸기 전에 subkey를 먼저 장치로 옮겨야 할 수 있으므로 제조사 문서를 확인한다. card menu에서 q로 나가 변경을 저장한 뒤, PGP passphrase와 card Admin PIN을 준비하고 key edit menu를 연다.

$ gpg --edit-key [fpr]

Secret subkeys are available.

pub  ed25519/AAAABBBBCCCCDDDD
     created: 2022-12-20  expires: 2024-12-19  usage: SC
     trust: ultimate      validity: ultimate
ssb  cv25519/1111222233334444
     created: 2022-12-20  expires: never       usage: E
ssb  ed25519/5555666677778888
     created: 2017-12-07  expires: never       usage: S
[ultimate] (1). Alice Dev <[email protected]>

gpg>

gpg> menu에서 key 1은 첫 번째 [E] subkey를 선택한다. 출력의 ssb* 별표가 현재 선택된 key를 나타내며 같은 명령을 다시 입력하면 선택이 해제되는 toggle이다. keytocard를 실행하고 Encryption key slot 2를 선택한다. PGP passphrase와 Admin PIN 입력 뒤 오류가 없으면 이전된 것이다.

gpg> key 1
gpg> keytocard
Please select where to store the key:
   (2) Encryption key
Your selection? 2

다음 key를 옮기기 전에 key 1을 다시 입력해 [E] 선택을 반드시 해제하고 key 2로 [S]를 선택한다. [S] key를 Signature와 Authentication에 모두 쓸 수 있어도 이 절차에서는 Signature slot 1에 넣는다.

gpg> key 1
gpg> key 2
gpg> keytocard
Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1

gpg> q
Save changes? (y/N) y

변경을 저장하면 card로 옮긴 private subkey가 homedir에서 삭제된다. 교체 card에 다시 넣어야 할 때는 앞에서 만든 검증된 offline backup을 사용한다.

gpg --list-secret-keys를 다시 실행하면 Certify key는 sec#, card의 subkey는 ssb>로 표시된다. >는 private subkey가 smartcard에만 있다는 뜻이다.

$ gpg --list-secret-keys
sec#  ed25519 2022-12-20 [SC] [expires: 2024-12-19]
      000000000000000000000000AAAABBBBCCCCDDDD
uid           [ultimate] Alice Dev <[email protected]>
ssb>  cv25519 2022-12-20 [E] [expires: 2024-12-19]
ssb>  ed25519 2022-12-20 [S]

private-keys-v1.d의 .key 파일은 실제 key가 아니라 card 위치를 가리키는 stub으로 바뀐다. strings 출력에 shadowed-private-key가 있으면 실제 내용은 smartcard에 있다는 뜻이다.

$ cd ~/.gnupg/private-keys-v1.d
$ strings *.key | grep 'private-key'

실제 서명으로 card 동작을 시험한다. 첫 명령에서 smartcard PIN을 요구하고, verify 결과에 Good signature가 나와야 한다.

$ echo "Hello world" | gpg --clearsign > /tmp/test.asc
$ gpg --verify /tmp/test.asc

Certify 작업을 시작할 때 암호화된 offline storage를 mount하고 GNUPGHOME을 그 백업 디렉터리로 지정한다. gpg --list-secret-keys에서 sec#가 아니라 sec가 표시되어 실제 Certify private key를 읽고 있는지 확인한다.

$ export GNUPGHOME=/media/disk/foo/gnupg-backup
$ gpg --list-secret-keys

Certify key의 기본 만료 기간은 생성 후 2년이다. 키가 무기한 유효하지 않게 하는 보안 목적과, 사용하지 않는 key가 keyserver에서 결국 사라지게 하는 목적이 있다. 현재 날짜에서 1년 연장하거나 기억하기 쉬운 특정 날짜를 지정할 수 있다.

$ gpg --quick-set-expire [fpr] 1y
$ gpg --quick-set-expire [fpr] 2025-07-01
$ gpg --send-key [fpr]

변경한 public key를 keyserver로 다시 보낸다. offline storage에서 변경한 내용을 평소 working keyring으로 export/import한 뒤 GNUPGHOME을 해제한다.

$ gpg --export | gpg --homedir ~/.gnupg --import
$ unset GNUPGHOME

원격 system에서 tag나 commit을 서명해야 한다면 gpg-agent를 SSH로 forwarding할 수 있다. 원격 sshd 설정을 수정할 수 있을 때 더 원활하며, 구체적인 socket forwarding 절차는 GnuPG wiki를 따른다.

• Agent Forwarding over SSHhttps://wiki.gnupg.org/AgentForwarding

Spostare le sottochiavi in un apposito dispositivo criptato
===========================================================

Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete,
le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca
a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre
comunicazioni o a falsificare le vostre firme (se conoscono la passphrase).
Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
malware sofisticati (pensate a Meltdown e a Spectre).

Il miglior modo per proteggere le proprie chiave è di spostarle su un
dispositivo specializzato in grado di effettuare operazioni smartcard.

I benefici di una smartcard
---------------------------

Una smartcard contiene un chip crittografico che è capace di immagazzinare
le chiavi private ed effettuare operazioni crittografiche direttamente sulla
carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
operativo usato sul computer non sarà in grado di accedere alle chiavi.
Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
montato, il sistema operativo potrà accedere al contenuto delle chiavi private.

L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
capace di operazioni di tipo smartcard.

Dispositivi smartcard disponibili
---------------------------------

A meno che tutti i vostri computer dispongano di lettori smartcard, il modo
più semplice è equipaggiarsi di un dispositivo USB specializzato che
implementi le funzionalità delle smartcard.  Sul mercato ci sono diverse
soluzioni disponibili:

- `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
  `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
  ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
  alla manomissione o alcuni attacchi ad un canale laterale).
- `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla
  manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
  crittografia ECC (NISTP).
- `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
  della  Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
  computer portatili più recenti. In aggiunta, offre altre funzionalità di
  sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP)

La vostra scelta dipenderà dal costo, la disponibilità nella vostra regione, e
sulla scelta fra dispositivi aperti e proprietari.

.. note::

    Se siete nella lista MAINTAINERS o avete un profilo su kernel.org, allora
    `potrete avere gratuitamente una Nitrokey Start`_ grazie alla fondazione
    Linux.

.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
.. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/
.. _Gnuk: https://www.fsij.org/doc-gnuk/
.. _`potrete avere gratuitamente una Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html

Configurare il vostro dispositivo smartcard
-------------------------------------------

Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena
lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo
eseguendo::

    $ gpg --card-status

Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente,
affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare
non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta
con GnuPG, cercate aiuto attraverso i soliti canali di supporto.

Per configurare la vostra smartcard, dato che non c'è una via facile dalla
riga di comando, dovrete usate il menu di GnuPG::

    $ gpg --card-edit
    [...omitted...]
    gpg/card> admin
    Admin commands are allowed
    gpg/card> passwd

Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il
codice di reset (4). Assicuratevi di annotare e salvare questi codici in un
posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset
(che vi permetterà di azzerare completamente la smartcard).  Il PIN
dell'amministratore viene usato così raramente che è inevitabile dimenticarselo
se non lo si annota.

Tornando al nostro menu, potete impostare anche altri valori (come il nome,
il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.

.. note::

    A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore
    devono essere esclusivamente numerici.

.. warning::

    Alcuni dispositivi richiedono la presenza delle sottochiavi nel dispositivo
    stesso prima che possiate cambiare la passphare. Verificate la
    documentazione del produttore.

Spostare le sottochiavi sulla smartcard
---------------------------------------

Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo
tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni
vi serviranno sia la passphrase della chiave PGP che il PIN
dell'amministratore::

    $ gpg --edit-key [fpr]

    Secret subkeys are available.

    pub  ed25519/AAAABBBBCCCCDDDD
         created: 2022-12-20  expires: 2024-12-19  usage: SC
         trust: ultimate      validity: ultimate
    ssb  cv25519/1111222233334444
         created: 2022-12-20  expires: never       usage: E
    ssb  ed25519/5555666677778888
         created: 2017-12-07  expires: never       usage: S
    [ultimate] (1). Alice Dev <[email protected]>

    gpg>

Usando ``--edit-key`` si tornerà alla modalità menu e noterete che
la lista delle chiavi è leggermente diversa. Da questo momento in poi,
tutti i comandi saranno eseguiti nella modalità menu, come indicato
da ``gpg>``.

Per prima cosa, selezioniamo la chiave che verrà messa sulla carta --
potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave
**[E]**)::

    gpg> key 1

Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo
``*`` indica che la chiave è stata "selezionata". Funziona come un
interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirà
e la chiave non sarà più selezionata.

Ora, spostiamo la chiave sulla smartcard::

    gpg> keytocard
    Please select where to store the key:
       (2) Encryption key
    Your selection? 2

Dato che è la nostra chiave  **[E]**, ha senso metterla nella sezione criptata.
Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra
chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza
errori, allora la vostra chiave è stata spostata con successo.

**Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave
e selezionate la seconda chiave **[S]** con ``key 2``::

    gpg> key 1
    gpg> key 2
    gpg> keytocard
    Please select where to store the key:
       (1) Signature key
       (3) Authentication key
    Your selection? 1

Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo
che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il
comando ritorna senza errori, allora l'operazione è avvenuta con successo::

    gpg> q
    Save changes? (y/N) y

Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi
che avete spostato sulla carta (ma questo non è un problema, perché abbiamo
fatto delle copie di sicurezza nel caso in cui dovessimo configurare una
nuova smartcard).

Verificare che le chiavi siano state spostate
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una
sottile differenza nell'output::

    $ gpg --list-secret-keys
    sec#  ed25519 2022-12-20 [SC] [expires: 2024-12-19]
          000000000000000000000000AAAABBBBCCCCDDDD
    uid           [ultimate] Alice Dev <[email protected]>
    ssb>  cv25519 2022-12-20 [E] [expires: 2024-12-19]
    ssb>  ed25519 2022-12-20 [S]

Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo
nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e
guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti
con degli stub::

    $ cd ~/.gnupg/private-keys-v1.d
    $ strings *.key | grep 'private-key'

Per indicare che i file sono solo degli stub e che in realtà il contenuto è
sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``.

Verificare che la smartcard funzioni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Per verificare che la smartcard funzioni come dovuto, potete creare
una firma::

    $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
    $ gpg --verify /tmp/test.asc

Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe
mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``.

Complimenti, siete riusciti a rendere estremamente difficile il furto della
vostra identità digitale di sviluppatore.

Altre operazioni possibili con GnuPG
------------------------------------

Segue un breve accenno ad alcune delle operazioni più comuni che dovrete
fare con le vostre chiavi PGP.

Montare il disco con la chiave primaria
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno,
per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di
usarli::

    $ export GNUPGHOME=/media/disk/foo/gnupg-backup
    $ gpg --list-secret-keys

Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma
(il simbolo ``#`` significa che la chiave non è disponibile e che state ancora
utilizzando la vostra solita cartella di lavoro).

Estendere la data di scadenza di una chiave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

La chiave principale ha una data di scadenza di 2 anni dal momento della sua
creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi
che, eventualmente, dovessero sparire dai keyserver.

Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave,
eseguite::

    $ gpg --quick-set-expire [fpr] 1y

Se per voi è più facile da memorizzare, potete anche utilizzare una data
specifica (per esempio, il vostro compleanno o capodanno)::

    $ gpg --quick-set-expire [fpr] 2025-07-01

Ricordatevi di inviare l'aggiornamento ai keyserver::

    $ gpg --send-key [fpr]

Aggiornare la vostra cartella di lavoro dopo ogni modifica
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte,
dovreste importarle nella vostra cartella di lavoro abituale::

    $ gpg --export | gpg --homedir ~/.gnupg --import
    $ unset GNUPGHOME

Usare gpg-agent con ssh
~~~~~~~~~~~~~~~~~~~~~~~

Se dovete firmare tag o commit su un sistema remoto, potete ridirezionare il
vostro gpg-agent attraverso ssh. Consultate le istruzioni disponibili nella wiki
GnuPG:

- `Agent Forwarding over SSH`_

Funziona senza troppi intoppi se avete la possibilità di modificare le
impostazioni di sshd sul sistema remoto.

.. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding

.. _it_pgp_with_git:

Git tag, commit과 patch 서명

Git 저장소를 clone하면 tag, commit, branch를 포함한 전체 history가 로컬에 생긴다. 여러 곳에 복제된 linux.git 가운데 어떤 사본이 악의적으로 바뀌지 않았는지, commit Author에 자신의 이름을 넣은 코드가 실제 자신이 만든 것인지 확인하려면 별도 암호학적 증거가 필요하다.

signed tag는 그 tag가 가리키는 repository 내용이 tag를 만든 개발자의 workstation과 동일하다는 무결성 기준점을 제공한다. signed commit은 공격자가 private key 없이 개발자를 사칭하기 어렵게 한다.

secret key가 하나뿐이면 기본 key로 선택된다. 여러 key가 있다면 Git이 사용할 fingerprint를 전역 설정한다.

$ git config --global user.signingKey [fpr]

$ git tag -s [tagname]

다른 개발자가 pull할 repository의 변조 여부를 확인할 수 있도록 모든 Git tag에 서명하는 것을 권장한다. tag는 git verify-tag로 직접 검증한다. 다른 fork에서 tag를 pull하면 Git은 merge 과정에서 tip의 signature를 자동 검증하고 결과를 merge message에 넣는다.

$ git verify-tag [tagname]
$ git pull [url] tags/sometag

Merge tag 'sometag' of [url]

[Tag message]

# gpg: Signature made [...]
# gpg: Good signature from [...]

다른 사람의 tag를 검증하려면 먼저 그 개발자의 public key를 가져와 identity를 검증해야 한다. annotated tag를 항상 서명하도록 강제하려면 tag.forceSignAnnotated를 설정한다.

$ git config --global tag.forceSignAnnotated true

커널 개발 workflow에서는 commit을 patch로 변환해 mailing list로 보내는데, 이 변환은 Git commit signature를 보존하지 않는다. upstream을 기준으로 rebase해도 기존 commit object가 새로 생성되어 서명이 사라진다. 이 때문에 많은 커널 개발자는 commit signing을 필수로 보지 않고 외부 저장소의 signed commit도 workflow 증거로 사용하지 않는다.

그럼에도 kernel.org, infradead.org, ozlabs.org 같은 공개 hosting에 working tree를 제공한다면 모든 commit에 서명할 것을 권장한다. 훗날 code provenance와 forensic 분석이 필요할 때 외부 tree의 signature도 증거가 되며, system 재설치 후 다시 clone한 저장소 무결성을 확인할 수 있고, 다른 사람이 cherry-pick 전에 commit을 빠르게 검증할 수 있다.

# 한 commit 서명: 소문자 -s와 다른 옵션이므로 대문자 -S
$ git commit -S

# 모든 commit 자동 서명
$ git config --global commit.gpgSign true

자동 commit signing을 켜기 전에 gpg-agent의 passphrase cache와 smartcard 동작을 먼저 구성한다.

커널 mailing list로 보내는 patch도 PGP key로 서명할 수 있다. PGP-MIME이나 PGP-inline은 일반 code review와 patch 적용을 방해할 수 있으므로, kernel.org가 만든 patatt를 이용해 DKIM과 비슷한 cryptographic attestation을 message header에 넣는다.

먼저 배포판에서 patatt package를 찾고, 없다면 PyPI의 `pip install patatt`로 설치한다. Git `user.signingKey`가 이미 설정되어 있다면 별도 key 설정 없이 repository에 git-send-email hook을 설치할 수 있다.

pip install patatt

patatt install-hook

이후 git send-email로 보내는 patch에는 자동으로 cryptographic signature가 붙는다. b4로 patch를 가져와 적용하면 발견한 DKIM과 patatt signature를 자동으로 검증한다.

$ b4 am [email protected]
[...]
Checking attestation on all messages, may take a moment...
---
  [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
  [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
  [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
  ---
  Signed: openpgp/[email protected]
  Signed: DKIM/kernel.org

patatt와 b4는 계속 개발되고 있으므로 현재 project 문서에서 새 기능과 변경된 사용법을 확인한다.

• Patatt Patch Attestationhttps://pypi.org/project/patatt/

Usare PGP con Git
=================

Una delle caratteristiche fondanti di Git è la sua natura decentralizzata --
una volta che il repositorio è stato clonato sul vostro sistema, avete la
storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
con i centinaia di repositori clonati che ci sono in giro, come si fa a
verificare che la loro copia di linux.git non è stata manomessa da qualcuno?

Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
"Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
`non averci niente a che fare`_?

Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
I tag firmati dimostrano che il repositorio è integro assicurando che il suo
contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno
creato il tag; mentre i commit firmati rendono praticamente impossibile
ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi
PGP.

.. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else

Configurare git per usare la vostra chiave PGP
----------------------------------------------

Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla
da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste
avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]``
è la vostra impronta digitale)::

    $ git config --global user.signingKey [fpr]

Come firmare i tag
------------------

Per creare un tag firmato, passate l'opzione ``-s`` al comando tag::

    $ git tag -s [tagname]

La nostra raccomandazione è quella di firmare sempre i tag git, perché
questo permette agli altri sviluppatori di verificare che il repositorio
git dal quale stanno prendendo il codice non è stato alterato intenzionalmente.

Come verificare i tag firmati
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Per verificare un tag firmato, potete usare il comando ``verify-tag``::

    $ git verify-tag [tagname]

Se state prendendo un tag da un fork del repositorio del progetto, git
dovrebbe verificare automaticamente la firma di quello che state prendendo
e vi mostrerà il risultato durante l'operazione di merge::

    $ git pull [url] tags/sometag

Il merge conterrà qualcosa di simile::

    Merge tag 'sometag' of [url]

    [Tag message]

    # gpg: Signature made [...]
    # gpg: Good signature from [...]

Se state verificando il tag di qualcun altro, allora dovrete importare
la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
che troverete più avanti.

Configurare git per firmare sempre i tag con annotazione
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Se state creando un tag con annotazione è molto probabile che vogliate
firmarlo. Per imporre a git di firmare sempre un tag con annotazione,
dovete impostare la seguente opzione globale::

    $ git config --global tag.forceSignAnnotated true

Come usare commit firmati
-------------------------

Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
nello sviluppo del kernel linux per via del fatto che ci si affida alle
liste di discussione e questo modo di procedere non mantiene le firme PGP
nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
Per questo motivo, la maggior parte degli sviluppatori del kernel non si
preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
che si trovano in altri repositori usati per il proprio lavoro.

Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
o altri), allora la raccomandazione è di firmare tutti i vostri commit
anche se gli sviluppatori non ne beneficeranno direttamente.

Vi raccomandiamo di farlo per i seguenti motivi:

1. Se dovesse mai esserci la necessità di fare delle analisi forensi o
   tracciare la provenienza di un codice, anche sorgenti mantenuti
   esternamente che hanno firme PGP sui commit avranno un certo valore a
   questo scopo.
2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
   esempio dopo un danneggiamento del disco), la firma vi permetterà di
   verificare l'integrità del repositorio prima di riprendere il lavoro.
3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
   permetterà di verificare l'integrità dei commit prima di applicarli.

Creare commit firmati
~~~~~~~~~~~~~~~~~~~~~

Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
al comando ``git commit`` (si usa la lettera maiuscola per evitare
conflitti con un'altra opzione)::

    $ git commit -S

Configurare git per firmare sempre i commit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Potete dire a git di firmare sempre i commit::

    git config --global commit.gpgSign true

.. note::

    Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare
    questa opzione.

.. _it_verify_identities:

Come lavorare con patch firmate
-------------------------------

Esiste la possibilità di usare la vostra chiave PGP per firmare le patch che
invierete alla liste di discussione del kernel. I meccanismi esistenti per la
firma delle email (PGP-Mime o PGP-inline) tendono a causare problemi
nell'attività di revisione del codice. Si suggerisce, invece, di utilizare lo
strumento sviluppato da kernel.org che mette nell'intestazione del messaggio
un'attestazione delle firme crittografiche (tipo DKIM):

- `Patatt Patch Attestation`_

.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/

Installare e configurate patatt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lo strumento patatt è disponibile per diverse distribuzioni, dunque cercatelo
prima lì. Oppure potete installarlo usano pypi "``pip install patatt``"

Se avete già configurato git con la vostra chiave PGP (usando
``user.signingKey``), allora patatt non ha bisogno di alcuna configurazione
aggiuntiva. Potete iniziare a firmare le vostre patch aggiungendo un aggancio a
git-send-email nel vostro repositorio::

    patatt install-hook

Ora, qualsiasi patch che invierete con ``git send-email`` verrà automaticamente
firmata usando la vostra firma crittografica.

Verificare le firme di patatt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Se usate ``b4`` per verificare ed applicare le patch, allora tenterà
automaticamente di verificare tutte le firme DKIM e patatt disponibili. Per
esempio::

    $ b4 am [email protected]
    [...]
    Checking attestation on all messages, may take a moment...
    ---
      ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
      ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
      ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
      ---
      ✓ Signed: openpgp/[email protected]
      ✓ Signed: DKIM/kernel.org

.. note::

   Lo sviluppo di patatt e b4 è piuttosto attivo. Si consiglia di verificare la
   documentazione più recente.

.. _it_kernel_identities:

개발자 identity와 trust 검증

서명이 수학적으로 유효하다는 사실만으로 그 key가 실제 커널 개발자의 것임을 증명할 수는 없다. 공격자가 같은 이름과 이메일로 새 key를 만들 수 있으므로, public key 획득 경로와 identity binding을 검증해야 한다.

다른 개발자 public key collection이 충분하지 않다면 GnuPG의 자동 발견을 이용할 수 있다. WKD와 DANE는 각각 TLS와 DNSSEC이라는 위임된 신뢰 기술을 통해 public key를 찾고 가져온다.

# ~/.gnupg/gpg.conf
auto-key-locate wkd,dane,local
auto-key-retrieve

DANE는 public key를 DNS에 게시하고 DNSSEC-signed zone으로 보호한다. WKD는 HTTPS 조회를 사용한다. GnuPG는 자동으로 가져온 key를 local keyring에 추가하기 전에 DANE에서는 DNSSEC을, WKD에서는 TLS certificate를 검증한다.

kernel.org는 계정이 있는 모든 개발자의 WKD를 게시한다. 설정 뒤 Linus Torvalds와 Greg Kroah-Hartman의 key를 이메일 주소로 찾을 수 있다. kernel.org 계정이 있다면 자신의 key에 kernel.org UID를 추가해 다른 개발자의 WKD 검색을 돕는다.

$ gpg --locate-keys [email protected] [email protected]

• kernel.org UID 추가https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key

PGP의 Web of Trust는 HTTPS/TLS의 중앙 Certification Authority를 대신하려는 분산 trust delegation 방식이다. software vendor가 신뢰할 인증자를 정하는 대신 각 사용자가 누구의 인증을 신뢰할지 결정한다.

Web of Trust의 실제 운용은 이해하기 어렵다. GnuPG 2.2 이상은 대안으로 Trust on First Use를 제공한다. SSH가 첫 연결의 host key fingerprint를 기억하고 이후 변경을 경고하듯, TOFU는 처음 가져온 identity-key 연결을 기록한다.

나중에 같은 identity를 가진 다른 key가 나타나면 기존 key와 새 key를 모두 검증 대상으로 표시하고 사용자가 어느 것을 유지할지 판단하게 한다. 문서는 GnuPG v2의 새 기본값인 TOFU+PGP 결합 trust model을 권장한다.

# ~/.gnupg/gpg.conf
trust-model tofu+pgp

기존 복제형 keyserver network가 최근 수년 동안 대부분 제대로 동작하지 않게 되자 kernel.org는 개발자 public key를 모은 Git repository를 운영한다. 이 저장소를 public key source로 구성하는 전체 절차는 Kernel developer PGP Keyring 문서에 있다.

커널 개발자라면 다른 개발자가 자신의 서명을 검증할 수 있도록 해당 keyring에 public key를 제출하는 것을 검토한다.

• Kernel developer PGP Keyringhttps://korg.docs.kernel.org/pgpkeys.html

Come verificare l'identità degli sviluppatori del kernel
========================================================

Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
impostore?

Configurare l'auto-key-retrieval usando WKD e DANE
--------------------------------------------------

Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche
di altri sviluppatori, allora potreste iniziare il vostro portachiavi
affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi
ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi
nel caso in cui iniziare una propria rete di fiducia da zero sia troppo
scoraggiante.

Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``::

    auto-key-locate wkd,dane,local
    auto-key-retrieve

La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo
per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando
zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo
alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD
per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS
prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate.

Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account
kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``,
potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman
(se non le avete già)::

    $ gpg --locate-keys [email protected] [email protected]

Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
chiave lo UID di kernel.org`_.

.. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key

Web of Trust (WOT) o Trust on First Use (TOFU)
----------------------------------------------

PGP incorpora un meccanismo di delega della fiducia conosciuto come
"Web of Trust". Di base, questo è un tentativo di sostituire la necessità
di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS.
Invece di avere svariati produttori software che decidono chi dovrebbero
essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
la responsabilità ad ogni singolo utente.

Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
"ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
connettete ad un sistema remoto, l'impronta digitale della chiave viene
registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma
SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità,
entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
verificare manualmente quale tenere.

Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
``trust-model`` in ``~/.gnupg/gpg.conf``::

    trust-model tofu+pgp

Usare il repositorio kernel.org per il web of trust
---------------------------------------------------

Il progetto kernel.org mantiene un repositorio git con le chiavi pubbliche degli sviluppatori in alternativa alla replica dei server di chiavi che negli ultimi anni sono spariti. La documentazione completa su come impostare il repositorio come vostra sorgente di chiavi pubbliche può essere trovato qui:

- `Kernel developer PGP Keyring`_

Se siete uno sviluppatore del kernel, per favore valutate l'idea di inviare la
vostra chiave per l'inclusione in quel portachiavi.


If you are a kernel developer, please consider submitting your key for
inclusion into that keyring.

.. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.html