image

GnuPG introduceert extra decryptie-subkey voor end-to-end encryptie bij bedrijven

vrijdag 28 april 2023, 15:15 door Redactie, 11 reacties

Het gebruik van end-to-end encryptie binnen groten bedrijven en organisaties kan voor de nodige problemen zorgen, bijvoorbeeld als iemand afwezig is of wanneer gegevens van voormalige medewerkers moeten worden benaderd. De makers van encryptiesoftware GnuPG hebben nu in de nieuwste versie een feature genaamd "Additional Decryption SubKey" (ADSK) geïntroduceerd die hiermee moet helpen.

ADSK moet het gebruik van end-to-end encryptie meer compatibel met standaard bedrijfsprocedures maken. Bij het gebruik van end-to-end encryptie wordt de private (secret) key vaak gedeeld met anderen of op een veilige plek bewaard, aldus de GnuPG-beheerders. Het beheer van dergelijke keys is lastig, foutgevoelig en kan in het ergste geval end-to-end encryptie in een soort van "gateway-gebaseerde" encryptie veranderen. De ADSK-feature zorgt ervoor dat bij het versturen van een versleutelde reply op een e-mail er verschillende subkeys voor de encryptie wordt gebruikt.

Een andere reden om ADSK toe te passen is het "splitten" van keys over verschillende apparaten. "Zo kan het geheime deel van de key voor een smartphone voor extra veiligheid op een token staan, maar bij een desktop staat die op de harde schijf, omdat de desktop waarschijnlijk minder snel gestolen zal worden. De ADSK van een gestolen toestel kan worden ingetrokken en vervolgens kan voor het nieuwe toestel een nieuwe worden gegenereerd", aldus de ontwikkelaars. ADSK is beschikbaar in GnuPG 2.4.1 en is ook voor bestaande keys te gebruiken.

Reacties (11)
28-04-2023, 16:21 door Anoniem
Met andere woorden: een backdoor.
28-04-2023, 16:52 door johanw
Dus ze zijn eindelijk gezwicht. Toen die "feature" geintroduceerd werd was men nog mordiceus tegen.
28-04-2023, 18:21 door Anoniem
Nou het klopt inderdaad wel dat end-to-end mail encryptie binnen bedrijven meestal onwerkbaar is (dit geldt net zo goed voor S/MIME!) omdat de keys gekoppeld zijn aan personen, en personen in bedrijven inwisselbaar zijn.
29-04-2023, 08:28 door beaukey
Door Anoniem: Met andere woorden: een backdoor.

en

Door johanw: Dus ze zijn eindelijk gezwicht. Toen die "feature" geintroduceerd werd was men nog mordiceus tegen.

Als je je eigen sleutel beheer niet op orde hebt, dan is het een risico, en geen backdoor. Een backdoor is iets wat in het product "ingebakken" zit. Een ADSK moet je zelf instellen.
29-04-2023, 21:12 door johanw - Bijgewerkt: 29-04-2023, 21:12
Een adk kan de eigenaar van de key instellen. En ik heb nog geen optie gezien in gpg om adk's te negeren dus voorlopig zie ik het als backdoor.
30-04-2023, 19:58 door johanw - Bijgewerkt: 30-04-2023, 19:58
En ik kreeg op de GnuPG mailinglist de bevestiging van Werer Koch, de hoofdontwikkelaar van GnuG, dat zo'n optie ook niet bestaat en er vorlopig ook niet komt omdat hij er het nut niet van inziet:

> What I'm missing (maybe I just didn't found it?) is an option in my
> config file to ignore adk requests and just don't encrypt to those keys

It does not make any sense so have such an option. If a user wants to
allow colleagues or an archive system to decrypt her mails that is her
decision.

Dat wordt forken, al is die source code vreselijk ingewikkeld opgezet.
30-04-2023, 20:44 door Anoniem
Door johanw: Dat wordt forken, al is die source code vreselijk ingewikkeld opgezet.

Je hoeft maar op een plaats de code te veranderen. En dat is de code die Public-Key Encrypted Session Key Packets genereert https://datatracker.ietf.org/doc/html/rfc4880#section-5.1. De ADSK kan dan per ongeluk een session key bevatten waar een hoop bits van zijn omgevallen.

Niet dat ik het ga doen, ik kan onmogelijk mijn systeem veilig houden tegen TLA. Zelf zal ik gewoon de meest officiële versie blijven gebruiken van Werner Koch.
30-04-2023, 21:17 door Anoniem
Door johanw: En ik kreeg op de GnuPG mailinglist de bevestiging van Werer Koch, de hoofdontwikkelaar van GnuG, dat zo'n optie ook niet bestaat en er vorlopig ook niet komt omdat hij er het nut niet van inziet:

> What I'm missing (maybe I just didn't found it?) is an option in my
> config file to ignore adk requests and just don't encrypt to those keys

It does not make any sense so have such an option. If a user wants to
allow colleagues or an archive system to decrypt her mails that is her
decision.

Dat wordt forken, al is die source code vreselijk ingewikkeld opgezet.


Om eerlijk te zien : ik vind je hier een enorme eigenwijze zeurpiet .

De ontvanger van je bericht zegt expliciet (zichtbaar via de ADSK key) Ik WIL en GA dit bericht delen met deze andere personen - namelijk die andere keys.

En jij gaat dan die boel aan de ontvangstkant vernaggelen door dat toch maar niet te doen ?

Lekker dan : gaat iemand op vakantie (of langdurig ziek), alles geregeld, out of office, collega's in de adsk key, en gaat Ir Wevers weer eigenwijs doen .

In welk scenario weet jij beter dan degene op je antwoord (of van wie je een adsk key hebt) dat je toch 1:1 wilt encrypten ?

Stuur dan gewoon een bericht : "ik ga niet met die andere personen communiceren, ik wil een persoonlijke key van je" .
01-05-2023, 00:20 door Anoniem
Door Anoniem:
Door johanw: Dat wordt forken, al is die source code vreselijk ingewikkeld opgezet.

Je hoeft maar op een plaats de code te veranderen. En dat is de code die Public-Key Encrypted Session Key Packets genereert https://datatracker.ietf.org/doc/html/rfc4880#section-5.1. De ADSK kan dan per ongeluk een session key bevatten waar een hoop bits van zijn omgevallen.

Niet dat ik het ga doen, ik kan onmogelijk mijn systeem veilig houden tegen TLA. Zelf zal ik gewoon de meest officiële versie blijven gebruiken van Werner Koch.

Ik schreef al dat ik johanw's wens niet handig vind.
Het lijkt me wel lelijk om het hele mechanisme te gebruiken en dan alleen in de definitieve sessie output een aantal stromen te verminken.

Mocht hij (of iemand) het toch willen lijkt dit een handvat voor de plaatsen in de code :

https://dev.gnupg.org/rGe4f61df8509e

Overigens :

Met de erg natte en amper gefunderde vinger *denk* ik dat een andere (en misschien handiger) manier om dit te bereiken is het (als) ontvanger van zo'n pubkey editen van de pubkey-met-additional-subkeys , en daarvan die additionele subkeys verwijderen .
Misschien dat het ook een ander type key is , maar het lijkt me mogelijk om van iemands pubkey key+subkeys een "nieuwe" solo-pubkey te maken . (of meerdere. voor de andere subkeys).
Waarschijnlijk verlies je daarin dan wel signatures, maar uiteindelijk - als je die eerst gecontroleerd hebt, en om de één of andere onmogelijke reden _wel_ de eigenaar van een key vertrouwd maar niet diens keuze om wat extra subkeys toe te voegen , dan zie ik geen principiële technische reden waarom je niet in je eigen verzameling van pubkeys van mensen met je wilt corresponderen zo'n adsk key (of een subkey ervan) tot "losse" pubkeys om te vormen.

De 'web-of-trust' validatie moet je dan maar offline gedaan hebben op de key+subkeys zoals die oorspronkelijk beschikbaar waren.

Voordeel lijkt me dat je niet hoeft te roeren in de gpg sources, maar evt alleen een pubkey extract/convert/import script (eenmalig) hoeft te maken. Of te vinden.
01-05-2023, 01:58 door johanw
Door Anoniem:
De ontvanger van je bericht zegt expliciet (zichtbaar via de ADSK key) Ik WIL en GA dit bericht delen met deze andere personen - namelijk die andere keys.

In de praktijk is die adk meestal verplicht toegevoegd door de werkgever, niet door de ontvanger zelf.
01-05-2023, 12:39 door Anoniem
Door johanw:
Door Anoniem:
De ontvanger van je bericht zegt expliciet (zichtbaar via de ADSK key) Ik WIL en GA dit bericht delen met deze andere personen - namelijk die andere keys.

In de praktijk is die adk meestal verplicht toegevoegd door de werkgever, niet door de ontvanger zelf.

Terecht, voor zo'n bedrijfssituatie .
Zakelijk gezien heeft de 'eigenaar' (feitelijk gebruiker, beheerder, operator) van een zakelijke key ook weinig _zelf_ te willen .

Het alternatief is dat "de" zakelijke key gewoon met passphrase en al in een gedeelde share, (of keepass , hoop je) van het team of de ontvanger en z'n backup-collega's staat .

Net als alle privé-zaken : die doe beter in je in eigen tijd met eigen apparatuur , en je werk-gerelateerde zaken doe je op werk devices, met een werk-identiteit (cert@, support@, devs@ ), en deel je met aangewezen vervangers of opvolgers.

Als je de persoon echt privé - zodanig dat je ook gpg nuttig en nodig vindt - wilt benaderen is z'n werk-key (cq gesaboteerde adsk key) gewoon echt niet handig.

adsk is een mechanisme om (met name in zakelijke settings) zichtbaar te maken dat berichten aan "deze" key gedeeld worden met meerdere andere key-owners.

Het voorbeeld bij gpg dat een enkele gebruiker meerdere devices heeft - wellicht niet allemaal even high-security is misschien ook wel een use case , hoewel dat wel veel alertheid vraagt wanneer je primair de "meest secure" key gebruikt en wanneer het ook goed genoeg is voor een key die op een minder trusted device gebruikt wordt.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.