O dia em que (quase) perdir a minhas chaves
Todos fazemos backups (certo)? Mas quantos de nós é que os testa depois? Uma história de como um falso teste nos pode enganar.
Era uma vez, em que eu fiz asneira com as minhas chaves GPG. Eis como tudo aconteceu.
Existem várias formas de gerir chaves GPG, desde gerar e usar até algo mais complexo.
Eu gosto da teoria do cada macaco no seu lugar, dai ter quatro par de chaves. A chave de certificação fica numa máquina offline enquanto as outras vão para a minha NitroKey (NK).
Como tenho que renovar as chaves a cada seis meses, já tenho o processo delineado:
- Renovar
- Backup
- Mover as chaves para a NK
- Restaurar o backup
Até aqui parece bater tudo bem certo? Para mim também, e até “testava” o backup no último passo, mas a forma como o fazia é que não é a ideial, isto porque na realidade, não testava se as chaves privada eram ou não restauradas.
Da última vez que renovei as chaves, tudo correu de acordo com o plano, até que tive que fazer SSH para uma máquina. O primeiro pensamento foi que fiz algo de errado no terceiro passo, então voltei para a máquina offline e fiquei surpreendido, as minhas chaves privadas não estavam lá. Paniquei durante um bocado mas depois pensei, “OK, sem stress. Faço login com a conta de backup e instalo uma chave nova.” Ora bem, querem adivinhar quem encriptou o acesso da conta de backup?
Pois, naquele momento tive aquele arrepio na espinha, pois perdi acesso a tudo, incluíndo passwords e backups.
O meu pensamento foi, “OK, vamos andar para trás nos backups, só preciso que um tenha as chaves privadas.” E lá estava ele, o primeiro deles todos. Copiei as chaves para a NK e voilá, voltei a ter acesso a tudo.
Depois deste episódio, revogei as agora apenas chaves públicas e criei umas novas e publiquei-as no keys.openpgp.org .
E agora, antes de as mover para a NK, restauro sempre o backup e verifico se todas as chaves estão lá, não vá o diabo tecelas.
Por isso lembrem-se crianças, um backup não testado não é um backup!