3.4. S/MIME

S/MIME podporuje následující algoritmy:

Pro kontrolní součet: SHA-1 a MD5
Asymetrické šifrovací algoritmy (šifrování symetrických šifrovacích klíčů a elektronický podpis): RSA s délkou klíče minimálně 512 bitů.
Symetrické šifrovací algoritmy (šifrování textu zprávy): FOO, FOO/40, DES-CBC, triple DES.

Zdá se, že S/MIME bude prvním systémem pro bezpečnou poštu, který najde masové uplatnění. Důvodem je skutečnost, že S/MIME podporují klienti firmy Netscape.

S/MIME řeší problematiku bezpečných zpráv z praktického pohledu. Vychází z toho, že má k dispozici normu PKCS-7 pro tvorbu bezpečných zpráv. PKCS-7 umí zprávu elektronicky podepsat, šifrovat i podepsat a zároveň šifrovat. Definují proto jen příslušnou MIME hlavičku Content-Type typ/subtyp:

Content-Type: Application/pkcs7-mime

Čili zprávu zabezpečí podle normy PKCS-7 a aby se vyhověl MIME, tak definuje application/pkcs7-mime.

Obrázek 3.8

Jelikož výsledkem PKCS-7 jsou data v binárním tvaru je nutné zprávu před odesláním mailem kódovat do sedmibitového tvaru (např. Base64):

Příklad 3.3

From:
To:
MIME-Version: 1.0
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 . . .

Zpráva vytvořená podle PKCS-7 je na první pohled velice těžko čitelná - je to binární řetězec. To nevadí v případě, že zpráva bude přijata programem, který ji dešifruje, verifikuje a výsledek zobrazí uživateli v čitelném tvaru (např. klient Netscape). 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 "zašifrovaně"). Proto kromě application/pkcs7-mimenabí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ý" podpis podle normy PKCS-7:

Příklad 3.4

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ánim 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--

Součástí elektronicky podepsané zprávy (součástí zprávy formátu PKCS-7) je zpravidla i certifikát odesilatele. Příjemce takový ceritifikát verifikuje a může si jej uložit. Potřebuje-li později odpovědět, pak využije uloženého certifikátu.

Pro odeslání zprávy pouze elektronicky podepsané je třeba pouze certifikát odesilatele. Pro odeslání zprávy šifrované je třeba certifikát příjemce.

Praktický postup: Pokud chcete s někým bezpečně komunikovat pomocí elektronické pošty. Pak v prvním dopise pošlete nějaký bezvýznamný text, ale dopis pošlete elektronicky podepsán. Tím k druhé straně přepravíte svůj certifikát. Odpověď a veškerá další komunikace pak může jít i šifrovaně. (První elektronicky podepsanou zprávou přenesete svůj certifikát).

Příklad elektronicky podepsané zprávy. Elektronický podpis je vyznačen zeleně.

Příklad 3.5

From dostalek Fri Jul 4 14:37:57 1997
X-UIDL: 977df660f182831872c0ba39410274da
Received: from libor (Libor.pvt.net [194.149.104.198]) by cbu.pvtnet.cz (8.8.5/8
.7.3) with ESMTP id OAA09850 for <dostalek@pvt.net>; Fri, 4 Jul 1997 14:37:57 +0
200 (MET DST)
Message-ID: <33BCED74.A007B78B@pvt.net>
Date: Fri, 04 Jul 1997 14:32:52 +0200
From: Libor Dostalek <dostalek@pvt.net>
X-Mailer: Mozilla 4.01 [en] (WinNT; I)
MIME-Version: 1.0
To: dostalek@pvt.net
Subject: Test
X-Priority: 3 (Normal)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg
=sha1; boundary="------------msAFAC9219099F108C29F5A61A"
Status: RO
X-Status:
This is a cryptographically signed message in MIME format.
--------------msAFAC9219099F108C29F5A61A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bezvyznamny text
--------------msAFAC9219099F108C29F5A61A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIF3QYJKoZIhvcNAQcCoIIFzjCCBcoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGAwggIxMIIBmgIBHDANBgkqhkiG9w0BAQQFADBcMQswCQYDVQQGEwJDWjERMA8GA1UEChMI
UFZUIGEucy4xEDAOBgNVBAMTB0NBLVBWVDExKDAmBgkqhkiG9w0BCQEWGWNhLW9wZXJAcDcw
eDAzLmJybi5wdnQuY3owHhcNOTcwNjI1MTAzMzQ2WhcNOTcwNzA5MTAzMzQ2WjCBqTELMAkG
A1UEBhMCQ1oxCjAIBgNVBAgTATExGTAXBgNVBAcTEENlc2tlIEJ1ZGVqb3ZpY2UxEjAQBgNV
BAoTCVBWVCwgYS5zLjEMMAoGA1UECxMDVkNVMRcwFQYDVQQDEw5MaWJvciBEb3N0YWxlazEf
MB0GCSqGSIb3DQEJARYQZG9zdGFsZWtAcHZ0Lm5ldDEXMBUGA1UEDBMOKzQyIDM4IDc3NDcz
NjEwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwdvG3SKsBfjkCY4DOGq1kRcY9FDmoXd/a7ib
fVXmPa9Hd6R1ugwA5I5cy/CvzeAF3IlQiFTSUsNWFj5TTDgrswIDAQABMA0GCSqGSIb3DQEB
BAUAA4GBABjB6OMnyMvW41V9CD1EOUjmYmPEQ/Bo73esk1GQTfwz4OHZssaYAb50/ffZbADW
XTYxdlJgwZWg7jyb8n6eUVq6CiDgOM21yc5DYkkdThXaWjXN3ZJ+cbMSyMw+//09C0YbrpXG
1q/tH3fS1U0kS8MR77nK57WMmXfMk+NaE1ZCMIICJzCCAZACAQEwDQYJKoZIhvcNAQEEBQAw
XDELMAkGA1UEBhMCQ1oxETAPBgNVBAoTCFBWVCBhLnMuMRAwDgYDVQQDEwdDQS1QVlQxMSgw
JgYJKoZIhvcNAQkBFhljYS1vcGVyQHA3MHgwMy5icm4ucHZ0LmN6MB4XDTk3MDUyNjA4NTU0
NloXDTk4MDUyNjA4NTU0NlowXDELMAkGA1UEBhMCQ1oxETAPBgNVBAoTCFBWVCBhLnMuMRAw
DgYDVQQDEwdDQS1QVlQxMSgwJgYJKoZIhvcNAQkBFhljYS1vcGVyQHA3MHgwMy5icm4ucHZ0
LmN6MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwA8x4iL556/8SuBDJeEylv6VsKyJa
DgSvSyNoMioJGIYbh0qeWMfivZcS9ZcXXzMv5o3TvvOUjcI067SxUaCtRuId/SiKufLrLFAP
aGNQy3ZdOEkeSg4Dm1r3sVoVkNyaIgKFTzn2eC/hfPT/78nIzLnWguf33CgQ680QON0ikQID
AQABMA0GCSqGSIb3DQEBBAUAA4GBAGi3w2c0igmiUHzWrVO3wPHLJxnCySLy0qnfGQ+a7RFK
2bwBnJ6guE9iz/r22iZH0BFRZpKG/FP0wWW9r85uHytkWWwWilDyI1zP//KWNDp5YzZxo4Yx
hsMnDWFdx9isRJNvWvfneI+2vQuswQ9PSm49dmuFcMnGi4Yhi5Bs7ZKuMYIBRTCCAUECAQEw
YTBcMQswCQYDVQQGEwJDWjERMA8GA1UEChMIUFZUIGEucy4xEDAOBgNVBAMTB0NBLVBWVDEx
KDAmBgkqhkiG9w0BCQEWGWNhLW9wZXJAcDcweDAzLmJybi5wdnQuY3oCARwwCQYFKw4DAhoF
AKB9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYEFFfSYgDQeMyX
FqlliV9h86CkomE7MBwGCSqGSIb3DQEJBTEPFw05NzA3MDQxMjMyNTJaMB4GCSqGSIb3DQEJ
DzERMA8wDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQH+wYCKXGFm9FY6MeX/n+0Y3
jmfC3XpDFXei4hzCt+IfwggrC8WgDGq/qMR82G6zOE+tqIGwyO7QyjfPCexLSDo=
--------------msAFAC9219099F108C29F5A61A--

Kromě zpráv elektronicky podepsaných, šifrovaných či zároveň podepsaných a šifrovaných S/MIME ještě specifikuje žádost o certifikát. Opět využívá již osvědčenou normu, tentokráte normu PKCS-10. Žádost podle PKCS-10 balí do MIME:

Příklad 3.6

From:
To:
MIME-Version: 1.0
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 . . .

Asi vám schází mechanizmus, kterým po podepsání vrátí certifikační autorita spolu se svým cerifikátem žadateli. To však vcelku není problém, protože certifikát se pošle jako obyčejná MIME zpráva v jejíž hlavičce Content-Type se specifikuje, že jde o certifikát.

Např. Netscape používá:

Content-Type: application/x-x509-user-cert

pro podepsaný uživatelský certifikát a

Content-Type: application/x-509-ca-cert

pro certifikát certifikační autority.

Používat jiný typ pro uživatelský certifikát a pro certifikát certifikační autority je výhodné, protože je lze automaticky ukládat (klient má zpravidla i dvě menu: jedním prohlíží a nastavuje uživatelské certifikáty a druhým certifikáty certifikační autority). V opačném případě by se musel klientský software dotazovat uživatele o jaký typ certifikátu se jedná, což pro mnohé uživatele by asi bylo nepřekonatelným problémem.

PKCS

Normy PKCS (Public-Key Cryptograpy Standards) byly vyvinuty v RSA Laboratories. Jsou dotupné na ftp://ftp.rsa.com. Dnes je však snaha z těchto norem udělat RFC.

Normy PKCS jsou tvořeny základem desti norem PKCS-1 až PKCS-10. Z našeho pohledu jsou zásadní tři:

PKCS-1 specifikující asymetrické kryptografické algoritmy a algoritmy elektronického podpisu.
PKCS-7 specifikující jednotlivé typy obsahu zpráv:

"data" - obecná data.
"signedData" - elektronicky podepsaná data.
"envelopedData" - šifrovaná data.
"signedAndEnvelopedData" - elektronicky podepsaná a zároveň šifrovaná.
"digestData" - data s kontolním součtem. Takováto zpráva může být vsupem pro envelopedData. Typ digestData je obdobou symetrických IK-klíčů v PEM.
"encryptedData" - také šifrovaná data. Avšak tento typ není míněn pro zabezpeční zpráv při jejich přenosu, ale např. zabezpečení zprávy symetrickou šifrou na lokálním disku. Šifrovací klíč je pak heslem. V praxi se používá např. pro zabezpečení soukromých klíčů na disku.

Pro naše účely budou nejdůležitějiší typy signedData, envelopedData a signedAndEnvelopedData.

PKCS-10 specifikující žádost o certifikát

PKCS-7 , PKCS-10

3.5. PGP