PGP: van theorie naar praktijk Auteur: Ing. Vincent Alwicher MSIT CISSP > Vincent Alwicher is als information security consultant werkzaam bij de Royal Dutch Shell Group. Hij is te bereiken via
[email protected]. Noot: Dit artikel is op persoonlijke titel geschreven en reflecteert niet de Shell situatie. Het is gebaseerd op ervaringen die zijn opgedaan in projecten bij andere organisaties. Hiervoor kan het (commerciële) product PGP Desktop worden ingezet. De open source gemeenschap heeft ook niet stilgezeten en al jaren zijn er diverse goede open source PGP alternatieven beschikbaar en bestaat er een OpenPGP protocolspecificatie [2]. De open source initiatieven vallen in dit artikel buiten beschouwing. De messaging-, disk-, bestand- en containerencryptie mogelijkheden van PGP zullen ook niet worden behandeld. Alle referenties naar ‘PGP’ in dit artikel slaan uitsluitend op de commerciële oplossing PGP (PGP Desktop + enkele aanverwante producten). Tenslotte moet opgemerkt worden dat veel van de gebruikte terminologie in dit artikel PGP Corporate Desktop versie 8 gerelateerd is. De huidige vergelijkbare versie PGP Universal 200 is significant anders. Basiskennis van cryptografie en PKI (public key infrastructure) wordt verwacht van de lezer en zal in dit artikel niet verder worden uitgelegd.
Vertrouwensmodellen Alvorens met een cryptografische toepassing voor eindgebruikers zoals secure e-mail te beginnen, dient er een belangrijke afweging te worden gemaakt. Welk vertrouwensmodel wordt als uitgangspunt gehanteerd? In de regel zijn er drie modellen: 1) Het hiërarchische model, 2) Het direct-trust model en 3) Het web-of-trust model. Het eerste model wordt veelvuldig toegepast en kenmerkt zich vaak door één of meerdere CA’s (Certificate Authority) die garant staan voor correcte generatie, uitgifte en beheer van digitale certificaten (zie kader 1) aan gebruikers of andere entiteiten. Bekende voorbeelden hiervan zijn PKI Overheid [8] en VeriSign [9], maar tegenwoordig zijn er ook veel organisaties die hun eigen interne PKI’s en CA’s hebben draaien. Het principe van het hiërarchische model is dat alle sleutels digitaal onder-
16
Enkele jaren geleden verscheen er een artikel [1] in dit blad over de praktische toepasbaarheid van PGP (Pretty Good Privacy). Inmiddels zijn we ruim vier jaar verder. Tijd voor een nieuwe beschouwing. PGP is in 1991 door Phil Zimmermann gelanceerd en heeft sindsdien een hele ontwikkeling doorgemaakt. Nadat het een paar keer van eigenaar is gewisseld, heeft de huidige eigenaar PGP Corporation het product aangevuld met een suite van security oplossingen [3] [4]. Dit artikel bekijkt wederom de praktische toepasbaarheid van PGP met behulp van een praktijkcase waarbij één van de meest voorkomende toepassingen, secure e-mail, centraal staat. tekend worden door een centraal orgaan (CA) dat door iedereen wordt vertrouwd. Op deze manier wordt er een sleutelinfrastructuur gecreëerd, die bijvoorbeeld voor secure e-mail kan worden gebruikt, waarbij aangesloten gebruikers op de CA vertrouwen dat de identiteit van de personen aan wie sleutels zijn toegewezen is gecontroleerd. Het tweede model (direct-trust) is het simpelste model. Een gebruiker vertrouwt dat een sleutel valide is omdat hij weet wat de herkomst is. Veel cryptosystemen gebruiken dit principe op de een of andere manier. In webbrowsers bijvoorbeeld, vertrouwen gebruikers direct op de meegeleverde CA
sleutels door de fabrikant. Het directtrust model legt de verantwoordelijkheid van het vaststellen van de juiste identiteit en het koppelen aan een publieke sleutel bij de eindgebruiker zelf neer. Hiervoor moet hij de publieke sleutel van een ander digitaal ondertekenen met zijn eigen privésleutel om de geldigheid te bekrachtigen. Als men dit volgens het
INFORMATIEBEVEILIGING DECEMBER 2005
boekje wil doen, dan dient de fingerprint van een sleutel te worden gecontroleerd via een betrouwbaar kanaal/medium om met zekerheid vast te kunnen stellen dat de sleutel inderdaad tot de juiste persoon behoort. Fingerprint controle gebeurt in de praktijk zelden en dat maakt dit model kwetsbaar indien er onzorgvuldig wordt gehandeld door de gebruiker. Maar dit betekent ook dat er geen centrale infrastructuur inclusief certificate authority benodigd is, wat de flexibiliteit en eenvoud van inzetbaarheid ten goede komt. Figuur 1 - Het al dan niet geldig zijn (Validity) en het gestelde vertrouwen in sleutels (Trust)
Het derde model (web-of-trust) combineert het directe en hiërarchisch model en voegt daar een filosofie aan toe. Een gebruiker heeft de vrijheid om te bepalen of hij de ‘vriendjes’ van zijn eigen ‘vriendjes’ weer vertrouwt, zodat hij wordt ontlast van de identificatie en sleutelkoppeling van deze personen. Een sleutel van een derde kan recht-
streeks aangemerkt worden als vertrouwd, maar kan ook vertrouwd zijn doordat deze al eerder is gevalideerd door een certificate authority of trusted introducers. Trusted introducers kunnen andere PGP gebruikers zijn. PGP gebruikt de digitale handtekening als middel om te introduceren. Als iemand een sleutel ondertekent, dan wordt hij een introducer van deze sleutel en een trusted introducer indien een ander de sleutel als vertrouwd aanmerkt. Gevorderde PGP gebruikers zullen dit herkennen als respectievelijk de validity kolom en de trust kolom van PGPkeys (figuur 1). Op de hierboven beschreven manier wordt er een web-of-trust netwerk gecreëerd waarbij iedereen bijdraagt aan het correct identificeren en koppelen van gebruikersidentiteiten aan publieke sleutels. Er wordt al jaren gediscussieerd over wat nu het ideale vertrouwensmodel is, waardoor secure e-mail een heet hangijzer blijft voor veel organisaties. Het hiërarchische model is statisch, maar biedt wel meer controle, terwijl het direct-trust samen met het web-oftrust model weer veel flexibiliteit biedt, maar juist meer kennis en inzicht van eindgebruikers verlangt. Alle modellen hebben voor- en nadelen.
kenbaarheid en het vertrouwen in sleutels naar derden buiten de organisatie, het verbeteren van de life cycle van sleutels, het introduceren van data herstelmogelijkheden en sleutelrevocatie. Daarnaast moest de PGP configuratie niet eenvoudig door eindgebruikers aangepast kunnen worden. Tenslotte diende ook de bekende flexibiliteit van PGP behouden te blijven. Dat is vooral belangrijk bij communicatie met derden van buiten het bedrijf waar PGP sleutels van derden eenvoudig te importeren en te gebruiken moeten zijn.
Sleutelstructuur Figuur 2 - Logisch overzicht van de verschillende sleutels en hun relaties
CSK is benodigd om vertrouwensrelaties (cross certification) te scheppen tussen de verschillende landen onderling. Het beleid schrijft voor dat alle sleutels van medewerkers digitaal ondertekend moeten zijn door de landelijke CSK en de Root CSK. Het gebruik van niet-getekende sleutels wordt ontmoedigd en technisch zo veel mogelijk voorkomen. Verder heeft ieder land nog een drietal speciale sleutels: De ADK is benodigd voor data recovery. De DRK is vereist bij sleutelrevocatie in de gevallen waar de privé-sleutel van de gebruiker niet meer toegankelijk is. Tenslotte zijn er meerdere ESK’s. Deze zijn vergelijkbaar met een kreet die we veel tegen-
Praktijkcase Het vervolg van dit artikel behandelt een praktijkcase van een grote internationaal opererende organisatie die een hybride vertrouwensmodel heeft geïmplementeerd en waarbij PGP als secure e-mail oplossing is ingezet. Het uitgangspunt was om een bedrijfsbrede oplossing te creëren waarbij alle PGP sleutels op een uniforme en herkenbare manier worden aangemaakt en uitgegeven. Tevens dienen gebruikers zo veel mogelijk te worden ontlast van de initiële uitwisseling en activatie van alle bedrijfssleutels (hieronder vallen de speciale corporate sleutels en die van de medewerkers). Alvorens sleutels van anderen te kunnen gebruiken in het encryptieproces dienen deze eerst vertrouwd gemaakt te worden zoals eerder beschreven (Dit is het bekende grijze validity bolletje dat groen moet worden alvorens een sleutel gebruikt kan worden. Figuur 1). Andere doelstellingen waren: Het eenvoudiger toegankelijk maken van interne PGP sleutels via een centrale PGP Key Server, het vergroten van de her-
Noot figuur 2: Normaliter laten schema’s van CA’s en gebruikers enkel de lineaire vertrouwensrelaties zien. Vertrouwen en validiteit worden in werkelijkheid natuurlijk vanuit iedere gebruiker en daarvoor aangewezen CA verdeeld, niets slechts vanuit een gebruiker of CA. Het web-of-trust is dan ook een driedimensionaal vertrouwensnetwerk. Figuur 2 schetst een logisch overzicht van de verschillende sleutels en hun relaties. Ieder land heeft zijn eigen CSK. Daarnaast bestaat er één Root CSK. Deze opzet heeft als doel om ieder land hun eigen sleutels van medewerkers te valideren en de Root
komen in het hiërarchische model, namelijk subordinate CA’s. In het PGP web-of-trust model kan iedereen als certificate authority fungeren en sleutels van anderen valideren. In dit voorbeeld zijn het echter de ESK’s die deze taak hebben binnen de organisatie en alle sleutels valideren en ondertekenen met een ESK handtekening. Hiermee bekrachtigen ze dus dat de PGP gebruiker correct is geïdentificeerd en de juiste sleutel aan de juiste persoon is gekoppeld.
Sleutelgeneratie en -uitgifte Figuur 3 - Creatie- en uitgifteproces van sleutelparen voor eindgebruikers
INFORMATIEBEVEILIGING DECEMBER 2005
17
Het creatie- en uitgifteproces van een PGP sleutelpaar verloopt nu als volgt: 1. Een operationele afdeling (NL Operations in dit voorbeeld) installeert een customized lockdown versie van PGP Desktop bij een nieuwe PGP gebruiker (zie kader 2). 2. Samen met de eindgebruiker wordt een sleutelpaar aangemaakt waarbij de gebruiker zelf zijn passphrase moet invoeren. Middels PGP policies worden sterke passphrases afgedwongen. Tevens worden de ADK en DRK verplicht meegenomen in het sleutelgeneratie proces. 3. NL Operations ondertekent de publieke sleutel van de eindgebruiker met een ESK. Operations is de enige partij die daadwerkelijk de gebruiker ontmoet of spreekt en deze stap is dan ook cruciaal in het identificatieproces en dus het vertrouwensmodel. De koppeling van identiteit en sleutel vindt hier plaats. 4. De lokale NL security afdeling controleert de correctheid (naamgevingconventie, sleuteleigenschappen, et cetera) van de gegenereerde en ESKondertekende nieuwe publieke PGP sleutel van de eindgebruiker en indien alles correct is, zal dat vervolgens bekrachtigd worden door het plaatsen van een NL CSK handtekening. Let op: Er zal geen controle meer plaatsvinden van de identiteit van de gebruiker. Er wordt geheel vertrouwd op het correct uitvoeren van de procedure door Operations. Tenslotte zal NL Security de publieke sleutel sturen naar de centrale internationale PGP Key Server. 5. De internationale Corporate Security afdeling verwerkt nieuw ingestuurde sleutels die zich in de wachtrij van de PGP Key Server bevinden. Enkele controles worden weer uitgevoerd en indien akkoord bevonden, zal de sleutel ook nog een keer met de Root CSK worden getekend en in de PGP Key Server worden geactiveerd zodat deze
18
door alle PGP gebruikers binnen de organisatie gevonden kan worden. Alle sleutels zonder Root CSK handtekening worden automatisch uit de PGP Key Server verwijderd. Op deze manier wordt wildgroei voorkomen en zullen ‘vreemde’ geuploade sleutels door eindgebruikers of beheerders niet zomaar worden geaccepteerd. Overige taken van Operations zijn sleutelmanagement diensten zoals key renewals, key revocation, maar ook PGP configuratiewijzigingen. Data recovery is ondergebracht bij de afdeling NL Security. Hiervoor dient namelijk de ADK te worden ingezet en daar gelden strikte regels voor. Een van de doelstelling was om eindgebruikers te ontlasten van de zoektocht naar en uitwisseling van PGP sleutels met andere medewerkers. Met deze oplossing is nu een situatie gecreëerd waarbij een gebruiker secure e-mail berichten kan sturen naar andere medewerkers, zonder zich daarbij af te hoeven vragen of hij de correcte publieke sleutel wel heeft en of deze geactiveerd is (figuur 1, groene bolletjes). Publieke sleutels worden automatisch door de PGP plugin van de e-mailclient (of een onderliggende proxy) uit de PGP Key Server opgehaald, opgeslagen en regelmatig ververst in de lokale keyring van de gebruiker. Volledige transparantie is een feit. Figuur 4 - Eigenschappen van een PGP sleutel
INFORMATIEBEVEILIGING DECEMBER 2005
Noot figuur 4: A. In de eigenschappen van een PGP sleutel zijn gegevens te vinden over de geldigheid en bijbehorende DRK, ADK en de fingerprint. B. Toont de DRK waarmee een sleutel kan worden ingetrokken als deze bijvoorbeeld verloren is. C. Toont de verplichte (gemarkeerd met rood bolletje) ADK waarmee versleutelde gegevens ook bij verlies van de originele sleutel kunnen worden ontsloten. D. Om de fingerprint eenduidig te kunnen verifiëren zijn de hexadecimale waarden omgezet naar unieke Engelse woorden zodat het eenvoudiger is om deze via een ander (betrouwbaar) kanaal te communiceren. Bijvoorbeeld via de telefoon.
Geleerde lessen • Het lijkt een open deur, maar het goed beleggen van operationele taken blijft een heikel punt. Goede technische kennis en kunde van PGP bij operationele afdelingen is erg belangrijk om de verschillende processen optimaal geïmplementeerd te krijgen. Duidelijke documentatie, training en begeleiding is cruciaal. • De verschillende CSK/ESK handtekeningen (figuur 5) die op een sleutel worden gezet, lijken nogal een overkill. De praktijk toont echter de toegevoegde waarde aan van deze verschillende controlepunten. Het komt ten goede aan de kwaliteit en beheersbaarheid van de sleutels en voorkomt
Figuur 5 - Eindgebruiker’s sleutelpaar met verschillende handtekeningen
wildgroei en vervuiling van sleutels in de centrale PGP Key Server. • Data recovery kan lastig zijn. De ADK is in feite een loper waarmee alle versleutelde berichten ontcijferd kunnen worden. Het spreekt voor zich dat er uitermate voorzichtig met deze sleutel omgesprongen moet worden en er strikte procedures moeten zijn voor het gebruik ervan. Het laten rondslingeren van de ADK op PC’s moet voorkomen worden. • Leg het begrip ADK niet op een negatieve manier uit (Big Brother die overal bij kan), maar toon de gebruikers de voordelen van zo’n mastersleutel, zoals hulp bij het ontsluiten van onbereikbare versleutelde data. • Wees voorzichtig met het gebruik van verschillende versies van PGP. Versie 6 ondersteunt bijvoorbeeld geen AES (dat was er toen simpelweg nog niet). Zorg ervoor dat er duidelijk beleid is omtrent het gebruik van PGP versies en gebruikte algoritmes en adviseer (of verplicht indien noodzakelijk) je bedrijfsonderdelen en andere communicatiepartners (te) oude software te vernieuwen. • Ondanks alle inspanningen om gebruikers zo veel mogelijk tegemoet te komen, zijn er mensen die niet overweg kunnen met dit soort toepassingen en de encrypt en sign buttons in de e-mail client niet kunnen vinden. Policy-gedreven en gateway-gebaseerde e-mail encryptieoplossingen, waarbij nauwelijks gebruikersinteractie benodigd is, zouden hier een uitkomst kunnen bieden. Dit soort oplossingen zijn ook al jaren beschikbaar in de markt en zijn absoluut de toekomst. PGP Universal is bijvoorbeeld zo’n product. • Verschillende e-mail aliassen is lastig. Met oudere PGP versies dien je handmatig meerdere PGP identiteiten op te voeren. PGP versie 9 doet dit nu automatisch. Een belangrijke verandering in PGP versie 9 is dat het plugin concept vervangen is door een proxy.
Tom McCune’s legt dit aardig uit op zijn PGP website [6]. • Het gebruik van een PGP Key Server zorgt ervoor dat er minder fouten worden gemaakt bij de uitwisseling van sleutels. Deze fouten worden met name vaak veroorzaakt door verkeerde export/import acties. Bovendien hoef je dan niet meer telkens alle lokale keyrings te actualiseren. • Gebruikers blijven lange passphrases lastig vinden, maar deze blijven cruciaal voor goede bescherming van privé-sleutels en dus een absolute must die afgedwongen moet worden. Het gebruik van bijvoorbeeld smartcards zou een goed alternatief kunnen zijn voor zowel de authenticatiefunctie als een veiliger opslagmogelijkheid voor sleutels. • Het opslaan van de lokale PGP keyring in de My Documents folder (die ook nog gesynchroniseerd wordt met de centrale infrastructuur) is een mogelijke kwetsbaarheid van de implementatie in deze case indien er slechte passphrases worden gebruikt om de privé-sleutel te beschermen. • Het gebruik van PGP op handheld devices is nog niet door de organisatie geïmplementeerd vanwege de beperkte ondersteuning van PGP hiervoor. De Blackberry wordt tegenwoordig wel weer ondersteund. • Het gebruik van de Word editor binnen Outlook wordt niet door PGP ondersteund. • PGP versie 8 en lager ondersteunen geen S/MIME en dat staat compatibiliteit met andere PKI oplossingen (lees: derden met niet-PGP oplossingen) in de weg. PGP versie 9 ondersteunt wel S/MIME.
Conclusies Dit artikel heeft laten zien dat het met PGP prima mogelijk is om hiërarchie en controle te scheppen. Relatief eenvoudig kunnen verschillende praktische voordelen worden behaald. Samengevat zijn dat onder andere: 1)
Uniforme manier van sleutelgeneratie, 2) Verbeterd sleutelmanagement, 3) Ontlasting van initiële activatie door eindgebruiker, 4) Transparantie voor eindgebruikers, 5) Betere herkenbaarheid en vertrouwen richting derden, 6) Introductie van data herstelmogelijkheden, 7) Centrale sleutelrevocatie mogelijkheden en 8) Centraal beheerde en lockdown PGP client configuraties. Tenslotte is ook de bekende web-oftrust flexibiliteit van PGP behouden gebleven, waardoor er in het geheel een hybride vertrouwensmodel is ontstaan. Helaas kan er in de oplossing, zoals deze is beschreven in de praktijkcase, nauwelijks controle worden uitgeoefend op de uitwisseling van PGP sleutels met derden van buiten de organisatie. Daarvoor is men in hoge mate afhankelijk van de eindgebruiker. En dat is een van de redenen waarom client-based secure e-mail infrastructuren altijd klein zijn gebleven en puur tactisch worden ingezet. Een gateway is benodigd voor enforcement en volledige controle en dus voor grootschalig (strategisch) gebruik. Een belangrijke les is dat ondanks alle inspanningen het lastig is voor een deel van de gebruikerspopulatie om met secure e-mail te werken. Dit is echter volledig inherent aan de technische oplossing of het gekozen vertrouwensmodel. Wellicht is het te wijten aan inzicht en soms lijkt het zelfs op onwil van gebruikers en is het dus meer een mentaliteitskwestie. Eindgebruikers die uit hoofde van hun functie of rol gebruik moeten maken van de secure e-mail faciliteiten, moeten doordrongen worden van nut en noodzaak en uitleg krijgen over hoe ze in de praktijk hiermee moeten omgaan. Organisaties dienen daarom voldoende aandacht te (blijven) besteden aan bewustzijn, training en het communiceren en naleven van duidelijke beveiligingsrichtlijnen.
INFORMATIEBEVEILIGING DECEMBER 2005
19
Er kleeft aan secure e-mail ook een juridische kant zodra e-mail berichten digitaal ondertekend worden met een cryptografische sleutel. Hoe zit het dan met aansprakelijkheid, onweerlegbaarheid, et cetera? De disclaimers die tegenwoordig automatisch aan bedrijfsmail wordt toegevoegd zijn er niet voor niets. Er zijn voor internationaal opererende organisaties diverse vraagstukken met betrekking tot het inzetten van cryptografische oplossingen in landen waar wet- en regelgeving op dit gebied sterk verschillen [7]. Er zijn dus veel meer aspecten belangrijk dan alleen maar een tool of technische oplossing.
Referenties [1] Artikel PGP Onder De Loep door Leon Kuunders Informatiebeveiliging 1/2001 [2] OpenPGP www.openpgp.org [3] PGP Corporation www.pgp.com (commerciële versies) [4] PGP historie http://www.pgp.com/company/history.html [5] Tom McCune’s page for PGP www.mccune.cc/PGP.htm [6] Bert-Jaap Koops - Crypto Law Survey http://rechten.uvt.nl/koops/cry ptolaw/ [7] PKI Overheid www.pkioverheid.nl [8] VeriSign www.verisign.com
Digitaal certificaat Een digitaal document dat de binding van een (natuurlijk of rechts-) persoon met een cryptografische sleutel garandeert, uitgegeven door een certificatenaanbieder (CA). Het certificaat bevat ten minste de publieke sleutel van de persoon, de unieke naam van de persoon, een geldigheidsdatum en gegevens over de CA. Het geheel is door de CA ondertekend met diens privé-sleutel, waardoor de gegevens niet manipuleerbaar zijn. De term ‘certificaat’ wordt veelvuldig gebruikt in het hiërarchische vertrouwensmodel dat gebruik maakt van de X.509 standaard. Binnen PGP omgevingen wordt de term ‘certificaat’ minder snel gebruikt.
CSK - Corporate Signing Key Een sleutelpaar dat primair gebruikt wordt om de validatie van andere digitale certificaten of digitale informatie te bekrachtigen. Deze validatie vindt plaats door een autoriteit die acteert namens het bedrijf. In deze case is het de organisatie zelf die als CA acteert. De CSK is een PGP term.
ADK - Additional Decryption Key Een data recovery sleutel. In een omgeving waar het gebruik van een ADK technisch wordt afgedwongen, is een organisatie in staat om gebruikers te helpen bij het ontsluiten van hun data indien zij niet meer de beschikking hebben over hun sleutels of passphrase. Ieder e-mail bericht dat wordt verstuurd, wordt namelijk ook altijd automatisch versleuteld met de ADK. De ADK is een PGP term.
DRK - Designated Revocation Key Een sleutel die het mogelijk maakt om iedere verloren, gestolen of anderszins gecompromitteerde sleutel in te trekken. Een gebruiker is namelijk niet zelf meer in staat om dat te doen indien hij niet meer de beschikking heeft over zijn sleutels of passphrase. De DRK is een PGP term.
ESK - End user Signing Key Sleutels die worden ingezet om namens de CA een deel van het validatieproces over te nemen. Hiermee wordt de CA ontlast en krijgen bepaalde organisatieonderdelen zelf de verantwoordelijkheid voor het validatieproces en binding van sleutels aan identiteiten. De ESK is in feite een Trusted Introducer Key (TIK). TIK is een PGP term. ESK is een afkorting die door de organisatie in deze case zelf is geïntroduceerd.
Customized lockdown versie van PGP Desktop Het is mogelijk om een aangepaste PGP client te bouwen (en delen van) de configuratie af te schermen tegen wijzigingen door gebruikers. Hiermee heeft de organisatie meer controle over het gebruik van PGP en het sleutelmanagement. De volgende punten geven een overzicht van de mogelijkheden: • PGP Key Server: *Vaste koppeling met centrale PGP Key Server waarin naast publieke sleutels ook de PGP client configuraties kunnen worden opgeslagen; *Regelmatige verversing middels de server van de configuratie en sleutels die zijn opgeslagen in de lokale keyring; *Verplicht synchroniseren met PGP Key Server bij verschillende acties (encrypt, sign, revoke, verify); *Automatisch opzoeken van sleutels in de PGP Key Server bij het encrypten van berichten naar voor de gebruiker nog niet bekende sleutels; *Eventuele koppeling met andere publieke PGP directories op het internet; • Passphrase policies (minimaal aantal karakters, samenstelling van passphrase, et cetera); • Vaststellen en blokkeren van single sign-on waarden (passphrase cache timeout); • Instellen van minimaal toegestane sleutellengte, te gebruiken algoritme en levensduur van sleutels; • Verplichte versleuteling voor in- en/of uitgaand verkeer met ADK en verplichte toekenning van DRK; • Automatisch toevoegen van standaard corporate sleutels aan nieuwe lokale keyrings (ADK, DRK, ESK’s); • Aanmaken van nieuwe client sleutels toestaan of blokkeren; • Selectie van de te installeren PGP componenten (Outlook plugin, PGPdisk module, et cetera). • Automatische backup van lokale keyring naar netwerkschijf; Software benodigdheden: PGP Desktop, PGP Admin en PGP Key Server (tegenwoordig: PGP Universal Server). Zie [5] voor meer informatie over de laatste PGP producten en versies.
Passphrase De PGP prive-sleutel wordt beveiligd met een passphrase. Een passphrase is meer dan een wachtwoord. Daarom wordt de term ‘wachtzin’ ofwel passphrase gebruikt. Een adequate passphrase bestaat uit meerdere woorden en een variëteit aan verschillende karakters. Hoe langer en hoe gevarieerder de passphrase, hoe beter deze beschermt is tegen brute force aanvallen.
kader 1
20
INFORMATIEBEVEILIGING DECEMBER 2005
kader 2