Je kunt natuurlijk met GnuPG eerst de keys in een folder op een USB creëeren (om deze later in een kluis te bewaren), en vervolgens inlezen in de key-ring op de laptop zelf.

Maak eerst een ASCII-armored backup van de secret keys. Dat kan met de GnuPG commandline opties --export-secret-keys plus --amor. De verkregen output brand of print je vervolgens op een tweetal Verbatim CD-ROMs of papier van een hoge archiefwaardige kwaliteit. Er is onder Linux ook een paperkey utility als een .deb of .rpm package beschikbaar.

Wat je ook kan doen is een fatsoenlijke email provider proberen, zoals https://posteo.de/en, dan ben je niet zelf aan het aanklooien maar je kan ook thunderbird gebruiken inclusief een calender. Oké, die kost wel wat maar die paar centen per jaar haal je er zo uit.

Je kan een sleutel ook binnen de TPM genereren, dan wordt die dus niet eerst op je hardeschijf opgeslagen.

Dan wordt het mogelijk interessant om te kijken naar subkeys. Waarbij je 1 hoofdsleutel online ergens bewaard en in normale omstandigheden gebruik maakt van de sleutel in de TPM.

Maar de bedoeling is natuurlijk dat de PGP sleutel alleen in de trusted platform module zit. Als je daarnaast nog ergens een kopie hebt van de secret key, doet dat het principe van een TPM een beetje teniet voor mij.

TS

De eerste alinea van de blogpost waar je naar linkte legt uit hoe het zit.

Wat jij stelt, dat een kopie van een privésleutel het principe van een TPM teniet doet, gaat alleen op als je een cryptografische toepassing hebt waarvan het uitdrukkelijk de bedoeling is dat die aan specifieke hardware gebonden is. Dat zal bij PGP meestal niet opgaan; of oude e-mails bijvoorbeeld nog relevant zijn hangt niet af van de vraag of je nog dezelfde of inmiddels een andere laptop gebruikt. Zelf zou ik absoluut de sleutel niet samen met de hardware kwijt willen raken.

Waar men de TPM dan ook voor gebruikt is om te zorgen dat de sleutel veilig is op de laptop, zowel in rust als in gebruik. Dat je de sleutel ook nog in de kluis hebt liggen om hem op een andere laptop te kunnen installeren verandert niets aan het feit dat je de kopie van de sleutel op de laptop die je in gebruik hebt met een TPM een extra beveiliging heeft die je zonder de TPM niet hebt.

Wat 07:38 Anoniem zegt, gebruik maken van subkeys kan complementair goed werken.

Als de TPM chip kapot geraakt ben je alles kwijt, dat lijkt me geen goed idee.

De opmerking dat geheime sleutels nooit uit de TPM module (of bv. uit een HSM) mogen komen is niet correct. Dit is afhankelijk van het doel van die sleutel:
- voor identificatie (ik ben die ik ben) accepteer je dat een sleutel verloren kan gaan doordat de kluis (TPM, HSM) defect is, je kan dan bv. het bijbehorende certificaat revoken en een nieuwe aanvragen. Vanaf dat moment geld alleen de nieuwe. Zo'n sleutel kan je in een HSM of TPM genereren
- voor ontsleutelen van berichten accepteer je dat niet: je wilt toegang houden tot versleutelde berichten en je zorgt er daarom voor dat je altijd ergens een backup hebt, in bv. een HSM, of versleuteld onder een HSM key. Desnoods als een afgedrukte key die je ergens in een fysieke kluis opslaat.
De enige uitzondering is als het versleutelde bericht zo belangrijk is dat je liever hebt dat niemand (ook jezelf) het kan lezen als er iets met de sleutel fout gaat. Maar voor normaal gebruik niet relevant

Q

Een tussenvorm tussen alleen op de TPM en een backup in een kluis, kan een revocation certificate zijn voor je PGP sleutel. Dan revoke je een oude encryption subkey en maak je een nieuwe aan die je opnieuw in de TPM zet. Zo blijft je hoofdsleutel geldig als je TPM chip niet meer werkt.

https://gnupg.org/gph/en/manual.html#REVOCATION

Dit lost echter niet het probleem op dat je secret keys tijdelijk op de harddisk komen te staan. Met alleen het wachtwoord als bescherming en niet het principe van de TPM dat wat erin zit, er niet meer uitgehaald kan worden.

Dank voor alle reacties,
TS

Leuk uit de crypto gereedschapskist , en soms nuttig als recovery optie : Shamir Secret Sharing.

Een geheim verdelen tussen over een aantal mensen, zodanig dat die reconstrueerbaar is met n-uit-m van de deelnemers.

En daarbij *NIET* reconstrueerbaar als er te weinig mensen hun 'deel' inleveren - ook niet met veel rekenwerk.
(als je tien delen voor reconstructie nodig hebt , is het ook met 9 beschikbaar nog steeds erg onmogelijk om het secret te reconstrueren)

https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

Er zijn wat programma's voor .

Zo kun je een masterkey verspreid bewaren, en bij verlies/ontdekking van een enkel deel is er nog niks aan de hand.

Dit is een complexe, waarbij je bv. een sleutel kan herstellen die je over meerdere mensen hebt verdeeld zonder dat je ze allemaal nodig hebt (bv. 3 man nodig van de 5 aan wie je oorspronkelijk een deel hebt gegeven). Best leuke Crypto.

Wat vroeger veel gebruikt werd is een splitsing in 3 waarbij je wel alle drie de delen nodig hebt.
Methode: stel je hebt een 256bit sleutel K1. Dan genereer je twee 256bit random nummers R1 en R2, doet achtereenvolgens een XOR tussen K1 en R1 tot KR1, en dan KR1 met R2 tot KR12 waarbij KR12 ook 256bit is.
De bewaarders van het geheim (key Custodians C1, C2 en C3) geef je R1, R2 en KR12. Niemand kan iets met zijn losse deel, maar alleen als alle drie bij elkaar komen en weer alles XORen krijg je de sleutel terug
Dat XOR-en laat je normaal binnen een HSM gebeuren zodat de plain key K1 nergens gekopieerd kan worden. Hierbij worden R1, R2 en KR12 op een eigen smartcard opgeslagen met PIN code.
Het enige probleem is dat als één van de custodians z'n deel verliest (of zijn/haar PIN) de oorspronkelijke K1 nooit meer terug te halen is. En daar zijn dan weer hele procedures voor om of met backup custodians te werken of via allerlei andere 4-eyes processen

Leuke dingen!

Q

Ik heb mindere ervaringen met Verbatim maar dat zal wel aan mij liggen