3.6. Struktura vytvářených zpráv¶

Z popisu struktury vytvářených souborů např. zjistíte, zda součástí podepsaného souboru je i veřejný klíč podepisujícího. V druhé části bude poté popsán ASCII formát, který vzniká po přepínači --armor či který se používá v elektronické poště.

3.6.1. Struktura zpráv (souborů)¶

Ukážeme si strukturu tří souborů – soubor s odděleným odpisem, zašifrovaný soubor a podepsaný zašifrovaný soubor. Další typy jako soubor zašifrovaný symetrickou šifrou, exportovaný veřejný klíč, podepsaný klíč či exportovaný privátní klíč chráněný heslem jsou popsány ve standardu RFC 4880 14.

Výstupní soubory jsou buď binární, či se binární výstup převádí do „ASCII“ formátu pomocí přepínače --armor. ASCII formát bude popsán v následující kapitole.

Výstupní soubory se skládají z balíčků (packets). Balíčky se mohou skládat za sebe či různě do sebe vnořovat. Strukturu souboru si můžete vypsat pomocí přepínače --list-packets:

gpg --list-packets soubor

Obr. 3.8 Soubor s odděleným podpisem.¶

Začneme popisem odděleného podpisu (viz obrázek), který obsahuje následující položky:

Identifikaci algoritmu digitálního podpisu – RSA, DSA či ECDSA.
Identifikaci použité hašovací funkce – např. SHA512.
Dlouhé keyID klíče použitého při šifrování haše.
Čas vytvoření podpisu, tento čas může být snadno zfalšován.
První dva byty haše – pro kontrolu správnosti dešifrování haše.
Haš ze souboru zašifrovaný pomocí privátního klíče podepisujícího, tj. digitální podpis v nejužším významu. V případě RSA je to výsledek operace \(m^{d}\ \mathbf{\text{mod}}\text{\ n}\), kde \(m\) je vypočtený haš, \(d\) je privátní exponent (klíč) a \(n\) modulo dělitel (stejná hodnota pro privátní a veřejný klíč).

Každý podpis v souboru s odděleným podpisem (viz TODO) představuje samostatný balíček.

Výpis 3.27 Zobrazení struktury souboru s odděleným podpisem pomocí přepínače --list-packets.¶

gpg --list-packets soubor5.sig
# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 92001940314FDED5
       version 4, created 1481311887, md5len 0, sigclass 0x00
       digest algo 10, begin of digest f1 46
       hashed subpkt 2 len 4 (sig created 2016-12-09)
       subpkt 16 len 8 (issuer key ID 92001940314FDED5)
       data: [4093 bits]

Obr. 3.9 Struktura podepsaného souboru.¶

Podepsaný soubor obsahuje tří balíčky - vedle balíčku podpisu též balíček s vlastními daty, původním jménem souboru a časem poslední změny souboru. Tyto dva balíčky jsou vloženy do balíčku pro kompresi dat. Součástí je i informace, který kompresní algoritmus byl použit (ZIP, ZLIB či BZip2).

Obr. 3.10 Struktura podepsaného a zašifrovaného souboru s jedním příjemcem.¶

Ještě si ukážeme strukturu podepsaného a zašifrovaného souboru. Na začátku jsou balíčky se zašifrovaným klíčem sezení – pro každého příjemce jeden balíček. V každém z nich se klíč sezení šifruje veřejným klíčem příjemce pomocí odpovídajícího algoritmu veřejného klíče (RSA, Elgamal či ECDH). Součástí zašifrovaného klíče sezení je i identifikace použitého algoritmu symetrické šifry (AES128, AES192, AES256, Blowfish, Twofish, IDEA, Camellia 128, …).

Na začátku balíčku zašifrovaného symetrickou šifroui je inicializační vektor pro symetrickou šifru, která se používá v CFB módu. Zašifrovaným obsahem je obvykle kompresovaný balíček obsahující datový balíček a volitelně digitální podpis. Zašifrovaný obsah je doplněn o balíček s kontrolním hašem, který se počítá pomocí SHA1 z vlastního obsahu před zašifrováním. Tento kontrolní haš se používá pro kontrolu dešifrování – zjistí se případné chyby při přenosu či úmyslné záměny obsahu nebo klíče sezení.

3.6.2. ASCII formát – armor, base64, radix-64¶

Při zadání přepínače --armor program gpg nevytvoří binární výstupní soubor, ale textový výstupní soubor, kdy jsou binární data převedena do ASCII formátu (obvykle s koncovkou .asc). Anglické slovo armor má význam obrnit či vyztužit. Tento formát vznikl před vytvořením a rozšířením standardu MIME pro posílání binárních souborů v elektronické poště. Cílem bylo vytvořit takový tvar, který bezpečně projde tehdejší 7-bitovou elektronickou poštou.

Výpis 3.28 Podepsaný soubor v ASCII formátu, tj. po zadání přepínače --armor.¶

ASCII formát obsahuje vždy úvodní a závěrečný řádek označující začátek a konec dat. To umožňuje vložit textový soubor do textu dopisu a při přijetí z něho vybrat. V textu dopisu (či obecně souboru) může být vloženo více OpenPGP „souborů“, např. více podepsaných klíčů.

Mezi úvodní a závěrečnou hlavičkou je binární soubor převedený do Radix64, což je formát založený na kódování Base64.

Výpis 3.29 Exportovaný veřejný klíč v ASCII formátu, tj. po zadání přepínače --armor.¶

Kódování Base64 převádí binární data na posloupnost 64 tisknutelných znaků z ASCII tabulky 15. Nejčastěji se používá v elektronické poště pro přenos binárních souborů či a též při přenosu zašifrovaného obsahu či digitálního podpisu.

Při převodu do Base64 se nejdříve vytvoří tabulka, která k indexům 0 až 63 přiřadí konkrétní znaky. V některých variantách se poslední dva znaky liší, např. při kódování v URL se použije pomlčka (-) a podtržítko ( _ ).

Tabulka 3.1 Znaky v Base64 dle RFC 2045 (MIME).¶
Index	Znak	Index	Znak	Index	Znak	Index	Znak
0	A	16	Q	32	g	48	w
1	B	17	R	33	h	49	x
2	C	18	S	34	i	50	y
3	D	19	T	35	j	51	z
4	E	20	U	36	k	52	0
5	F	21	V	37	l	53	1
6	G	22	W	38	m	54	2
7	H	23	X	39	n	55	3
8	I	24	Y	40	o	56	4
9	J	25	Z	41	p	57	5
10	K	26	a	42	q	58	6
11	L	27	b	43	r	59	7
12	M	28	c	44	s	60	8
13	N	29	d	45	t	61	9
14	O	30	e	46	u	62	+
15	P	31	f	47	v	63	/

Binární data se rozdělí pro třech oktetech (bytech), každá trojice se poté převede na čtyři tisknutelné znaky.

Obr. 3.11 Zakódování tři binárních oktetů na 4 znaky Base64 tabulky.¶

Pokud binární vstup nevychází přesně na trojice, tak se zakóduje poslední jeden či dva znaky a výstup se doplní o dvě či jedno rovnítko (=), tzv. padding.

Radix64 kódování používané v OpenPGP omezuje maximální délku řádku na 76 znaků, neboť poštovní klienti často automaticky zalamovali řádky po 80 znacích. Dále se na konec souboru doplňuje kontrolní součet CRC 16 o délce 24bitů, který je opět převedený do Base64 a uvozen jedním znakem =.

14: https://tools.ietf.org/html/rfc4880 - OpenPGP Message Format
15: Vedle Base64 existuje i Base32 se 32 tisknutelnými znaky. Base16 označuje zakódování binárních dat pomocí šestnáctkové (hexadecimální) číselné soustavy. Pokud se binární data převedou do Base64, tak se jejich velikost zvětší přibližně o 33%. Při převodu do Base32 se zvětší přibližně o 60%, v případě Base16 je výsledná velikost dvojnásobná.
16: Cyklický redundantní součet (anglicky Cyclic redundancy check) je speciální hašovací funkce určená pro detekci chyb při přenosu či ukládání dat. V některých případech lze chybu opravit.

3.6. Struktura vytvářených zpráv¶

3.6.1. Struktura zpráv (souborů)¶

3.6.2. ASCII formát – armor, base64, radix-64¶

Related Topics

Navigace