10   Bezpečná pošta: S/MIME

V Internetu byla publikována celá řada protokolů specifikujících bezpečnou poštu. Zejména se jednalo o protokoly PEM a MOSS, které se však v praxi  neujaly (jejich popis je na přiloženém CD). Prosadil se protokol PGP, avšak z dnešního pohledu se jeví jasným favoritem protokol S/MIME.

 

Normy RFC-2632 až RFC-2634 jsou již  třetí verzí protokolu S/MIME (Secure/Multipurpose Internet Mail Extension). Zatímco druhá verze protokolu S/MIME byla orientována na algoritmy RSA a MD-5 a zprávy dle PKCS#7, tak třetí verze tyto algoritmy a formát PKCS#7 podporuje jen pro zachování zpětné komptability a orientuje se na protokol CMS.

 

Základními kryptografickými protokoly jsou:

 

S/MIME je koncertem několika protokolů. Jádrem je zpráva CMS, která je zabalená v MIME zprávě. Navíc je třeba s certifikáty a CRL pracovat s ohledem na to, že zprávy mohou být zpracovávány bez přístupu na Internet (OffLine). Před tím, než sestavíme S/MIME zprávu, podíváme se na jednotlivé protokoly, které se této hry účastní.

10.1Zpráva CMS používaná v S/MIME

S/MIME používá formát zprávy CMS. Přitom podporuje pouze následující typy CMS zpráv: Data,  SignedData a EnvelopedData, tj. nepodporuje např. autentizovaná data popisovaná též v normě CMS.

 

V případě elektronicky podepisovaných zpráv musí být struktura signerInfo verze 1. Prakticky to znamená, že v případě elektronického podpisu jsou podporovány pouze zprávy zcela kompatibilní s normou PKCS#7 (což se ovšem netýká zpráv v elektronické obálce).

 

S/MIME doporučuje používat následující tři atributy CMS zpráv (viz kap. 8.9.3). Jedná se o podepisované atributy elektronického podpisu, tj. stuktury signerInfo.

 

sMIMECapabilities   OBJECT IDENTIFIER ::= {pkcs pkcs-9(9) 15}

id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

 

kde

id-aa OBJECT IDENTIFIER ::= { pkcs pkcs-9(9) smime(16) 2 }

 

Podepisované atributy sMIMECapabilities a sMIMEEncryptionKeyPreference zavádí přímo norma S/MIME.

 

První atribut signingTime obsahuje datum a čas podpisu zprávy. Jeho syntaxi jsme popsali v kap. 8.9.3. Zbývající dva atributy zavádí přímo norma S/MIME.

 

Atributem sMIMECapabilities informuje odesilatel příjemce o kryptografických a jiných algoritmech, které podporuje (jaké algoritmy má použít ve své případné odpovědi). Jeho příklad jsme viděli v kapitole 8.9.4:

 

 

       SEQUENCE         

          30 58

        OBJECT            :1.2.840.113549.1.9.15 (S/Mime capabilities)

           06 09 2a 86 48 86 f7 0d 01 09 0f

        SET              

           31 4b

         SEQUENCE         

            30 49

          SEQUENCE         

             30 0a

           OBJECT            :des-ede3-cbc

              06 08 2a 86 48 86 f7 0d 03 07

          SEQUENCE         

             30 0e

           OBJECT            :rc2-cbc

              06 08 2a 86 48 86 f7 0d 03 02

           INTEGER           :80

              02 02 00 80

          SEQUENCE         

             30 07

           OBJECT            :des-cbc

              06 05 2b 0e 03 02 07

          SEQUENCE         

             30 0d

           OBJECT            :rc2-cbc

              06 08 2a 86 48 86 f7 0d 03 02

           INTEGER           :28

              02 01 28

          SEQUENCE         

             30 07

           OBJECT            :sha1

              06 05 2b 0e 03 02 1a

          SEQUENCE         

             30 0a

           OBJECT            :md5

              06 08 2a 86 48 86 f7 0d 02 05

 

Jak je popsáno v kap. 8.9.3, tak každý atribut je sekvencí skládající se z identifikátoru objektu atributu a množiny hodnot. V případě atributu sMIMECapabilities je množina hodnot jednoprvková. Jediným prvkem této množiny je specifikace jednotlivých podporovaných algoritmů. Každý podporovaný algoritmus je specifikován strukturou SMIMECapability:

 

SMIMECapability ::= SEQUENCE {

   capabilityID OBJECT IDENTIFIER,

   parameters ANY DEFINED BY capabilityID OPTIONAL }

 

Tato struktura obsahuje identifikátor objektu příslušného algoritmu a případně parametry.

 

Poslední atribut sMIMEEncryptionKeyPreference je důležitý v případě, že odesilatel používá jiný certifikát pro podepisování a jiný pro šifrování. Častou praxí totiž je, že odesilatel elektronicky podepíše zprávu a jako součást elektronicky podepsané zprávy (CMS zprávy) přibalí svůj certifikát. Příjemce pak využije tento certifikát pro šifrování odpovědi. Potíž je ovšem nastane, nelze-li tento certifikát použít k šifrování. To je i případ kvalifikovaných certifikátů, které mají doporučeno, aby v rozšíření „použití klíče“ měly nastaveno, že se nesmí používat k ničemu jiném než pouze k elektronickému podepisování. Obdobným případem je, že uživatel používá např. certifikáty s algoritmem DSS k elektronickému podpisu a Diffie-Hellmanovy certifikáty pro šifrování.

 

Řešením je, že se šifrovací certifikát také přibalí do CMS zprávy a jeho identifikace se uvede v atributu sMIMEEncryptionKeyPreference. Hodnotou tohoto atributu je pak jedna z následujících možností:

 

sMIMEEncryptionKeyPreference ::= CHOICE {

   issuerAndSerialNumber   [0] IssuerAndSerialNumber,

   receipentKeyId          [1] RecipientKeyIdentifier,

   subjectAltKeyIdentifier [2] SubjectKeyIdentifier

}

 

Zde je již vidět, že pokud přijmeme nějakou elektronicky podepsanou zprávu, pak si náš software u odesilatele poznamená jeho preferované kryptografické atributy a jeho šifrovací certifikát – ten je buď stejný jako jeho podepisovací certifikát nebo je uveden v atributu sMIMEEncryptionKeyPreference. Problém je, pokud od adresáta nemáme žádné takové informace. V takovém případě záleží na tom, zdali máme nějaké zprávy elektronické pošty od adresáta nebo ne:

·         Pokud máme nějaké starší poštovní zprávy od tohoto uživatele, pak se snažíme použít algoritmy, které adresát sám použil v předešlých zprávách. Co se týče certifikátu, tak v případě, že poštovní zpráva od uživatele obsahuje certifikát určený výhradně pro podepisování, tak se snažíme ve starších zprávách nebo v adresářových službách najít certifikát vydaný stejnou CA a se stejným předmětem certifikátu jako je podepisovací certifikát, který je možné použít pro šifrování.

·         Pokud nemáme starší zprávy a adresátův certifikát získáme např. pomocí adresářových služeb, pak použijeme pro šifrování algoritmus 3DES, a není-li to možné, pak RC2/40.

 

10.2Certifikáty a CRL

Adresa elektronické pošty podle RFC-822 musí být uvedena v certifikátu, kterým je dokument podepsán. Jak software odesilatele, tak software příjemce musí zkontrolovat shodu této adresy uvedené v certifikátu s adresou v hlavičce „From:“ nebo „Sender:“ elektronické pošty. Tady je prostor pro různé žertíky, protože adresa v hlavičce „From“ (resp. „Sender“) může obsahovat libovolný řetězec, pokud je v tomto řetězci uvedena adresa ve špičatých závorkách. MS Outlook však uživateli zobrazuje právě ten libovolný řetězec (nikoliv korektní adresu ve špičatých závorkách).

 

V certifikátu může být uvedena adresa elektronické pošty buď v předmětu certifikátu (jedinečné jméno „Common Name“) nebo v rozšíření SubjectAltName.  Obě možnosti jsou podporovány, preferována je však adresa v rozšíření SubjectAltName. Pokud uživatel totiž používá více poštovních adres, pak je všechny může do tohoto rozšíření uvést (rozšíření se uvede vícenásobně).

 

Jinou otázkou jsou rozšíření certifikátu. S/MIME vyžaduje, aby software podporoval rozšíření: Basic

Constraints, Key Usage,  authorityKeyID, subjectKeyID a subjectAltNames. Ostatní rozšíření podporovat pouze může, tj. ostatní rozšíření nemohou být označena jako kritická, aby bylo zajištěno, že příslušný software pro S/MIME je bude podporovat a neodmítne celý certifikát.

 

CRL může být součástí zprávy CMS, tj. tím pádem i zprávy S/MIME. Je pochopitelně pravda, že nejefektivnější je používat On Line zjištění, jak na tom certifikát je,. např. za využití rozšíření URI Distribution Points či protokolu OCSP. Avšak mnohdy uživatelé pracují tak, že se připojí k Internetu, stáhnou si poštu, odpojí se od Internetu a teprve pak si poštu čtou. V takovém případě On Line komunikace s CA je nemožná a je dobré vzít za vděk i CRL ze zprávy. Software klienta by měl umožnit i tato CRL uložit v úložišti CRL počítače pro případné další použití.

 

10.3MIME: Multipart/Signed a Multipart/Encrypted

V kapitole 3 jsme popisovali kompozitní typy. Průlom přinesla norma RFC1847, která  zavádí kompozitní typy multipart/signed (pro elektronicky podepsané zprávy) a multipart/encrypted (pro zprávy v elektronické obálce), tj. rozšiřuje MIME o hlavičky vhodné pro elektronický podpis a šifrování zprávy. S/MIME pro některé elektronické podpisy používá kompozitní typ multipart/signed, druhý kompozitní typ mulitipart/encrypted S/MIME nepoužívá.

 

Norma RFC1847 je obecnou normou, tj. specifikuje pouze obecný tvar zprávy, která je elektronicky podepsána nebo šifrována. Kryptografické protokoly jsou tu obecně vyjádřeny pouze řetězcem protocol=typ/subtyp. Algoritmus výpočtu kontrolního součtu pro elektronický podpis se obecně vyjadřuje parametrem micalg=algoritmus.

 

Následující normy pak rozpracovávají jednotlivé tvary „bezpečných zpráv“, tj. určují konkrétní hodnoty dosazené za typ/subtyp. Např. dnes již téměř zapomenutá norma MOSS používá řetězce application/moss-signature a application/moss-encrypted všude tam, kde je v RFC1847 uveden řetězec typ/subtyp.

Jednotlivé části se pak skládají ze záhlaví odděleného prázdným řádkem od textu části zprávy. Záhlaví je tvořeno jednotlivými hlavičkami.

Obrázek 10-1 schématicky znázorňuje tvar elektronicky podepsané zprávy.

Obr. 10-1 Struktura elektronicky podepsané zprávy elektronické pošty

Zajímavé je si uvědomit, že hlavička Content-Type se může vyskytnout až třikrát:

  1. V záhlaví celé zprávy elektronické pošty, tj. v záhlaví SMTP zprávy RFC822 (rozšířené podle MIME). Zde se používá typ Multipart specifikující, že zpráva je složena z více částí. Jako subtyp se zadává informace, zda-li se jedná o zprávu elektronicky podepsanou (Multipart/Signetd) případně šifrovanou (Multipart/Encrypted). V případě elektronického podpisu se parametrem micalg specifikuje algoritmus pro výpočet kontrolního součtu.
  2. V záhlaví první části zprávy, tj. části nesoucí text zprávy. Zde specifikuje např. typ znakové sady a další parametry (např. text/html).
  3. V záhlaví části nesoucí elektronický podpis. Zde specifikuje, že se jedná právě o část nesoucí elektronický podpis.

Jako příklad si zopakujeme příklad elektronicky podepsané zprávy z kap. 8.9.4, který je příkladem S/MIME zprávy. V tomto případě je  protocol="application/x-pkcs7-signature" a micalg=SHA1:

…

From: "Libor Dostalek" dostalek@pvt.cz

To: test@t1.pvt.cz

Subject: Banka

Date: Wed, 7 Mar 2001.11:32:58 +0100

MIME-Version:.1.0

Message-ID: 000c01c0a6f1$fb6c6cd0$c8252fc3@libor

Content-Type: multipart/signed;

   protocol="application/x-pkcs7-signature";

   micalg=SHA1;

   boundary="----=_NextPart_000_0027_01C0A6FA.5C17C3B0"

X-Priority: (Normal)

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)

X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Importance: Normal

 

 Toto je zpráva ve formátu MIME obsahující více částí

 

------=_NextPart_000_0027_01C0A6FA.5C17C3B0

Content-Type: text/plain;

       charset="iso-8859-2"

Content-Transfer-Encoding: 7bit

 

 Banka na namesti v 11:00

 

 Sef

 

------=_NextPart_000_0027_01C0A6FA.5C17C3B0

Content-Type: application/x-pkcs7-signature*);

    name="smime.p7s"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

    filename="smime.p7s"

 

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYICOjCCAjYC

AQEwZDBdMQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZUIGEucy4xETAPBgNVBAsTCDIwMDAwOTAx

MSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0b3JpdGEgSS5DQSAwMDA5AgMB4BIwCQYFKw4DAhoF

AKCCASwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMzA3MTAz

MjU4WjAjBgkqhkiG9w0BCQQxFgQUiTyLOzG09qg6S71Ob5OHiiSyYUgwWAYJKoZIhvcNAQkPMUsw

STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF

Kw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQswCQYDVQQGEwJDWjERMA8GA1UE

ChMIUFZUIGEucy4xETAPBgNVBAsTCDIwMDAwOTAxMSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0

b3JpdGEgSS5DQSAwMDA5AgMB4BIwDQYJKoZIhvcNAQEBBQAEgYBjQe3gKqprZNG20K3O9bBEPWPx

MiHfiupGBw799nMPFuJThITq8aR/JnPusFw9HJMFF+TrAxxk4f9jlYFaVDm9HdrdjODAGh1tP91x

jZ+1By37iibmNV2C23Px1Vq+aoZON0ZDEIqjqnm0D2ruqqrdCa9rpx/j8Pb4nayRi0d2HQAAAAAA

AA==

 

------=_NextPart_000_0027_01C0A6FA.5C17C3B0--

Dále norma RFC1847 specifikuje i zprávu typu Multipart/Encrypted, kterou protokol S/MIME nevyužívá. Její tvar je analogický tvaru zprávy elektronicky podepsané. Opět se zpráva skládá ze dvou částí:

Schématicky je tvar takovéto zprávy znázorněn na následujícím obrázku:

Obr. 10-2 Struktura šifrované zprávy elektronické pošty typu Multipart/Encrypted. S/MIME ji nepoužívá! – S/MIME pro šifrované zprávy používá jednoduchý typ:

„Content-Type: application/x-pkcs7-mime“

 

10.4S/MIME

Mechanismus vytvoření zprávy protokolu S/MIME je znázorněn na obr. 10.3. Zpráva je nejprve zabezpečena protokolem CMS, pak kódována Base64 do sedmibitového tvaru a nakonec obalena hlavičkami MIME a SMTP a odeslána elektronickou poštou.

Obr. 10-3 Mechanismus vytvoření zprávy S/MIME

S/MIME zprávy buďto podepisuje nebo vkládá do elektronické obálky (šifruje). Pokud chceme provést obě operace, tj. zprávu jak podepsat, tak i šifrovat, tak se např. elektronicky podepsaná zpráva vkládá do elektronické obálky či naopak. Tj. vytvoří se elektronicky podepsaná S/MIME zpráva, která se jako data vloží do elektronické obálky – též S/MIME zprávy. Teoreticky norma připouští i opačnou možnost, tj. zprávu v elektronické obálce následně podepsat, ale tato varianta se nedoporučuje. Vždy je totiž lepší podepisovat data v původní podobě, a pak je případně zašifrovat, než podepisovat už zašifrovaná data. Vztah mezi podpisem a interpretací dat pak nemusí být zcela doložitelný (např. u soudu).

Vnoření jedné S/MIME zprávy do druhé je teoreticky možné opakovat i vícekrát. V kapitole o rozšířeném S/MIME uvidíme, že elektronicky podepsaná S/MIME zpráva se vkládá do elektronické obálky a výsledek se ještě elektronicky podepisuje, tj. proces vytváření S/MIME zprávy se provede třikrát.

Asi čekáte, že začneme popisovat zprávy Multipart/signed, ale to je omyl. S/MIME používá kompozitní zprávy skládající se ze dvou částí jen v dále zmíněném případě. S/MIME používá zejména jednoduché zprávy využívající typ:

Content-Type: application/pkcs7-mime

 

A to jak pro elektronicky podepisované zprávy, tak i pro zprávy šifrované. Klasický případ S/MIME zprávy proto je:

 

From:
To:
MIME-Version: 1.0
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64

 

4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 
7GhIGfHfYT64VQbnj756 . . . 

Typ application/pkcs7-mime  může mít několik volitelných parametrů:

·         Parametrem name můžeme specifikovat jméno souboru (stejný význam má i parametr filename v případné hlavičce Content-Disposition).  Jméno souboru může mít nejvýše 8 znaků a 3 znaky rozšíření. Jako jméno souboru se téměř vždy používá „smime“ a rozšíření může být:

o        .p7m pro MIME typ „Application/pkcs7-mime“ v případě elektronicky podepsané zprávy nebo zprávy v elektronické obálce.

o        .p7c pro MIME typ „Application/pkcs7-mime“ v případě, že zpráva obsahuje pouze degenerovanou CMS zprávu obsahující pouze certifikáty.

o        .p7s pro MIME typ  „Application/pkcs7-signature“, tj. pro kompozitní zprávu.

·         Parametr smime-type obsahuje informaci o obsahu zprávy. Tj. specifikuje, zda-li se jedná o podepsanou či šifrovanou zprávu. Ano, tato informace se dá poznat z vnitřku zprávy, ale tato hlavička může usnadnit práci poštovního klienta při zobrazování různých ikonek se symboly elektronického podpisu či šifrování na Vašem PC, aniž by docházelo ke komplikovanému rozboru zprávy. Parametr smime-type nabývá hodnot:

o        enveloped-data pro zprávu v elektronické obálce.

o        signed-data pro elektronicky podepsaná data.

o        certs-only pro degenerovanou zprávu obsahující pouze certifikáty.

Příklad (z RFC-2633):

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;

     name=smime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

 

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6

7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H

f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

0GhIGfHfQbnj756YT64V

No a nyní jsme u problému elektronicky podepsané zprávy. Zpráva vytvořená podle CMS je na první pohled velice těžko čitelná - je to BER kódovaný řetězec. To nevadí v případě, že zpráva bude přijata a interpretována programem, který ji dešifruje, verifikuje a výsledek zobrazí uživateli v čitelném tvaru. Ale mnohdy je třeba zprávy pouze elektronicky podepisovat a rozesílat nejrůznějším adresátům, přitom jen někteří budou používat pro čtení programy podporující S/MIME.

Mnohým adresátům by stačilo si zprávu přečíst bez verifikace elektronického podpisu. Avšak formát application/pkcs7-mime je běžnými klienty nečitelný (zobrazí jej ve tvaru „rozsypaný čaj“ s textem někde uprostřed). Proto kromě formátu application/pkcs7-mime nabízí S/MIME pro elektronický podpis druhou možnost, kdy zpráva je rozdělena pomocí multipart/signed na dvě části: na čitelný text a samostatný „nečitelný“ elektronický podpis podle normy CMS. Jelikož elektronický podpis neobsahuje podepisovaná data (položka eContent v CMS zprávě je prázdná), tak se tento elektronický podpis nazývá externím elektronickým podpisem.

 

S externě podepsanou elektronickou zprávou jsme se setkali v kap. 2.3, přesto si její tvar alespoň schématicky zopakujme:

 

From:
To:
MIME-Version: 1.0
Content-Type: multipart/signed; protocol=application/pkcs7-signature;
               micalg=rsa-md5; boundary=hranice

--hranice
Content-Type: text/plain
Content-transfer-Encoding:

Text v čitelné podobě. 
V případě, že text zprávy není v ASCII, pak je ještě před podepisováním kódován Base64 nebo quoted-printable (tato informace se pochopitelně doplní do hlavičky Content-Transfer-Encoding).
--hranice
Content-Type: application/pkcs7-signature 
Content-Transfer-Encoding: base64

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 
7GhIGfHfYT64VQbnj756 ...
--hranice--

 

10.5Příklad elektronicky podepsané a šifrované zprávy

Tato kapitola obsahuje komentovaný výpis komunikace bezpečnou poštou. Nejprve odesilatel odesílá bezvýznamnou zprávu (v mém případě úplně prázdnou zprávu), aby dopravil adresátovi svůj certifikát. Odesilatel mu pak odpoví již šifrovanou zprávou. Všimněte si několika aspektů:

·         Ač jsem odeslal prázdnou zprávu, tak MS Outlook 2000 (jenž jsem použil) nevygeneroval degenerovanou CMS zprávu signedData, ale úplnou zprávu. Vysvětluji si to tím, že u degenerované zprávy signedData není elektronický podpis, proto by nemohl použít  podepisované parametry, které použít chtěl.

·         V poštovním klientovi (obr. 10-4) jsem si nastavil, že chci používat jiný certifikát jako podepisovací a jiný jako šifrovací. V odesílané zprávě signedData jsou proto oba certifikáty.

·         Za velice důležitou věc považuji si všimnout, kolika adresátům je zpráva určena (v našem případě jednomu) a kolik je v odpovědi struktur recipientInfo. Jsou tam dvě. Proč? Pokud si je prohlédnete, tak jedna je pro adresáta a druhá pro odesilatele. Tj. i když odesilatel není adresátem, tak je ve zprávě envelopedData jedna struktura recipientInfo pro něj. Co by se stalo, kdyby tomu tak nebylo? V takovém případě byste si nemohli prohlížet ve vašem poštovním klientovi složku „Odeslaná pošta“. Nedostali byste se k symetrickému šifrovacímu klíči, kterým je zpráva zašifrována. Že tomu tak opravdu je, lze ověřit jednoduchým příkladem. Pošlete někomu šifrovanou zprávu a když se podíváte do složky „Odeslaná pošta“, tak ji přečtete. Když ovšem si vyexportujete šifrovací certifikát i se soukromým šifrovacím klíčem a zrušíte jej v úložišti vašeho PC, pak tutéž zprávu již nepřečtete. (Pote si nezapomeňte certifikát zpátky importovat!) Je velmi užitečné si tuto skutečnost uvědomit, protože mohou nastat situace, kdy není zašifrování vaším vlastním klíčem žádoucí.

Obr. 10-4 MS Outlook jsem nastavil tak, že jiný certifikát používám k elektronickému podpisu (s „X“) a jiný nabízím jako šifrovací certifikát

 

 

Následující příklad jsem odchytil MS Network Monitorem (programem „Sledování sítě“). Některé pro nás nepodstatné SMTP hlavičky jsem vypustil, aby se příklad stal přehlednějším; obdobně z šifrované odpovědi vždy uvádím jen začátky a konce šifrované zprávy, protože zpráva je šifrována a tudíž pro nás nedostupná:

 

From: =?iso-8859-2?Q?Libor Dost=E1lek?= <dostalek@pvt.cz>

To: test@t1.pvt.cz

Subject: Test

Date: Wed, 28 Mar 2001 14:26:22 +0200

MIME-Version: 1.0

Content-Type: multipart/signed; protocol=application/x-pkcs7-signature;

   micalg=SHA1; boundary=----=_NextPart_000_000E_01C0B792.D987AE70

 

Toto je zpráva ve formátu MIME obsahující více částí

------=_NextPart_000_000E_01C0B792.D987AE70

Content-Type: text/plain; charset=iso-8859-2

Content-Transfer-Encoding: 7bit

 

------=_NextPart_000_000E_01C0B792.D987AE70

Content-Type:.application/x-pkcs7-signature; name=smime.p7s

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7s

 

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFrzCCApYw

ggH/oAMCAQICAwHgEjANBgkqhkiG9w0BAQQFADBdMQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZU

IGEucy4xETAPBgNVBAsTCDIwMDAwOTAxMSgwJgYDVQQDEx9DZXJ0aWZpa2FjbmkgYXV0b3JpdGEg

SS5DQSAwMDA5MB4XDTAxMDIxMjEwNDA1MVoXDTAxMDgxNDEwNDA1MVowdDELMAkGA1UEBhMCQ1ox

ETAPBgNVBAoTCFBWVCBhLnMuMRkwFwYDVQQLExBDZXNrZSBCdWRlam92aWNlMRcwFQYDVQQDEw5M

aWJvciBEb3N0YWxlazEeMBwGCSqGSIb3DQEJARYPZG9zdGFsZWtAcHZ0LmN6MIGfMA0GCSqGSIb3

DQEBAQUAA4GNADCBiQKBgQCt55MtKxB4DBfiiNe9xLT0Ob8yOSRg8WF/sf5ZlsE6XQ3i43mNbu7D

dB36FxwCwW4/DhflodSVpTU0gFy0lxehwZQWKjIRjj5Y3eiiEAMcC+z+g51HBqyfp1GAaAetGtry

Te4e/1j7iF1UhSPVeCmQ21+s260rApB/BxfQQHDmKwIDAQABo00wSzBJBgNVHR8EQjBAMB6gHKAa

hhhodHRwOi8vY2EuaWNhLmN6L2NybC5jZ2kwHqAcoBqGGGh0dHA6Ly9wcy5pcGIuY3ovY3JsLmNn

aTANBgkqhkiG9w0BAQQFAAOBgQAoCsrTM+GR1LuY9dH7qlkYdf1HppTkxPXfS/YBJ+dov9kaqS91

2ljY/XrbJla6DOmzXLduxxNfCHy8+zt8zchbal2oy+vv3EsEaAYhywL8NVt8ohgNkY0spXgsszQ3

8Ibi0vnEX54OJw9AQ6oBQd5G7OR4DLkUqp9/OCqNThw86zCCAxEwggJ6oAMCAQICAwEnezANBgkq

hkiG9w0BAQUFADBOMQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZUIGEucy4xEDAOBgNVBAMTB0NB

LVBWVDExGjAYBgkqhkiG9w0BCQEWC29wZXJAaWNhLmN6MB4XDTAxMDMyODExNDAzOVoXDTAxMDQx

MTExNDAzOVowgYcxCzAJBgNVBAYTAkNaMRQwEgYDVQQIEwtOZXRvbGlja2EgOTEZMBcGA1UEBxMQ

Q2Vza2UgQnVkZWpvdmljZTEMMAoGA1UEChMDUFZUMRkwFwYDVQQDExBMaWJvciBEb3N0YWxlayBY

MR4wHAYJKoZIhvcNAQkBFg9kb3N0YWxla0BwdnQuY3owgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ

AoGBAKkyXYzBIR7BZ6pqm5zW6k++ZBtDcHyyLz/EgmrDURHG/QkQA0/c9HV3ZAxk08LePWjJHINL

PD0XAQjQNA1qtRiMCatEucsgHMxbG/UYYII1h/x32v/UCghvnTQrihfE86uxtJhOb6z1JdUBNbM2

hZsKtkWbsKWGjVtyCVBpaXlNAgMBAAGjgcIwgb8wXQYDVR0fBFYwVDAooCagJIYiaHR0cDovL2Nh

LmljYS5jei9jcmwuY2dpP2FrY2U9dGVzdDAooCagJIYiaHR0cDovL3BzLmlwYi5jei9jcmwuY2dp

P2FrY2U9dGVzdDBeBgNVHSAEVzBVMFMGCisGAQQBs2EBAQMwRTBDBggrBgEFBQcCAjA3GjVKZW4g

cHJvIFRFU1RPVkFDSSB1Y2VseS4gKE9ubHkgZm9yIFRFU1RJTkcgcHVycG9zZXMuKTANBgkqhkiG

9w0BAQUFAAOBgQArrPlP8EAFFRLm1KNRVijffV6JoU1G92d2At365V+7SFSRT9OfZ/Op1VaVHQ1K

ZLObW0of4kbT06Ma0ZucgjjBUNz2rT/OXgMDis8Xxy+1zjfQaRIyPxxoBPd81168Id/7rLYgE6QE

4CXuOEKu6M/o30BzGJT6FzYgR3IlwMgauDGCAiswggInAgEBMFUwTjELMAkGA1UEBhMCQ1oxETAP

BgNVBAoTCFBWVCBhLnMuMRAwDgYDVQQDEwdDQS1QVlQxMRowGAYJKoZIhvcNAQkBFgtvcGVyQGlj

YS5jegIDASd7MAkGBSsOAwIaBQCgggEsMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI

hvcNAQkFMQ8XDTAxMDMyODEyMjQ1MFowIwYJKoZIhvcNAQkEMRYEFB9V213GmaU8a7KB5N9oB5Si

qWCAMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH

MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwXTEL

MAkGA1UEBhMCQ1oxETAPBgNVBAoTCFBWVCBhLnMuMREwDwYDVQQLEwgyMDAwMDkwMTEoMCYGA1UE

AxMfQ2VydGlmaWthY25pIGF1dG9yaXRhIEkuQ0EgMDAwOQIDAeASMA0GCSqGSIb3DQEBAQUABIGA

LxMWzzhYRNuUbdWe2NX1HR9IxK/A5XT0hAFGNTIPD4qvrg0g0Y9oOJw7QTnqMS8bhzhdfeY5VIrf

Q2Cq+qJDDd6EuXXbjL2AkkcQ9Zz+L3rJTwCzMrMnIfuxK0oL8oxfgYLEOpqA96ojVmdR3V2owxNn

XaTw6CneV0la/gWXY3UAAAAAAAA=

 

------=_NextPart_000_000E_01C0B792.D987AE70—-

 

 

·         Vnější obálkou CMS zprávy je sekvence skládající se z identifikátoru objektu specifikujícího typ zprávy a obsahu zprávy, jenž je typu „specifická 0“ (viz obr. 8-16):

SEQUENCE         

    30 80

  OBJECT            :pkcs7-signedData

     06 09 2a 86 48 86 f7 0d 01 07 02

  cont [ 0 ]       

     a0 80

 

·         CMS zpráva SignedData je sekvence začínají verzí:

   SEQUENCE         

      30 80

    INTEGER           :01

       02 01 01

 

·         Další položkou CMS zprávy SignedData je množina algoritmů použitých pro výpočet kontrolního součtu:

    SET              

       31 0b

     SEQUENCE         

        30 09

      OBJECT            :sha1

         06 05 2b 0e 03 02 1a

      NULL             

         05 00

 

·         Dále následuje položka s podepisovanými daty. V našem případě je prázdná, tj. jedná se buď o externí podpis nebo o degenerovanou zprávu SignedData:

    SEQUENCE         

       30 80

     OBJECT            :pkcs7-data

        06 09 2a 86 48 86 f7 0d 01 07 01

     EOC              

        00 00

 

·         Dále následuje položka typu „specifická 0“ obsahující množinu certifikátů:

    cont [ 0 ]       

       a0 82 05 af

     SEQUENCE         

        30 82 02 96

 

·         První certifikát (CN = Libor Dostalek)

      SEQUENCE         

         30 82 01 ff

       cont [ 0 ]       

          a0 03

        INTEGER           :02

           02 01 02

       INTEGER           :01E012

          02 03 01 e0 12

       SEQUENCE         

          30 0d

        OBJECT            :md5WithRSAEncryption

           06 09 2a 86 48 86 f7 0d 01 01 04

        NULL             

           05 00

       SEQUENCE         

          30 5d

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :20000901

             13 08 32 30 30 30 30 39 30 31

        SET              

           31 28

         SEQUENCE         

            30 26

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Certifikacni autorita I.CA 0009

             13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

             69 74 61 20 49 2e 43 41 20 30 30 30 39

       SEQUENCE         

          30 1e

        UTCTIME           :010212104051Z

           17 0d 30 31 30 32 31 32 31 30 34 30 35 31 5a

        UTCTIME           :010814104051Z

           17 0d 30 31 30 38 31 34 31 30 34 30 35 31 5a

       SEQUENCE         

          30 74

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

        SET              

           31 19

         SEQUENCE         

            30 17

          OBJECT            :organizationalUnitName

             06 03 55 04 0b

          PRINTABLESTRING   :Ceske Budejovice

             13 10 43 65 73 6b 65 20 42 75 64 65 6a 6f 76 69 63 65

        SET              

           31 17

         SEQUENCE         

            30 15

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Libor Dostalek

             13 0e 4c 69 62 6f 72 20 44 6f 73 74 61 6c 65 6b

        SET              

           31 1e

         SEQUENCE          

            30 1c

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :dostalek@pvt.cz

             16 0f 64 6f 73 74 61 6c 65 6b 40 70 76 74 2e 63 7a

       SEQUENCE         

          30 81 9f

        SEQUENCE         

           30 0d

         OBJECT            :rsaEncryption

            06 09 2a 86 48 86 f7 0d 01 01 01

         NULL             

            05 00

        BIT STRING       

           03 81 8d 00 30 81 89 02 81 81 00 ad e7 93 2d 2b 10 78 0c 17

           e2 88 d7 bd c4 b4 f4 39 bf 32 39 24 60 f1 61 7f b1 fe 59 96

           c1 3a 5d 0d e2 e3 79 8d 6e ee c3 74 1d fa 17 1c 02 c1 6e 3f

           0e 17 e5 a1 d4 95 a5 35 34 80 5c b4 97 17 a1 c1 94 16 2a 32

           11 8e 3e 58 dd e8 a2 10 03 1c 0b ec fe 83 9d 47 06 ac 9f a7

           51 80 68 07 ad 1a da f2 4d ee 1e ff 58 fb 88 5d 54 85 23 d5

           78 29 90 db 5f ac db ad 2b 02 90 7f 07 17 d0 40 70 e6 2b 02

           03 01 00 01

       cont [ 3 ]       

          a3 4d

        SEQUENCE         

           30 4b

         SEQUENCE         

            30 49

          OBJECT            :X509v3 CRL Distribution Points

             06 03 55 1d 1f

          OCTET STRING     

             04 42 30 40 30 1e a0 1c a0 1a 86 18 68 74 74 70 3a 2f 2f 63

             61 2e 69 63 61 2e 63 7a 2f 63 72 6c 2e 63 67 69 30 1e a0 1c

             a0 1a 86 18 68 74 74 70 3a 2f 2f 70 73 2e 69 70 62 2e 63 7a

             2f 63 72 6c 2e 63 67 69

      SEQUENCE         

         30 0d

       OBJECT            :md5WithRSAEncryption

          06 09 2a 86 48 86 f7 0d 01 01 04

       NULL             

          05 00

      BIT STRING       

         03 81 81 00 28 0a ca d3 33 e1 91 d4 bb 98 f5 d1 fb aa 59 18

         75 fd 47 a6 94 e4 c4 f5 df 4b f6 01 27 e7 68 bf d9 1a a9 2f

         75 da 58 d8 fd 7a db 26 56 ba 0c e9 b3 5c b7 6e c7 13 5f 08

         7c bc fb 3b 7c cd c8 5b 6a 5d a8 cb eb ef dc 4b 04 68 06 21

         cb 02 fc 35 5b 7c a2 18 0d 91 8d 2c a5 78 2c b3 34 37 f0 86

         e2 d2 f9 c4 5f 9e 0e 27 0f 40 43 aa 01 41 de 46 ec e4 78 0c

         b9 14 aa 9f 7f 38 2a 8d 4e 1c 3c eb

 

·         Druhý certifikát (CN = Libor Dostalek X)

     SEQUENCE         

        30 82 03 11

      SEQUENCE         

         30 82 02 7a

       cont [ 0 ]        

          a0 03

        INTEGER           :02

           02 01 02

       INTEGER           :01277B

          02 03 01 27 7b

       SEQUENCE         

          30 0d

        OBJECT            :sha1WithRSAEncryption

           06 09 2a 86 48 86 f7 0d 01 01 05

        NULL             

           05 00

       SEQUENCE         

          30 4e

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

        SET              

           31 10

         SEQUENCE         

            30 0e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :CA-PVT1

             13 07 43 41 2d 50 56 54 31

        SET              

           31 1a

         SEQUENCE         

            30 18

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :oper@ica.cz

             16 0b 6f 70 65 72 40 69 63 61 2e 63 7a

       SEQUENCE         

          30 1e

        UTCTIME           :010328114039Z

           17 0d 30 31 30 33 32 38 31 31 34 30 33 39 5a

        UTCTIME           :010411114039Z

           17 0d 30 31 30 34 31 31 31 31 34 30 33 39 5a

       SEQUENCE         

          30 81 87

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 14

         SEQUENCE         

            30 12

          OBJECT            :stateOrProvinceName

             06 03 55 04 08

          PRINTABLESTRING   :Netolicka 9

             13 0b 4e 65 74 6f 6c 69 63 6b 61 20 39

        SET              

           31 19

         SEQUENCE         

            30 17

          OBJECT            :localityName

             06 03 55 04 07

          PRINTABLESTRING   :Ceske Budejovice

             13 10 43 65 73 6b 65 20 42 75 64 65 6a 6f 76 69 63 65

        SET              

           31 0c

         SEQUENCE         

            30 0a

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT

             13 03 50 56 54

        SET              

           31 19

         SEQUENCE         

            30 17

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :Libor Dostalek X

             13 10 4c 69 62 6f 72 20 44 6f 73 74 61 6c 65 6b 20 58

        SET              

           31 1e

         SEQUENCE         

            30 1c

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :dostalek@pvt.cz

             16 0f 64 6f 73 74 61 6c 65 6b 40 70 76 74 2e 63 7a

       SEQUENCE         

          30 81 9f

        SEQUENCE         

           30 0d

         OBJECT            :rsaEncryption

            06 09 2a 86 48 86 f7 0d 01 01 01

         NULL              

            05 00

        BIT STRING       

           03 81 8d 00 30 81 89 02 81 81 00 a9 32 5d 8c c1 21 1e c1 67

           aa 6a 9b 9c d6 ea 4f be 64 1b 43 70 7c b2 2f 3f c4 82 6a c3

           51 11 c6 fd 09 10 03 4f dc f4 75 77 64 0c 64 d3 c2 de 3d 68

           c9 1c 83 4b 3c 3d 17 01 08 d0 34 0d 6a b5 18 8c 09 ab 44 b9

           cb 20 1c cc 5b 1b f5 18 60 82 35 87 fc 77 da ff d4 0a 08 6f

           9d 34 2b 8a 17 c4 f3 ab b1 b4 98 4e 6f ac f5 25 d5 01 35 b3

           36 85 9b 0a b6 45 9b b0 a5 86 8d 5b 72 09 50 69 69 79 4d 02

           03 01 00 01

       cont [ 3 ]       

          a3 81 c2

        SEQUENCE         

           30 81 bf

         SEQUENCE         

            30 5d

          OBJECT            :X509v3 CRL Distribution Points

             06 03 55 1d 1f

          OCTET STRING     

             04 56 30 54 30 28 a0 26 a0 24 86 22 68 74 74 70 3a 2f 2f 63

             61 2e 69 63 61 2e 63 7a 2f 63 72 6c 2e 63 67 69 3f 61 6b 63

             65 3d 74 65 73 74 30 28 a0 26 a0 24 86 22 68 74 74 70 3a 2f

             2f 70 73 2e 69 70 62 2e 63 7a 2f 63 72 6c 2e 63 67 69 3f 61

             6b 63 65 3d 74 65 73 74

         SEQUENCE         

            30 5e

          OBJECT            :X509v3 Certificate Policies

             06 03 55 1d 20

          OCTET STRING     

             04 57 30 55 30 53 06 0a 2b 06 01 04 01 b3 61 01 01 03 30 45

             30 43 06 08 2b 06 01 05 05 07 02 02 30 37 1a 35 4a 65 6e 20

             70 72 6f 20 54 45 53 54 4f 56 41 43 49 20 75 63 65 6c 79 2e

             20 28 4f 6e 6c 79 20 66 6f 72 20 54 45 53 54 49 4e 47 20 70

             75 72 70 6f 73 65 73 2e 29

      SEQUENCE         

         30 0d

       OBJECT            :sha1WithRSAEncryption

          06 09 2a 86 48 86 f7 0d 01 01 05

       NULL              

          05 00

      BIT STRING       

         03 81 81 00 2b ac f9 4f f0 40 05 15 12 e6 d4 a3 51 56 28 df

         7d 5e 89 a1 4d 46 f7 67 76 02 dd fa e5 5f bb 48 54 91 4f d3

         9f 67 f3 a9 d5 56 95 1d 0d 4a 64 b3 9b 5b 4a 1f e2 46 d3 d3

         a3 1a d1 9b 9c 82 38 c1 50 dc f6 ad 3f ce 5e 03 03 8a cf 17

         c7 2f b5 ce 37 d0 69 12 32 3f 1c 68 04 f7 7c d7 5e bc 21 df

         fb ac b6 20 13 a4 04 e0 25 ee 38 42 ae e8 cf e8 df 40 73 18

         94 fa 17 36 20 47 72 25 c0 c8 1a b8

 

·         Jelikož za touto položkou následují další položky, tak se nejedná o degenerovanou zprávu SignedData. Následující položka není typu „specifická 1“, takže se již musí jednat o množinu elektronických podpisů:

    SET              

       31 82 02 2b

 

·         První elektronický podpis:

     SEQUENCE         

        30 82 02 27

      INTEGER           :01 (Verze struktury signerInfo)

         02 01 01

 

·         Následuje identifikace certifikátu určeného k verifikaci elektronického podpisu. Jelikož je verze 1, tak je certifikát určen jedinečným jménem vydavatele a číslem certifikátu:

      SEQUENCE         

         30 55

       SEQUENCE         

          30 4e

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

        SET              

           31 10

         SEQUENCE         

            30 0e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :CA-PVT1

             13 07 43 41 2d 50 56 54 31

        SET              

           31 1a

         SEQUENCE         

            30 18

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :oper@ica.cz

             16 0b 6f 70 65 72 40 69 63 61 2e 63 7a

       INTEGER           :01277B

          02 03 01 27 7b

 

·         Následuje algoritmus použitý pro výpočet kontrolního součtu:

      SEQUENCE         

         30 09

       OBJECT            :sha1

          06 05 2b 0e 03 02 1a

       NULL             

          05 00

 

·         Jelikož je následující položka typu „specifická 0“, tak se jedná o podepisované atributy:

      cont [ 0 ]       

         a0 82 01 2c

 

·         Prvním podepisovaným atributem je atribut contentType:

       SEQUENCE         

          30 18

        OBJECT            :contentType

           06 09 2a 86 48 86 f7 0d 01 09 03

        SET              

           31 0b

         OBJECT            :pkcs7-data

            06 09 2a 86 48 86 f7 0d 01 07 01

 

·         Druhým podepisovaným atributem je datum a čas podpisu (atribut signingTime):

       SEQUENCE         

          30 1c

        OBJECT            :signingTime

           06 09 2a 86 48 86 f7 0d 01 09 05

        SET              

           31 0f

         UTCTIME           :010328122450Z

            17 0d 30 31 30 33 32 38 31 32 32 34 35 30 5a

 

·         Třetím podepisovaným atributem je kontrolní součet ze zasílané zprávy (atribut messageDigest):

       SEQUENCE         

          30 23

        OBJECT            :messageDigest

           06 09 2a 86 48 86 f7 0d 01 09 04

        SET              

           31 16

         OCTET STRING     

            04 14 1f 55 db 5d c6 99 a5 3c 6b b2 81 e4 df 68 07 94 a2 a9

            60 80

 

·         Dalším podepisovaným atributem je atribut smimeCapabilities:

       SEQUENCE         

          30 58

        OBJECT            :1.2.840.113549.1.9.15

           06 09 2a 86 48 86 f7 0d 01 09 0f

        SET              

           31 4b

         SEQUENCE         

            30 49

          SEQUENCE          

             30 0a

           OBJECT            :des-ede3-cbc

              06 08 2a 86 48 86 f7 0d 03 07

          SEQUENCE         

             30 0e

           OBJECT            :rc2-cbc

              06 08 2a 86 48 86 f7 0d 03 02

           INTEGER           :80

              02 02 00 80

          SEQUENCE         

             30 07

           OBJECT            :des-cbc

              06 05 2b 0e 03 02 07

          SEQUENCE         

             30 0d

           OBJECT            :rc2-cbc

              06 08 2a 86 48 86 f7 0d 03 02

           INTEGER           :28

              02 01 28

          SEQUENCE         

             30 07

           OBJECT            :sha1

              06 05 2b 0e 03 02 1a

          SEQUENCE         

             30 0a

           OBJECT            :md5

              06 08 2a 86 48 86 f7 0d 02 05

 

·         Další podepisovaný parametr je přidán tvůrcem programu – firmou Microsoft, protože 1.3.6.1.4.1.311 je OID pro Microsoft (obsahuje jedinečné jméno CA a číslo šifrovacího certifikátu), nepochopil jsem však, jaký je rozdíl mezi tímto podepisovaným atributem a atributem sMIMEEncryptionKeyPreference):

       SEQUENCE         

          30 73

        OBJECT            :1.3.6.1.4.1.311.16.4

           06 09 2b 06 01 04 01 82 37 10 04

        SET              

           31 66

         SEQUENCE         

            30 64

          SEQUENCE         

             30 5d

           SET              

              31 0b

            SEQUENCE         

               30 09

             OBJECT            :countryName

                06 03 55 04 06

             PRINTABLESTRING   :CZ

                13 02 43 5a

           SET              

              31 11

            SEQUENCE         

               30 0f

             OBJECT            :organizationName

                06 03 55 04 0a

             PRINTABLESTRING   :PVT a.s.

                13 08 50 56 54 20 61 2e 73 2e

           SET              

              31 11

            SEQUENCE         

               30 0f

             OBJECT            :organizationalUnitName

                06 03 55 04 0b

             PRINTABLESTRING   :20000901

                13 08 32 30 30 30 30 39 30 31

           SET              

              31 28

            SEQUENCE         

               30 26

             OBJECT            :commonName

                06 03 55 04 03

             PRINTABLESTRING   :Certifikacni autorita I.CA 0009

                13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

                69 74 61 20 49 2e 43 41 20 30 30 30 39

          INTEGER           :01E012

             02 03 01 e0 12

 

·         Poslední položkou je vlastní elektronický podpis:

      SEQUENCE         

         30 0d

       OBJECT            :rsaEncryption

          06 09 2a 86 48 86 f7 0d 01 01 01

       NULL             

          05 00

      OCTET STRING     

         04 81 80 2f 13 16 cf 38 58 44 db 94 6d d5 9e d8 d5 f5 1d 1f

         48 c4 af c0 e5 74 f4 84 01 46 35 32 0f 0f 8a af ae 0d 20 d1

         8f 68 38 9c 3b 41 39 ea 31 2f 1b 87 38 5d 7d e6 39 54 8a df

         43 60 aa fa a2 43 0d de 84 b9 75 db 8c bd 80 92 47 10 f5 9c

         fe 2f 7a c9 4f 00 b3 32 b3 27 21 fb b1 2b 4a 0b f2 8c 5f 81

         82 c4 3a 9a 80 f7 aa 23 56 67 51 dd 5d a8 c3 13 67 5d a4 f0

         e8 29 de 57 49 5a fe 05 97 63 75

 

·         Za poslední položkou ještě následují konce položek nedefinované délky, tj. zpráva je kódována v BER (nikoliv v DER)

    EOC              

       00 00

   EOC              

      00 00

  EOC              

     00 00

10.5.1 Příklad šifrované zprávy

From: =?iso-8859-2?Q?Hana_Kimovi=E8ova?= test@t1.pvt.cz

To: =?iso-8859-2?Q?Libor_Dost=E1lek?= dostalek@pvt.cz

Subject: Re: Test Date: Wed, 28 Mar 2001 14:31:12 +0200

MIME-Version: 1.0

Content-Type: application/x-pkcs7-mime;

  smime-type=enveloped-data;name=smime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

 

MIAGCSqGSIb3DQEHA6CAMIACAQAxggHeMIHsAgEAMFUwTjELMAkGA1UEBhMCQ1oxETAPBgNVBAoT

CFBWVCBhLnMuMRAwDgYDVQQDEwdDQS1QVlQxMRowGAYJKoZIhvcNAQkBFgtvcGVyQGljYS5jegID

ASd7MA0GCSqGSIb3DQEBAQUABIGAIlREhu050s38c4UFIbWAQOy9ssIy6YjR8KzYMtNJjRiA3j6B

a45GfvfndS9Xm5L8Pa+/QKsj1M6OGfcTSBnLYz80B6By2TiyuospN5w/FZF3jyL2ZMovdipCeafm

QSCeKslLgxG1obORkzt8GwqftsvEEr4wt2FhO6PB4O1jmugwgewCAQAwVTBOMQswCQYDVQQGEwJD

WjERMA8GA1UEChMIUFZUIGEucy4xEDAOBgNVBAMTB0NBLVBWVDExGjAYBgkqhkiG9w0BCQEWC29w

ZXJAaWNhLmN6AgMBJ38wDQYJKoZIhvcNAQEBBQAEgYCYuSkQioVgDX3oulYtSAxJJ01+Iu7j9ktU

nKogWRmOTNsdgJbHHDU4/gnVHWuFXo1nDCERPRVsI40+B86fwL9HVYpKSxq45Xk3poRX3uz3Dypb

ZhuK3nZiXhlMee0seymEnrw88tPUdYJC16nJmoBHar37+op1UwHkhbxpxtkUpjCABgkqhkiG9w0B

BwEwFAYIKoZIhvcNAwcECCh+HsAAESWwoIAEggQAs942sXA0U1QWAeKWcH9vqDNyG7MXBT2I+5Jj

TT3jAXUadc1ZTOttS2wrX8oa8W4Fv3tEovxlFW522lJOIXKNfX6EauG29FbfyZ9CGv2kHlpxo4q1

iNDUFwR7Pmf962UxCeJBzOYXht6MFwcXdMGem9hD+lZi1MPYNj03IceNF80b3yAm+BlNdKoSj/1n

VN1IBpkFYaSG/LdWcmDdp/j+R/TTjX2NFdV699Ii4kuRazOCi0ksXpHocly+js07hZmAnSMuAgUa

PBsEKFLmZGIFeG75VnpYvSE30eEw5ulaIVQoYbdVVu/JWrEyOz/glC67PihQ3D8oHEwML103HUbm

jJH98UCS8qiw9QUX5taFxlmnZ0uMRh6zSo5fqWenHWPbx5LWBx6JSyc7CHqH251zbW6Nmr1EUlm6

wEa1Kr2TDjvHdQMAA1PeQfoxtAA8OvCxyNOzVX7wIsWpFvaSbnBTVNEZKsC1XhzHNelZCNW5TqXg

ZcElW1TXtPXXchzAF/PhL9OIo+2Hx02gkGMww+6T+OwhKznQC8qOf2wbWHUCUNyCMo30LWMmamVt

Edy5l+6H8xdQbOM8bbTtG+HubRNAAatub9Hoi8eC3eP/7u+PUAX15ZusHlDMpzG/q7Gai+NryFWG

qx6PI3KF3dt8ncEGsOWsaBGxxPBiqocrs76fKskqp1aMXBL3Go1bScPHnzHuxoA0i/QU/96W/NTv

lDc1vyZ3kAmvhSDZCr5FaT5zLyMxPaeOkK7Y1YYEkKIBsYsgKFqiezZbvDxvO98TEnytFvq33cxi

7GtcefMpD+vGkfLbFGtgObrNsQQw4osD7KyVonYlsd58zzGkNEUMRNI4fHE8nctd0V2WRO1J+B8P

4B5CEKMyTFtmzZ74r2SwuSqw1pgDVBMLeO52ph21ZIq73JV8kWVmiba0FcET7xoLZ1Df/Qp1/1oA

357A1NKPCRmQ55VaLJqiIUfhVm9+N5/qmnJFIdczFUcqPp+eYdUvR7ZiSSXp4RGpMb0uwihNvYXk

Oit8iXANvahZPFN3DWQpa3kqohyhbuuNwWiABdj24ulyO3ggg6LV6bfA3m1E7eAusLWasU3LBMR2

SflgcXrsaOUNXNswBcBOwahzhhM8IhjyXt60USajqcjY7n1bpajtB6D7rTO9crPt06Ul8NMTEDL2

3OwmKYsxKnP3jklgCDkZtgMwhJkyovECjMrNIRPnKXoyWPlCegk1w0F1dgchk2ExU+akSKn59Sis

3nfBR+Q10K4DEOrenHjZ4qjGfw004Rna0MSngGmgehTxQTYXtLkSQekpViiPzs/KrhH5iIRGF/hb

ltXIIsLcNxelwcGijibMpi+GFrsVLX8G7dxmCgSCBACbix0wAaaBuAHRQCahAaAWQCtxdtRUQdWU

V6ZhPIzgZYeHeDmBcgaAuv+kId1DaPIcnYrd769gmDZbDF4tIRLkyAP2mPyjfbVGZT1/amwCHp7b

YPi+NECBE9V6r7BDlrCx4Ok6u0w3V/g0+6LndFaS7mZBn0a8hFMWtqN2Pu/QR6I+xywyld+KLpUo

ZnRTd/jplRtfwvzdEkUvHA4mCD51dq0D01t8Gwbv9hNlkSM3KCjhK1QXCrbFRTxA0blD7sVaMoDV

aRVzfoi+1wimmaAlzeISnxDNiglBM6Y2lThnIEdKSRKx+vDFmfOX3JxrboYrejoiclqkj6rdChoY

v9i2HggxuQtiwPAtLMejzse9ckZ8n5StJ8F1BgyDK3BY5UyDTKkIq9ACoRkNHbeB9iDGAq9MPjdm

5m3x313VWVsmZKV1146i3PzsLzuxdWdO95feRMUzfMu06O42dpr03NZnFpigZniBLmYr6umU3K55

6RbK8phJI1Zn1ZftZdFTTs2zQC+LQ/m8hX5vhPB8PjBgnFfeJlZ4Xry3K7G0lncUkyi2AucnDIC+

4zHPn3yV7MJVUgotW9k04Ms0dy3Fz+YRJRCL2eW5c6VwohfV9quZ+4PrxrZhYyW8gRIYATTmE1gu

G5reukchJ1lAaO4ATaw1Fm87fFC3Es+U/J2kQnNtKG0fMXOYIHbjis3iC8ok1K7xLqCN1hjAJjlo

jwpyLuLvW9ocb8ZInX0QMfCFAO90Qb/sJKBdqZG71oh5u6aezBRvw3a+i1QdAXy2nHd0ENx1JI7Q

pecLrFu0goX1uOHmn6Thy4+CE9dybUdbM4HJvT5trQVWPDMdWEIw5taa+GvQc0jTOC7uqUL9wKjO

fxVrBbQYltbyw9lkv0b1pNglhMimrumMRGv4Nd+Evpgl4XdW01AnY7R4kRiXqsO7XbpDxYV+d3JM

7Rymu2X49IOPXh4/794duQ8PAEwCuBj/kPPqaN9uZ+6HUNLF69O6LrSrPRQrAtWcUr5SXhZnKE2v

ivTc54GuE54Zj0Um3jhN4cZRg9C5yQ5KJ67xjSPbs0nPwqPnNVakpyQ0QA0JrR8RS7alsb8fYJjO

BRDGlIqE4y0hQSCWXs+Fc1+uwaUIFxfIvxmwrcq1knz25LBtnY/qgumul+6VUq5nONfOk2R0D1SL

TQlKpbBxkZb6bA/5WFTk+vRmUAJ6QMSJYYNoKiLBClB0knXEOiELf84IXAX/JuNAmdZqK39Ng5Vw

nV0l3sPRsaJ+heYm2mnhBiJ9gtKOZqgb6sfoPvw8m2hDq5jVWmDHVVS9GPcw3krBsS36vwx8eXiK

5goJNt905qZtT43+lOcqGg068ba8cRk4Dat99m+tBIIEAIBQyt9tuwdofqmTijf5CQCJ+VVGHUK0

JQcP7x/w29XoYALXdhZYYGw+4x+/8lNArEK/Sju+rdEo7hORo4aEHCxD+PXcxjLUvPjcHzA8UYcJ

z6BE4fzVhEvAXgUsllfGMlk1u7N/4qpjsy6Fls8JZq375V6NUN9e6Ya3Zf3SgqcjdXWKvtszbFSJ

SIQ43DINAw3gh57vb22cnWrfvu8ugTXsUpqPjsq2ACtEVvGd/uHAUSTcsaJ5C1Fh5yroq1cFDSfH

Cd2egepCW4PB1YHFTvhIJJ+9YoffDTMp7VQN+Z5bJQjci6Bx6qkG4YroE8F7MNt4IwFu9AHn+DbR

qGfMD/qvhGVlb7ExGNIXKbukjKFeA7mSA+i/OhEmsEdMPjFeTbJXj90kDysNhKbPkPeKqAwVPuhe

i/DPNRA2v7/3Q/lPQKPQzek4KX/nnuNEXKLqoxNK2Atp5lwPedZw6Jjf1QVox12tYWM73QtXGECI

pYAabaLI/Um/cWLQv0bGjddvQn93QKRBFtrnZEjykV6nM2LVjsWukMETRmELyxFcPuAbPPCl5Mld

yb1uDfVqnE5sB0P4Hwseo5cKAHC+7Nf3VX77zWIC+GQJnWogFRIoES+Li8oO+YY5kzUnTNr1VNlT

XxS8FyruetbhCnbD0WDDWpSIFB7QUJI/vSe7pgg1XrBroJeIM94ZBuZ9n7U0vU/lS6YXuToNhO8f

eBlfjT3q2fqgvp7Faue9l91oiYU6I97+X1t+63AXscn5GivS8+NDkrczjpmh6eRPy9cULYzGP12k

EQ55xkQQw+4gNNTEgOFd9pcvqbfHt78cdlYMtPBVlYkP4srFhh64ZdWBCbYtJhEFdhvIOX4JYENR

/zsoaHBMbH8IHR70qYgoEV5sOC5hfhYpkPh00JZgUs+Slz8U8fj5yfTIVuc5vlOkn17+c8jsQGoy

laGfvF8eb3giQ34yZeykRcCHqEAO1ynQe4E6ZJzhzPUkPMf/Y4UbpdBORe/nmu1WOPm0PoiRON61

d3W5IamIlEKUWMgXSom37vPaQdVvOF9UwmapOOFhIyacx4eGAt+/a099fps//LNlPD9sFUM1sABW

42f4zthkU/Nk4Cr14UKpPONtXeKgg9qrzSzGBi2joN+yryclSWq6jfLYwASAggEXdzQFM71bbvnb

rW9Itda3vXSLIjhdP0rdOR1OUL+R8EbaWerTxq5bMdyuI9ECcTZzYMkN3bLuE5af4P42lPkwz3Jh

UNo2oqxEVxKFPJox1Sbg2VPwqElp3mnG+BVnxVkBwR7eDKyYhQYFkMO1o3DqK74PHCEQGB5NXNM5

egqPo0v4rHhLR1XMsWOtVr4NtMqbS/NMxLQ37K0+lcoEggEIMGbG92Rl1Bh+lvGAiGvYr3e0x0EV

8psce8NVo9tLJMZ3Kmo4trEXDqM8M3Wuf6J/Hl8TY/MFpyGakygFpOV7VUucSgtbSi9KpcThR3Gt

0YvJUDpz3f8OYIY5udxbMq0XWrOf9EBt16WaSH5jcgV3/T8w9deM+9EfT0+3CWob/TTSEwMgHqQ+

BiBXLdukGvUZD+kNUQxOeRfQVCWYgAYCpgCTUVEvsWjY41Ibf4CMIc3UKoZAIsT3WJHDLuV6Sls/

Ae+Hf9hqN2KzvuUlnqIcT/zClbLeyjDE99YdU0EtMtARtvpQFT4mTw6fGnLhUFEgw32Zi119eUho

mm2DMZrFaXgJcuLXMeaaAAAAAAAAAAAAAA==

.

 

·         Vnější obálkou CMS zprávy je sekvence skládající se z identifikátoru objektu specifikujícího typ zprávy a obsahu zprávy, jenž je typu „specifická 0“ (viz obr. 8-16):

 SEQUENCE         

    30 80

  OBJECT            :pkcs7-envelopedData

     06 09 2a 86 48 86 f7 0d 01 07 03

  cont [ 0 ]       

     a0 80

 

·         Obsah zprávy obsahuje jako první položku verzi. Jelikož je nula, tak se v podstatě jedná o zprávu PKCS#7.

   SEQUENCE         

      30 80

    INTEGER           :00 

       02 01 00

 

·         Dále následuje množina recipientInfos obsahující jednotlivé struktury recipientInfo:

    SET              

       31 82 01 de

 

·         První výskyt struktury recipientInfo:

     SEQUENCE         

        30 81 ec

      INTEGER           :00 (verze = 0)

         02 01 00

 

·         Dále následuje položka issuerAndSerialNumber obsahující identifikaci certifikátu, jehož veřejný klíč je použit k šifrování symetrického klíče:

      SEQUENCE         

         30 55

       SEQUENCE          

          30 4e

        SET              

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET               

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

        SET              

           31 10

         SEQUENCE         

            30 0e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :CA-PVT1

             13 07 43 41 2d 50 56 54 31

        SET              

           31 1a

         SEQUENCE         

            30 18

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :oper@ica.cz

             16 0b 6f 70 65 72 40 69 63 61 2e 63 7a

       INTEGER           :01277B  (sériové číslo certifikátu)

          02 03 01 27 7b

 

·         Dále následuje specifikace asymetrického algoritmu, kterým je zašifrován symetrický šifrovací klíč:

      SEQUENCE         

         30 0d

       OBJECT            :rsaEncryption

          06 09 2a 86 48 86 f7 0d 01 01 01

       NULL             

          05 00

 

·         Dále následuje symetrický klíč zašifrovaný veřejným klíčem ze specifikovaného certifikátu:

      OCTET STRING     

         04 81 80 22 54 44 86 ed 39 d2 cd fc 73 85 05 21 b5 80 40 ec

         bd b2 c2 32 e9 88 d1 f0 ac d8 32 d3 49 8d 18 80 de 3e 81 6b

         8e 46 7e f7 e7 75 2f 57 9b 92 fc 3d af bf 40 ab 23 d4 ce 8e

         19 f7 13 48 19 cb 63 3f 34 07 a0 72 d9 38 b2 ba 8b 29 37 9c

         3f 15 91 77 8f 22 f6 64 ca 2f 76 2a 42 79 a7 e6 41 20 9e 2a

         c9 4b 83 11 b5 a1 b3 91 93 3b 7c 1b 0a 9f b6 cb c4 12 be 30

         b7 61 61 3b a3 c1 e0 ed 63 9a e8

 

·         Druhý výskyt struktury recipientInfo:

     SEQUENCE         

        30 81 ec

      INTEGER           :00  (verze = 0)

         02 01 00

 

·         Dále následuje položka issuerAndSerialNumber obsahující identifikaci certifikátu, jehož veřejný klíč je použit k šifrování symetrického klíče:

      SEQUENCE         

         30 55

       SEQUENCE         

          30 4e

        SET               

           31 0b

         SEQUENCE         

            30 09

          OBJECT            :countryName

             06 03 55 04 06

          PRINTABLESTRING   :CZ

             13 02 43 5a

        SET              

           31 11

         SEQUENCE         

            30 0f

          OBJECT            :organizationName

             06 03 55 04 0a

          PRINTABLESTRING   :PVT a.s.

             13 08 50 56 54 20 61 2e 73 2e

        SET              

           31 10

         SEQUENCE         

            30 0e

          OBJECT            :commonName

             06 03 55 04 03

          PRINTABLESTRING   :CA-PVT1

             13 07 43 41 2d 50 56 54 31

        SET              

           31 1a

         SEQUENCE         

            30 18

          OBJECT            :emailAddress

             06 09 2a 86 48 86 f7 0d 01 09 01

          IA5STRING         :oper@ica.cz

             16 0b 6f 70 65 72 40 69 63 61 2e 63 7a

       INTEGER           :01277F

          02 03 01 27 7f

 

·         Dále následuje specifikace asymetrického algortimu pro šifrování symetrického klíče:

      SEQUENCE         

         30 0d

       OBJECT            :rsaEncryption

          06 09 2a 86 48 86 f7 0d 01 01 01

       NULL             

          05 00

 

·         Dále následuje zašifrovaný symetrický klíč:

      OCTET STRING     

         04 81 80 98 b9 29 10 8a 85 60 0d 7d e8 ba 56 2d 48 0c 49 27

         4d 7e 22 ee e3 f6 4b 54 9c aa 20 59 19 8e 4c db 1d 80 96 c7

         1c 35 38 fe 09 d5 1d 6b 85 5e 8d 67 0c 21 11 3d 15 6c 23 8d

         3e 07 ce 9f c0 bf 47 55 8a 4a 4b 1a b8 e5 79 37 a6 84 57 de

         ec f7 0f 2a 5b 66 1b 8a de 76 62 5e 19 4c 79 ed 2c 7b 29 84

         9e bc 3c f2 d3 d4 75 82 42 d7 a9 c9 9a 80 47 6a bd fb fa 8a

         75 53 01 e4 85 bc 69 c6 d9 14 a6

 

·         Dále následuje vlastní šifrován zpráva, která je sekvencí identifikátoru objektu typu zprávy (v našem případě pkcs7-data), identifikace symetrického šifrovacího algoritmu včetně parametrů a případně  vlastní šifrované zprávy.

    SEQUENCE         

       30 80

     OBJECT            :pkcs7-data

        06 09 2a 86 48 86 f7 0d 01 07 01

     SEQUENCE         

        30 14

      OBJECT            :des-ede3-cbc

         06 08 2a 86 48 86 f7 0d 03 07

      OCTET STRING     

         04 08 28 7e 1e c0 00 11 25 b0

 

·         Ještě jsem oddělil vlastní šifrovanou zprávu, která je typu „specifická 0“. Jenže to, co následuje, je trik, který jsem si myslel, že v kapitole 6 nebudu muset vysvětlovat, protože je to v normě X.690 nebo X.691 docela odtažitý odstavec. Specifická nula by měla hodnotu  8016(specifický tág) + 0 (jednoduchý typ) + 0 (hodnota tágu je nula) = 8016,  jenže pokud se podíváme na následující specifickou 0, tak ta má hodnotu a0, která vznikla z: 8016( sepicifický tág) + 2016 (konstruovaný typ) + 0 (hodnota tágu je nula) = a016. Už jsme se setkali s mnoha případy, kdy byla specifická nula konstruovaná – vždy ale obsahovala nějakou sekvenci či množinu. Tento případ je odlišný, protože se tato specifická nula skládá pouze z řetězce, tj. obsahuje řetězec zkonstruovaný z několika řetězců. Důvod je praktický: pokud je zpráva dlouhá, tak šifrovací knihovna načte vždy blok dat (v našem příkladu vidíte, že načítá vždy blok dlouhý 40016 B) a pak zase další blok, takže je jednodušší výslednou zašifrovanou zprávu zkonstruovat z jednotlivých bloků. (Tento blok nesouvisí s blokem blokové šifry – ten je podstatně kratší!) 

     cont [ 0 ]       

        a0 80

      OCTET STRING     

         04 82 04 00 b3 de 36 b1 70 34 53 54 16 01 e2 96 70 7f 6f a8

         33 72 1b b3 17 05 3d 88 fb 92 63 4d 3d e3 01 75 1a 75 cd 59

         4c eb 6d 4b 6c 2b 5f ca 1a f1 6e 05 bf 7b 44 a2 fc 65 15 6e

         76 da 52 4e 21 72 8d 7d 7e 84 6a e1 b6 f4 56 df c9 9f 42 1a

         fd a4 1e 5a 71 a3 8a b5 88 d0 d4 17 04 7b 3e 67 fd eb 65 31

         09 e2 41 cc e6 17 86 de 8c 17 07 17 74 c1 9e 9b d8 43 fa 56

         62 d4 c3 d8 36 3d 37 21 c7 8d 17 cd 1b df 20 26 f8 19 4d 74

…

         96 d5 c8 22 c2 dc 37 17 a5 c1 c1 a2 8e 26 cc a6 2f 86 16 bb

         15 2d 7f 06 ed dc 66 0a

      OCTET STRING     

         04 82 04 00 9b 8b 1d 30 01 a6 81 b8 01 d1 40 26 a1 01 a0 16

         40 2b 71 76 d4 54 41 d5 94 57 a6 61 3c 8c e0 65 87 87 78 39

…

         09 36 df 74 e6 a6 6d 4f 8d fe 94 e7 2a 1a 0d 3a f1 b6 bc 71

         19 38 0d ab 7d f6 6f ad

      OCTET STRING     

         04 82 04 00 80 50 ca df 6d bb 07 68 7e a9 93 8a 37 f9 09 00

         89 f9 55 46 1d 42 b4 25 07 0f ef 1f f0 db d5 e8 60 02 d7 76

…

         4b f8 ac 78 4b 47 55 cc b1 63 ad 56 be 0d b4 ca 9b 4b f3 4c

         c4 b4 37 ec ad 3e 95 ca

      OCTET STRING     

         04 82 01 08 30 66 c6 f7 64 65 d4 18 7e 96 f1 80 88 6b d8 af

         77 b4 c7 41 15 f2 9b 1c 7b c3 55 a3 db 4b 24 c6 77 2a 6a 38

…

         e1 50 51 20 c3 7d 99 8b 5d 7d 79 48 68 9a 6d 83 31 9a c5 69

         78 09 72 e2 d7 31 e6 9a

      EOC              

         00 00

     EOC               

        00 00

    EOC              

       00 00

   EOC              

      00 00

  EOC              

     00 00

10.6Jaká číhají nebezpečí na adresáta

Existují tři typy triviálních útoků na elektronicky podepsanou zprávu (útoky na asymetrickou kryptografii či na symetrické šifry nebereme v úvahu) :

  1. Pokud je zpráva pouze elektronicky podepsána a nikoliv šifrována, pak z ní lze získat text zprávy a původní elektronicky podepsanou zprávu zahodit (nedoručit adresátovi). V případě, že zprávu adresát očekává, pak můžeme pozměnit obsah původní zprávy v náš prospěch a nepodepsanou ji předat adresátovi. Adresát zprávě uvěří a bude si myslet, že ji odesilatel pouze zapomněl podepsat.
  2. Využijete vlastnosti adresy elektronické pošty, která se může skládat z libovolného řetězce, který v sobě někde ve špičatých závorkách obsahuje adresu dle RFC-822. Zpravidla adresu píšeme:
    “Leopold Smrk <Leopold.Smrk@firma.cz>“, avšak nic nebrání napsat:
    “Prezident republiky <Leopold.Smrk@firma.cz>” a na první pohled se příjemci zobrazí, že mail přišel od „Prezident republiky“ a obsahuje platný elektronický podpis. Při dalším ohledání na to ale snadno přijdeme, že se jedná o podvrh.
  3. Použijeme nedůvěryhodnou certifikační autoritu. Existuje celá řada testovacích CA, které vydávají automatizovaně certifikáty na jakoukoliv žádost (tyto CA jsou důležité pro vývoj, ale nedůvěryhodné z hlediska údajů uvedených v certifikátu). Jednou z takových CA je i testovací CA Verisignu. Ta má tu vlastnost, že její certifikát je tč. distribuován jako součást software, tj. automaticky jí náš software věří po instalaci např. MS Outlook. Takže stačí si na podnikovém poštovním serveru nechat udělat účet vypadající jako účet generálního ředitele. Z tohoto účtu si necháte vydat na testovací CA certifikát (např. na testovací CA Verisign) a už si můžete hrát se svými spolupracovníky (podepisujete se vesele pod neuvěřitelné příkazy jako generální ředitel, a adresátovi se jeví elektronický podpis jako důvěryhodný). Této legrace si ale bohužel neužijí uživatelé sítí založených na Windows 2000, protože ty již podporují CTL (Certificate Trust List). CTL je elektronicky podepsaný seznam důvěryhodných CA, který se distribuuje v rámci firmy, tj. nevěří se automaticky každé CA. V každém případě je útok tohoto typu způsoben vadnou implementací PKI v organizaci. Pokud totiž má být elektronický podpis skutečně vážně používán, musí organizační postupy zajistit, že uživatelé budou mít na svých stanicích označené jako důvěryhodné pouze ty certifikační autority, které jimi z hlediska organizace skutečně jsou.

 

Základní nebezpečí číhající na S/MIME zprávy spočívá v podvržení certifikátu i s řetězcem certifikátů až ke kořenovému certifikátu. Součástí S/MIME zprávy totiž může být celý tento řetězec včetně kořenového certifikátu. Je proto na software poštovního klienta, aby kořenovým certifikátům, jež jsou zasílány jako součást zprávy automaticky nevěřil. Toto nebezpeční se ještě zesiluje v období, kdy se obnovuje certifikát kořenové CA.

 

Kořenový certifikát musí být distribuován a je třeba, aby uživatel tento certifikát akceptoval, jen pokud je distribuován důvěryhodnou cestou, tj. např. je podepsán starým (ještě platným) kořenovým certifikátem. Není-li žádná z těchto cest technicky možná, pak je třeba, aby si uživatel např. telefonicky na CA ověřil kontrolní součet certifikátu označovaný též jako miniatura certifikátu.

10.7Rozšířené S/MIME (Enhanced Security Services for S/MIME         - ESS)

Zatímco S/MIME verze 3 je zpětně kompatibilní s předchozími verzemi S/MIME, tak některá rozšíření S/MIME asi budou jen těžko interpretovatelná klienty S/MIME verze 2. Rozšíření S/MIME jsou vtělena do atributů elektronického podpisu.

 

Jedná se o následující čtyři rozšíření S/MIME verze 3:

Jelikož některá rozšíření budou používat elektronicky podepsané  S/MIME zprávy vkládané do elektronické obálky a výsledek se ještě jednou bude elektronicky podepisovat, tak nám vzniknou dva elektronické podpisy: vnitřní a vnější. Proto u dalších zaváděných atributů musíme též uvádět, zda-li se vyskytují ve vnitřním podpisu či ve vnějším podpisu. A pochopitelně zdali jsou podepisované či nepodepisované.

Následující tabulka uvádí přehled atributů elektronického podpisu. Pro úplnost uvádíme i atributy definované ve zprávě CMS  „nerozšířeným“ S/MIME verze 3:

 

 

Atribut

Identifikátor objektu

Norma

Vnitřní /vnější

Podepisovaný atribut?

contentHints     

id-aa-contentHint OBJECT IDENTIFIER ::=  {id-aa  4}

ESS

obojí

Může být

contentReference 

id-aa-contentReference ::= OBJECT IDENTIFIER {id-aa  10}

ESS

obojí

Musí být

contentType      

id-contentType ::= OBJECT IDENTIFIER {pkcs-9  3 }

CMS

obojí

Musí být

counterSignature

id-countersignature OBJECT IDENTIFIER ::= {pkcs-9  6 }

CMS

obojí

Nesmí být

equivalentLabel

id-aa-equivalentLabels OBJECT IDENTIFIER ::=  {id-aa 9}

ESS

obojí

Musí být

eSSSecurityLabel

id-aa-securityLabel OBJECT IDENTIFIER ::=  {id-aa  2}

ESS

obojí

Musí být

messageDigest    

id-messageDigest OBJECT IDENTIFIER ::= {pkcs-9  4 }

CMS

obojí

Musí být

msgSigDigest     

id-aa-msgSigDigest OBJECT IDENTIFIER ::=  {id-aa  5}

ESS

Pouze vnitřní

Musí být

mlExpansionHistory

id-aa-mlExpandHistory OBJECT IDENTIFIER ::=  {id-aa  3}

ESS

Pouze vnější

Musí být

receiptRequest   

id-aa-receiptRequest OBJECT IDENTIFIER ::=  {id-aa  1}

ESS

Pouze vnitřní

Musí být

signingCertificate

id-aa-signingCertificate OBJECT IDENTIFIER ::=  {id-aa  12}

ESS

obojí

Musí být

signingTime

id-signingTime OBJECT IDENTIFIER ::= {pkcs-9  5 }

CMS

obojí

Musí být

smimeCapabilities

SMIMECapabilities OBJECT IDENTIFIER ::= {pkcs-9  15}

S/MIME

obojí

Musí být

sMIMEEncryption-

KeyPreference  

id-aa-encrypKeyPref OBJECT IDENTIFIER ::=  {id-aa 11}

S/MIME

obojí

Musí být

 

id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2)

    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2 }

 

10.7.1 Doručenka (Receipt)

Jedná se až o třikrát vnořené S/MIME. Uživatel odešle elektronicky podepsanou zprávu (případně ještě vloženou do elektronické obálky) adresátovi. Odesilatel však nemá žádné informace o tom, zda-li příjemce zprávu přijal a dokázal jí dokonce porozumět (tj. uměl ji dešifrovat a ověřit elektronický podpis.)

 

Pokud odesilatel vloží do elektronického podpisu atribut s žádostí o doručenku (ReceiptRequest), tak mu specifikovaní adresáti vrátí elektronicky podepsanou doručenku. Adresát může vygenerovat doručenku až v případě, kdy s kladným výsledkem verifikoval elektronicky podepsanou zprávu.

 

Syntaxe atributu žádost o doručenku je:

 

ReceiptRequest ::= SEQUENCE {

  signedContentIdentifier ContentIdentifier,

  receiptsFrom ReceiptsFrom,

  receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }

 

ub-receiptsTo INTEGER ::= 16

 

ContentIdentifier ::= OCTET STRING

 

Kde položka signedContentIdentifier obsahuje řetězec, který generuje odesilatel. Tento řetězec kopíruje adresát do doručenky, aby bylo možné spárovat doručenku s původní zprávou. Na jednoznačnosti tohoto řetězce závisí úspěch celé operace, proto se do řetězce vkládá: jméno uživatele, identifikace klíče, čas a náhodné číslo.

 

Položka recipientsFrom specifikuje adresáty, od kterých je vyžadováno vrácení doručenky. Ti mohou být specifikováni třemi způsoby:

 

   ReceiptsFrom ::= CHOICE {

     allOrFirstTier [0] AllOrFirstTier,

     receiptList [1] SEQUENCE OF GeneralNames }

 

   AllOrFirstTier ::= INTEGER {

     allReceipts (0),

     firstTierRecipients (1) }

 

Tj. pokud je např. doručenka vyžadována od všech, pak hodnotou atributu je specifická nula (tj. specifický typ s tágem nula) obsahující ve své datové části hodnotu nula.

 

Sama doručenka používá zvláštní typ zprávy:

 

Receipt ::= SEQUENCE {

  version ESSVersion,

  contentType ContentType,

  signedContentIdentifier ContentIdentifier,

  originatorSignatureValue OCTET STRING }

 

 

ESSVersion ::= INTEGER  { v1(1) }

 

Tato zpráva se vkládá do zprávy SignedData (tj. je elektronicky podepsána adresátem) a vznikne typ zprávy označovaný též jako zpráva typu „SignedData/Receipt“.

 

Verze je tč. 1, položka signedContentIdentifier je zkopírována z původní zprávy. Položka originatorSignatureValue obsahuje samotnou hodnotu elektronického podpisu z elektronického podpisu původní zprávy.

 

Takto popsaná doručenka vypadá docela jednoduše. Pokud čtete samotnou normu RFC-2634, tak je to ale kupodivu docela komplikované. Důvodem je skutečnost, že jedna zpráva může mít více elektronických podpisů a každý z elektronických podpisů může obsahovat atribut s žádostí o doručenku. Přitom nesmíme zapomínat, že jednotlivé podpisy pod zprávou nemusí být od různých osob. Např. jedna osoba může připojit pod zprávu třeba i dva své podpisy (jeden algoritmem RSA a druhý algoritmem DSS). Může se tak stát, že doručenka by mohla být vyžadována od téhož adresáta i několikrát v jedné zprávě. Je třeba zajistit, aby od jednoho adresáta obdržel odesilatel pouze jednu doručenku.

 

Doručenka může obsahovat též atribut msgSigDigest. Hodnotou tohoto atributu je řetězec (OCTET STRING) obsahující kontrolní součet z podepisovaných atributů původní zprávy (atributů v DER kódování).

 

Výše popsaný mechanismus doručenky však bohužel nesplňuje požadavky, které jsou kladeny na doručenku v případě obyčejné „papírové“ pošty. Tam je totiž adresátovi zásilka předána až poté, co potvrdí její převzetí svým podpisem; odesilatel se tak brání situaci, při které by si příjemce zásilku převzal, ale později by to popřel. Naše elektronická doručenka však nic takového nezaručuje, protože je výhradně na klientovi (potažmo jeho software pro čtení pošty), jak se žádostí o doručenku naloží.

 

10.7.2 Pokyny ke zpracování

Zatím jsme si vždy představovali, že zpráva je nejprve elektronicky podepsána a poté teprve vložena do elektronické obálky. Jenže v některých případech je tomu naopak – podepsaná zpráva obsahuje zašifrovanou zprávu. V tomto případě bez dešifrování není vidět, co zpráva obsahuje. Není jasné, k čemu zpráva slouží.

 

Pro tento případ je určen právě atribut pokyny ke zpracování (contentHints). Je jistou obdobou předmětu zprávy, ale na rozdíl od předmětu zprávy může být tento atribut podepsán.

 

ContentHints ::= SEQUENCE {

  contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,

  contentType ContentType }

 

První položka contentDescription může obsahovat textové instrukce ke zpracování zprávy. Druhá položka pak specifikuje typ zprávy.

10.7.3 Bezpečnostní návěští (Security Labels)

Bezpečnostní návěští je speciální oblast. S touto problematikou jsme se setkali již u internetových FrontEndů.

 

V operačních systémech bezpečnostní kategorie B („vojenské systémy“) by mělo být součástí každých dat bezpečnostní návěští obsahující informace o charakteru utajení dat (tajná data, přísně tajná data apod.). Atribut bezpečností návěští je určen právě k těmto účelům – jeho cílem je zajistit, aby se k obsahu zprávy dostaly pouze povolané osoby.

 

Použití zpráv S/MIME v oblasti utajovaných dat by stejně pravděpodobně muselo být vymezeno českou vyhláškou.

 

Pokud se domníváte, že pro klasifikované zprávy nemá smysl používat elektronickou obálku, protože např. NATO má výhrady k asymetrické kryptografii, tak je třeba si uvědomit, že právě CMS zprávy (na rozdíl od zpráv PKCS#7) umožňují se obejít i bez asymetrické kryptografie a šifrovací klíče mohou být distribuovány i jinou cestou (např. kurýrem na koni s disketou).

 

Detailní popis atributů bezpečnostních návěští naleznete v RFC-2634.

10.7.4 Bezpečné konference

Pokud posíláme S/MIME zprávu do konference, tak pokud je zpráva pouze podepsaná, tak ji můžeme poslat i do běžné konference.

 

Problém je ale už s šifrovanými zprávami. Zašifrovat zprávu musíme totiž veřejným klíčem z certifikátu samotné konference. Pokud bychom poslali takovou zprávu do obyčejné konference, pak si ji nikdo nepřečte, protože členové konference nemají soukromý klíč konference.

 

Bezpečné konference zpracovávají zašifrovaný příspěvek do konference tak, že ze struktury RecipientInfo vezmou symetrický šifrovací klíč zprávy a dešifrují jej svým soukromým klíčem. Pro každého člena konference namnoží zprávu, ale do namnožené zprávy přidají další výskyt struktury RecipientInfo pro konkrétního člena konference se symetrickým šifrovacím klíčem zprávy zašifrovaným veřejným klíčem člena konference. Takže konference musí mít kromě seznamu členů i jejich šifrovací certifikáty.

 

Když konference vytváří strukturu RecipientInfo pro konkrétního člena konference, pak do ní vloží symetrický šifrovací klíč zašifrovaný veřejným klíčem z certifikátu člena konference.

 

Bezpečná konference vždy elektronicky podepisuje namnožené zprávy svým soukromým klíčem, tj. přidá vnější elektronický podpis zprávy. Při té příležitosti přidává konference do svého podpisu atribut mlExpansionHistory. Tento atribut obsahuje seznam identifikací konferencí, kterými zpráva prošla. Pokud v přijaté zprávě v atributu mlExpansionHistory konference najde svou identifikaci, tak konference již zprávu dále nemnoží, protože by došlo k cyklickému množení zpráv.

 

Atribut mlExpansionHistory má hodnotu, jež je sekvencí identifikací jednotlivých konferencí, kterými zpráva prošla (může jich být až 64):

 

MLExpansionHistory ::= SEQUENCE

        SIZE (1..ub-ml-expansion-history) OF MLData

 

ub-ml-expansion-history INTEGER ::= 64

 

Identifikace konkrétní konference se provádí pomocí struktury MLData:

 

MLData ::= SEQUENCE {

  mailListIdentifier EntityIdentifier,

  expansionTime GeneralizedTime,

  mlReceiptPolicy MLReceiptPolicy OPTIONAL }

 

První položkou je identifikátor konference, kterým je identifikace podpisového certifikátu konference. Ta může být buď jedinečným jménem vydavatele a sériovým číslem certifikátu nebo rozšířením certifikátu „Identifikátor klíče předmětu“ (viz kap. 8.1.10):

 

   EntityIdentifier ::= CHOICE {

     issuerAndSerialNumber IssuerAndSerialNumber,

     subjectKeyIdentifier SubjectKeyIdentifier }

 

Druhou položkou je expansionTime, což je datum a čas namnožení zprávy konferencí. Poslední volitelnou položkou je politika doručenek. Jedná se o případ, kdy přispěvovatel do konference použije atribut „Žádost o doručenku“. Pomocí politiky doručenek lze vracení doručenek omezit:

 

  MLReceiptPolicy ::= CHOICE {

    none [0] NULL,

    insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,

    inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }

 

Buďto zakážeme původně požadované doručenky generovat adresátem, nebo uvedeme alternativní seznam (insteadOf) těch, kteří mají doručenky generovat, či naopak uvedeme seznam těch, kterým povolujeme  doručenky generovat. 

 

 

Obr. 10-5 Příspěvek (zpráva) uživatele X projde konferencemi A, B a C až k uživateli Y. ŠA = šifrování veřejným klíčem konference A. ŠA i B = sekvence RecipientInfos obsahuje strukturu RecipientInfo se symetrickým šifrovacím klíčem zašifrovaným veřejným klíčem konference A a další strukturu RecipientInfo se symetrickým šifrovacím klíčem šifrovaným veřejným klíčem konference B.  PX = elektronický podpis soukromým klíčem uživatele X. Dále je na obrázku znázorněno, že bezpečné konference hlídají cykly, tj. aby členem konference B např. nebyla konference A.

Příspěvek uživatele X (obr. 10-5) do bezpečné konference A je uživatelem X podepsán a vložen do elektronické obálky. V terminologii bezpečných konferencí je podpis uživatele X vnitřním podpisem zprávy.

 

Konference A dešifruje symetrický šifrovací klíč elektronické obálky zprávy a rozšíří elektronickou obálku o další výskyt struktury RecipientInfo se symetrickým šifrovacím klíčem zašifrovaným veřejným klíčem člena konference A (např. veřejným šifrovacím klíčem konference B). Celou zprávu i s rozšířenou elektronickou obálkou (o další strukturu RecipientInfo) podepíše svým podepisovacím klíčem. Dále konference A přidá atribut mlExpansionHistory s identifikací konference A.

 

Pokud zpráva prochází další konferenci, tj. konference B je členem konference A, pak opět dojde o další rozšíření elektronické obálky. Jenže elektronický podpis konference A již nelze použít, protože rozšířením elektronické obálky jsme změnili podepisovanou zprávu, proto se vnější podpis konference A zahodí. Pouze se z něj vezmou všechny podepisované atributy, které se vloží do elektronického podpisu prováděného konferencí B. Podepisovaný atribut mlExpansionHistory se rozšíří o identifikaci konference B.

 

Tj. v případě elektronických konferencí se zahazují vnější obálky obsahující elektronický podpis konference.

 

10.7.5 Certifikát určený k ověření podpisu

Dlouho jsem nemohl pochopit význam tohoto rozšíření. Pokud se podíváte na strukturu SignerInfo (strukturu elektronického podpisu) např. na obr. 8-18, pak v položce SignerIdentifier je identifikace certifikátu určeného pro verifikaci elektronického podpisu. Tak proč ještě další atribut? Problém je v tom, že položka SignerIdentifier není zahrnuta do výpočtu elektronického podpisu.

 

Čistě teoreticky by tedy bylo možné vzít elektronicky podepsanou zprávu a přidat k ní do položky Certificates podvržené certifikáty. Cílem tohoto rozšíření je umožnit odesilateli omezit množinu certifikátů používaných k verifikaci zprávy.

 

Tento atribut používá identifikátor objektu id-aa-signingCertificate. Hodnotou atributu je sekvence dvou prvků:

 

   SigningCertificate ::=  SEQUENCE {

       certs        SEQUENCE OF ESSCertID,

       policies     SEQUENCE OF PolicyInformation OPTIONAL

   }

 

Prvním prvkem této sekvence je posloupnost identifikací certifikátů určených k ověření podpisu a druhým volitelným prvkem je příslušná certifikační politika (viz rozšíření certifikátů zabývající se certifikační politikou).

 

Posloupnost certifikátů se skládá z identifikací jednotlivých certifikátů. Certifikát je identifikován kontrolním součtem (certHash) počítaným z celého certifikátu algoritmem SHA-1. Volitelně může být uvedeno jedinečné jméno vydavatele certifikátu a sériové číslo certifikátu (IssuerSerial).

 

   ESSCertID ::=  SEQUENCE {

        certHash                 Hash,

        issuerSerial             IssuerSerial OPTIONAL

   }

 

 

   IssuerSerial ::= SEQUENCE {

        issuer                   GeneralNames,

        serialNumber             CertificateSerialNumber

   }

 

První certifikát v posloupnosti certifikátů musí být určen k verifikaci elektronického podpisu a až případné další v posloupnosti k verifikacím certifikátů v řetězci certifikátů.

 

 

 


*) V příkladu jsem použil v praxi hojně užívaný typ „application/x-pkcs7-signature“ i když podle normy by se měl používat typ „application/pkcs7-signature“ (tj. bez x-). Předpona x- je určena pro experimentální typy; tj. pro vývoj. Avšak v praxi se používají oba typy a norma dokonce zmiňuje, že by software měl oba typy podporovat.