3.1. PEM

V praxi nedošlo k jeho masovému využití nejširší veřejností. Nebyl totiž běžně dostupný software, který by jej podporoval. Příčin bylo bezpochyby více, ale asi tou nejdůležitější je skutečnost, že na přelomu 80. a 90. let nebyla ještě masová poptávka po software tohoto druhu.

V první polovině 90. let došlo k masovému rozšíření PGP jehož výhodou byla jednoduchost a snadná dostupnost. Přitom PGP v té době vyhovovalo naprosté většině uživatelů.

Protokol PEM se však stal základem pro novější protokoly. Dnes se právě S/MIME zdá být východiskem a přitom S/MIME je PEM fylozoficky velmi blízké. Zejména se jedná o správu šífrovacích klíčů pomocí certifikátů.

Zpráva

1. Předpokládáme, že zpráva byla v kódování (reprezentaci dat) operačního systému, na kterém byla pořízena. PEM neřeší problematiku komprese dat ani problematiku znakových sad pro jednotlivá národní prostředí. Jednoduše si představme anglicky psaný text se znaky pro nový řádek. Text zprávy může být vytvořen např. v kódu EBCDIC (tj. ne nutně ASCII).
2. Zpráva odesílaná elektronickou poštou musí být před odeslání protokolem SMTP převedena do jednotné kanonické formy, tak aby systém příjemce měl šanci interpretovat správně jednotlivé znaky zprávy, tj. tak jak je mínil odesilatel.

Např. text je převeden do kódu ASCII, konec řádku je reprezentován dvojicí znaků <CR>< LF> atp.
Zpráva se v kanonické formě pouze přenáší Internetem, příjemcův systém zprávu opět převede do tvaru lokálního operačního systému. Kanonická forma je tvar, ve kterém si systémy zprávu předávají v počítačové síti.Takto reprezentovaný text budeme označovat jako text zprávy.
3. Předchozí dva kroky se provádí na všechny zprávy přenášené elektronickou poštou bez ohledu na to, zdali jsou šifrovány nebo ne. Dalším krokem je právě šifrování a elektronické podepisování zprávy.
4. Jenže zpráva po šifrování a elektronickém podepisování už opět nevyhovuje pro přenos protokolem SMTP (zejména není sedmibitová a délka řádku není omezena), takže je nutné zprávu převést do "tisknutelného tvaru". PEM používá kódování Base64.

Obdobně zpracování přijaté zprávy můžeme vyjádřit:
 

Zpráva = převod z kanonické formy ( dešifrování a verifikace el.podpisu ( Base64 - dekódování ( přenášená zpráva ) ) )

Typy zpracování

• ENCRYPTED - není vypuštěno nic. Zpráva je elektronický podepsána, šifrována a posléze kódována Base64.
• MIC-ONLY - vypuštěno je šifrování, tj. zpráva je pouze elektronicky podepsána a kódována Base64. Zprávami pouze elektronicky podepsanými se přenáší data, u kterých není důležité tajit jejich obsah (je např. veřejně znám), ale je důležité, kdo zprávu odeslal a zda-li nebyla pozměněna.
• MIC-CLEAR - vypuštěno šifrování a kódování. Zpráva je elektronicky podepsána, ale její obsah je možné přečíst i programy, které nepodporují PEM (neumí ani Base64). Příjemce si zprávu může přečíst aniž by ověřoval elektronický podpis. Případné ověření může provést až později, tj. až v případě pochybností.
• CRL - typ zprávy CRL je úplně z jiného soudku. Zpráva typu CRL je určena pro seznam zneplatněných certifikatů (Certificate Revocation Lists - CRL). Tento seznam je podepsán certifikační autoritou a kódován Base64 (viz RFC1422).

Šifrování

• Náhodně vygenerovaný klíč pro šifrování textu zprávy (DEK-klíč). DEK-klíč je generován pro každou posílanou zprávu vždy znovu.
• Klíče pro šifrování DEK-líčů, tzv. IK-klíče. IK-klíče mají delší dobu platnosti. IK-klíče má zpravidla konkrétní uživatel certifikovány certifikační autoritou.

Obrázek 3.1

Nejčastěji se pro šifrování textu zprávy používají symetrické šifry. Symetrický šifrovací klíč je pak přenášen zašifrován asymetrickou šifrou. PEM však specifikuje i možnost použití symetrické šifry i pro šifrování DEK-klíče - tj. symetrické IK-klíče.

Z dnešního pohledu se zdá, že používání symetrických IK-klíčů nemá velký praktický význam. Zpráva nemůže být elektronicky podepsána - pouze kontrolní součet zprávy je přenášen symetricky šifrován. Při použití symetrických IK-klíčů se IK-klíčem šifruje jak DEK-klíč, tak i kontrolní součet zprávy. V případě, že se ze zprávy vypočítá kontrolní součet, který se šifruje symetrickou šifrou, tak lze sice zkontrolovat integritu zprávy, ale ne její autentičnost (tj. nelze prokázat, že původce zprávy je opravdu odesilatel).

Nadále se budeme zabývat pouze případem, kdy IK-klíče jsou asymetrické. Text zprávy je pak šifrován veřejným klíčem příjemce a k elektronickému podpisu je použit soukromý klíč odesilatele.

Obrázek 3.2

Na obrázku opět není znázorněno, že jednotlivé části jsou kódovány Base64 a elektronický podpis je navíc ještě před odesláním šifrován DEK-klíčem.

Je-li zpráva odesílána více adresátům, pak DEK-klíč se zašifruje pro každého adresáta zvlášť jeho veřejným klíčem.

Podobně i při podepisování zprávy by mohlo zprávu teoreticky podepsat více uživatelů. Každý by si vytvořil kontrolní součet (mohou použít i různé algoritmy výpočtu kontrolního součtu) a podepsal jej svým soukromým klíčem.

Identifikace šifrovacího klíče

Text zprávy je šifrován DEK-klíčem. Šifrovací algoritmus pro šifrování textu zprávy pro příslušný DEK-klíč s jeho parametry se uvádí v hlavičce DEK-Info. Tato hlavička má následující syntaxi:

DEK-Info: algoritmus-mód,parametry

Samotný DEK-klíč je zašifrován IK-klíčem příjemce (adresáta). IK-klíč vždy po určitou dobu používá konkrétní uživatel. IK-klíč je reprezentován jeho certifikátem.

PEM se orientuje na certifikáty vydané certifikační autoritou. Každý takový certifikát je jednoznačně identifikován identifikací (jménem) certifikační autority a sériovým číslem certifikátu. Naopak jméno uživatele v certifikátu nemusí být jednoznačné.

Certifikát identifikuje dvojici veřejný/soukromý klíč uživatele. Pro odeslání zprávy je však třeba jak certifikát příjemce tak i soukromý klíč odesilatele (reprezentovaný rovněž certifikátem). Protože DEK-klíč je šifrován veřejným klíčem adresáta (určen certifikátem adresáta), kdežto elektronický podpis je šifrován soukromým klíčem odesilatele (určen certifikátem odesilatele).

Zpráva musí minimálně obsahovat identifikaci těchto dvou klíčů - dvou certifikátů. Jako identifikace slouží právě název certifikační autority a sériové číslo certifikátu. Pro identifikaci se používají hlavičky:
 
Tabulka 3.1

Hlavička	Význam
Originator-Certificate:	Tato hlavička obsahuje (Base64 kódovaný) celý certikát odesilatele.  Následovaná vždy hlavičkou specifikující šifrovací algoritmus s módem ve kterém je použit a za oddělující čárkou pak veřejným klíčem zašifrovaný DEK-klíč:  Key-Info: algoritmus-mód,zašifrovaný DEK-klíč  DEK-Info:
Isssuer-Certificate:	Tato hlavička může obsahovat certifikat certifikační autority, která certifikát uvedený v hlavičce Originator-Certificate vydala.
Originator-ID-Asymetric:	Identifikuje odesilatele.  Originator-ID-Asymetric: Identifikace_CA,sériové_číslo_certifikátu  V případě, že by tato hlavička identifikovala certifikát uvedený v hlavičce Originator-Certificate:, pak se tato hlavička vynechává.  Následovaná vždy hlavičkou specifikující šifrovací algoritmus s módem, ve kterém je použit a za oddělující čárkou pak veřejným klíčem zašifrovaný DEK-klíč:  Key-Info: algoritmus-mód,zašifrovaný_DEK-klíč
Recipient-ID-Asymetric:	Identifikuje příjemce (adresáta). Syntaxe:  Recipient-ID-Asymetric: Identifikace_CA,sériové_číslo_certifikátu  Následovaná vždy hlavičkou specifikující šifrovací algoritmus s módem, ve kterém je použit a za oddělující čárkou pak veřejným klíčem zašifrovaný DEK-klíč:  Key-Info: algoritmus-mód,zašifrovaný_DEK-klíč

Elektronický podpis

Elektronický podpis je specifikován v hlavičce MIC-Info. Jelikož pro elektronický podpis se používá soukromý klíč odesilatele, tak hlavička MIC-Info následuje za hlavičkami identifikujícími IK-klíč odesilatele, tj. za hlavičkami: Originator-ID-Asymetric, Originator-Certificate a Isssuer-Certificate. Hlavička má syntaxi:

MIC-Info: algoritmus_kontrolního_součtu,šifrovací_algoritmus,kontrolní_součet

Kontrolní součet je posléze šifrován ještě DEK-klíčem a kódován Base64. Např. používáme-li pro výpočet kontrolního součtu algoritmus MD5 a pro šifrování algoritmus RSA, pak poslední parametr v hlavičce MIC-Info má tvar:

el.podpis = Base64 ( DEK ( RSA_{soukromý_klíč_odesilatele} ( MD5 (text_zprávy) ) ) )

Celý protokol odeslání zprávy vypadá takto:

Předpoklady:

1. Odesilatel si předem nechal certifikační autoritou vystavit svůj certifikát. Certifikát verifikoval a spolu s certifikátem certifikační autority si jej uložil.
2. Odesilatel si předem nějakou cestou obstaral certifikát příjemce. Cerifikát verifikoval. Oveřil, že certifikát není na seznamu CRL.

1. Odesilatel vygeneruje náhodný DEK-klíč, kterým zašifruje text zprávy.
2. Odesilatel vyplní hlavičku Originator-Certificate svým certifikátem. Volitelně vlastním veřejným klíčem z tohoto certifikátu šifruje DEK-klíč a výsledkem je hlavička Key-Info následovaná za hlavičkou Originator-Certificate.
3. Podle potřeby odesilatel doplní ještě hlavičku Issuer-Certificate.
4. Odesilatel spočítá kontrolní součet textu zprávy, který šifruje svým soukromým klíčem. Výsedkem je pak hlavička MIC-Info.
5. Odesilatel podle údajů z certifikátu příjemce (adresáta) vyplní hlavičku Recipient-ID-Asymetric. Odesilatel dále veřejným klíčem z certifikátu příjemce (adresáta) šifruje DEK-klíč, který uloží do hlavičky Key-Info následované za hlavičkou Recipient-ID-Asymetric.

Obrázek 3.3