git을 쓰다보면 신원 증명을 위해서 gpg key를 만들어야 하는데 개인용, 회사용 분리 등 관리를 잘 하고 싶었다. 회사를 옮기거나 키가 만료 됐을 때만 관리하면 되는데, 이 때마다 보면서 참고할만한 문서가 없어 매번 찾아다니는게 귀찮아서 직접 정리했다. git과 ssh에 잘 쓰이기만 하면 되기 때문에 원리를 깊게 파보진 않았고, 때문에 틀린 내용도 포함되어있을 것 같다.
암/복호화 활용
문서 목적이 내가 나중에 키 관리할 때 사용하는 것이기 때문에 간단하게만 설명하겠다.
git에서 GPG의 암/복호화 활용은 두가지 인데, 당연히 첫째는 내용을 숨기는것이고 둘째는 서명을 확인하는것이다. 첫째는 당연하니 넘어가고, Github web에서 Verified/Unverified 표시를 해주는것이 둘째 목적이다.
커밋에는 작성자에 대한 정보를 (이름, 이메일 등) 같이 기록하는데, Verified 표시를 누르면 나오는 This commit was signed with the committer’s verified signature. 처럼 다른 사람이 사칭한게 아니라 진짜 그 사람이 작성했다고 확인하는 것이다. 이게 없으면, 내가 악성 코드를 Linus Torvalds라는 이름과 커밋으로 만들어서 Linux git에 patch를 올렸을 때 사람들이 이름만 믿고 반영해 줄 수도 있는거다.
핵심에는 비대칭키가 있는데, 비밀키와 공개키가 쌍으로 있을 때
- 비밀키로 암호화된 내용은 매칭되는 공개키로만 복호화할 수 있다.
- 공개키로 암호화된 내용은 매칭되는 암호키로만 복호화할 수 있다.
신원 확인은 전자를 사용하고, Github 설정에서 GPG 공개키를 등록하는 이유도 이것 때문이다. 내 비밀키에 매칭되는 공개키는 Github이 이미 알고있기 때문에 Github은 내 비밀키로 암호화된 커밋만 복호화할 수 있다. 즉, 다른 누군가가 커밋에 내 이름을 써놓고 자신의 비밀키를 사용해서 push했을 때는 Github이 알고있는 내 공개키로는 복호화가 불가능하기 때문에 위조됐다는 것을 알아챌 수 있다.
이 모든것은 비밀키를 본인만 안전하게 가지고있다는 전제하에 성립하며, 이걸 위해서 안전하게 비밀키를 보관하려는 것이다.
용어
Keyring
GPG에서는 여러 key를 묶어놓은 집합을 Keyring이라고 한다. 여기에는 자신의 key뿐 아니라 다른 사람의 (public) key 또한 포함될 수 있다.
Master key
Certification key 혹은 Master secret key라고도 불리며 이름처럼 다른 모든 관리하는 역할이다.
Keyring에는 여러 key가 있다고 했는데, 각 key는 반드시 master key이거나 sub key이다. Master key와 subkey들은 1:N 관계라서, 각 subkey들은 하나의 master key에 의해 만들어진다. Subkey 추가/삭제/변경은 꼭 master key가 있어야만 가능하므로 가장 중요하고 안전하게 지켜야한다.
Key usage flag
각 key마다 역할을 다르게 부여할 수 있는데 그게 usage flag이다.
gpg --list-secret-keys를 실행했을 때 [SC] 혹은 [E] 같은게 보일탠데, 해당 라인 key의 flag를 의미한다. gpg에서는 key에 할당된 flag를 가지고 아래와같이 상황에 따라 서로 다른 key를 사용한다.
C: Certification key. 이 flag를 가지는 key가 master key이다. 때문에 다른 key를 관리할 때 사용된다.S: Signing key. 위의 활용에서 설명한 서명을 위해 쓰이는 key이다.E: Encryption key. 상대방과 주고받을 데이터를 암/복호화 하는데 쓰이는 key이다.A: Authentication key. SSH, TLS에서 인증할 때 사용된다.
만약 C flag가 붙은 master key로 S sub key를 추가로 만들었다면, git을 이용할 때에는 commit에 서명만 가능하면 되기 때문에 C는 전혀 쓰이지 않고 S sub key만 사용한다.
생각해보면 sub key를 추가/삭제/변경할 일보다 commit을 만드는 일이 훨씬 잦다. 또한 C는 master key라는 이름처럼 강력하기 때문에 다른 key와 분리해서 보관하는게 좋다. gpg로 대충 key를 생성하면 C와 S가 하나의 key에 붙는데, 분리해서 하나씩 생성하고 C는 USB나 다른 오프라인 저장소로 옮기고 컴퓨터에서는 삭제하는게 안전하다. (보안이 정말 중요하다면)
Key ID, User ID, Fingerprint
Private key, Public key만 관리하면 되는줄 알았는데 위와같은 이름들이 함께 등장해서 헷갈린다.
예시로 설명하면, gpg --list-keys --keyid-format LONG를 실행했을 때 아래와 같은 출력이 나왔을 경우
pub rsa3072/D0ABFFAB227E9DE6 2020-10-09 [SC] [revoked: 2022-05-14]
3EAD11FD08087F4E754B9782D0ABFFAB227E9DE6
uid [ revoked] Byeonghoon Yoo <bh322yoo@gmail.com>D0ABFFAB227E9DE6가 Key ID, Byeonghoon Yoo <bh322yoo@gmail.com>가 User ID, 3EAD11FD08087F4E754B9782D0ABFFAB227E9DE6가 fingerprint다.
User ID의 경우 gpg의 각종 쿼리에 쓸 수 있는데, bh322yoo@gmail.com나 Byeonghoon Yoo처럼 부분만 입력할 수도 있다.
상황별 명령어
Backup secret key
gpg --export-secret-keys --export-options backup --output secret_key.asc --armor D0ABFFAB227E9DE6만약 master key가 위에서 설명한것처럼 C flag만 있다면 secret_key.asc를 안전하게 보관한다는 가정하에 지우는게 좋다.
맨 뒤에
!는 Key ID 뒤에 꼭 붙여야한다. 이게 있어야 master key 하나만 지우고, 빼먹으면 master key와 함께 모든 sub key를 지워버린다.
gpg --delete-secret-keys D0ABFFAB227E9DE6!Restore secret key
gpg --import-options restore --import secret_key.ascUser ID 추가 (이메일 추가)
User ID (UID)는 Master Key가 관리하기 때문에 추가하려면 Master key가 필요하다. 만약 secret key를 백업하면서 master key를 지웠다면 restore 이후에 아래 명령어를 실행해야한다. (추가 이후에는 backup과 삭제를 다시 해주자)
gpg --quick-adduid CF1251E9D42EF5B9 `some name <some@email.com>`
gpg --update-trustdb부록
PGP vs GPG
- PGP, GPG 모두 암/복호화에 사용되는 프로그램 구현체이다.
- GPG는 GnuPG의 줄임말이다.
- PGP가 Symantec이라는 회사에서 먼저 개발했다.
- PGP는 상용, GnuPG는 무료다.
- PGP가 유용하자 이걸 기반으로한 OpenPGP라는 암/복호화 표준 포맷 만들어졌다.
- GnuPG는 자유 재단인 GNU에서 만들었고, OpenPGP 표준을 따르는 구현체이다.
- PGP, GnuPG 둘 다 표준 포맷을 따르기 때문에 동일한 기능을 할 수 있다.
