Zavedení hash algoritmů SHA-2 v prostředí OS Microsoft Windows

Ve spojení s výše uvedenou problematikou se objevují různé spekulace a nepřesné informace, které uvádějí, že pro zavedení nových hash algoritmů je nezbytné provést upgrade operačních systémů Windows XP na Windows Vista nebo Windows 7. Obdobně je problém spojován s „povinným“ upgradem Windows Serveru 2003 na Windows Server 2008. Cílem tohoto článku je maximální objasnění všech faktů, které souvisí s problematikou zavedení hash algoritmů rodiny SHA-2.

Úvod do problematiky

Jak již bylo v úvodu zmíněno, přechod na hashovací algoritmy se týká oblasti elektronického podpisu. Pro správné porozumění dalších částí článku je základ problematiky vysvětlen v následujících odstavcích.

Principy elektronického podpisu

Elektronický podpis může být použit pro distribuci zprávy ve formátu prostého textu v případech, kdy příjemce musí identifikovat a ověřit odesílatele zprávy. Podepsání zprávy nemění vlastní zprávu, ale vytvoří řetězec znaků elektronického podpisu. Tento řetězec znaků může být následně připojen ke zprávě, nebo může být odeslán nezávisle. Formát předání zprávy a elektronického podpisu se řídí definovanými pravidly (standardy), kterých existuje celá řada, a hraje důležitou roli v celém procesu. Elektronický podpis reprezentuje malý objem dat, která jsou zašifrována privátním klíčem odesílatele. Při rozšifrování dat se použije veřejný klíč odesílatele, který zaručí, že data byla zašifrována odesílatelem, popř. někým, kdo má přístup k privátnímu klíči odesílatele. Elektronický podpis je vytvářen s využitím veřejně dostupných algoritmů a privátního klíče a je ověřován odpovídajícím veřejným klíčem. Tento proces je zobrazen na následujícím obrázku.

Obrázek 1: Proces vytváření a ověřování elektronického podpisu

V průběhu vytváření elektronického podpisu vstupují do hry dva základní kroky. V prvním kroku je z vlastní zprávy vytvářena hodnota funkce hash (známá také jako message digest). Tato výsledná hodnota je následně v dalším kroku podepsána s využitím privátního klíče odesílatele. Proces podepsání ve skutečnosti znamená zašifrování hodnoty hash privátním klíčem.

Následující obrázek je ilustrací dvou kroků použitých při vytváření elektronického podpisu.

Obrázek 2: Proces vytváření elektronického podpisu

Pro vlastní kontrolu podpisu je nezbytné mít k dispozici vlastní zprávu a elektronický podpis. Za prvé se ze zprávy vytvoří hodnota funkce hash stejným postupem, jaký byl použit při vytváření elektronického podpisu. Veřejným klíčem odesílatele se rozšifruje hodnota funkce hash v elektronickém podpisu (ta byla vytvořena při podepisování). V případě, že se první hodnota funkce hash shoduje s rozšifrovanou hodnotou, je prokázáno, že zpráva je ta, kterou odesílatel podepsal, a že nebyla změněna. Následující obrázek ilustruje proces ověření elektronického podpisu.

Obrázek 3: Proces ověření elektronického podpisu

Hodnota funkce hash je složena z malého množství binárních dat, definované délky podle zvoleného hash algoritmu. Např. délka pro SHA-1 je 160 bitů a pro SHA-256 je výstupní délka 256 bitů. Všechny výsledné hodnoty funkce hash sdílejí stejné vlastnosti bez ohledu na použitý algoritmus:

• Délka hodnoty hash je dána typem použitého hash algoritmu, a tato délka se nemění v závislosti na délce vlastní zprávy. Přechod na algoritmy rodiny SHA-2 znamená, že se zvětšuje délka hodnoty hash ze 160 bitů u algoritmu SHA-1 na příslušnou délku nového algoritmu SHA-2.
• Každá dvojice neidentických zpráv vede na totálně rozdílnou hodnotu hash, dokonce i v případě, že se dvě zprávy liší pouze v jediném bitu. I pro splnění této podmínky se přechází na hash algoritmy s větší délkou výstupní hodnoty.
• Pokaždé, když je počítána hodnota hash z příslušné zprávy za použití toho samého algoritmu, je vytvořena stejná hodnota funkce hash.
• Hash algoritmus je jednosměrná funkce. Z dané výsledné hodnoty hash funkce není možné obnovit původní zprávu.

Certifikáty

Jednou ze základních funkcí certifikátu je mimo jiné zajistit distribuci veřejného klíče odesílatele a ověření jeho platnosti. Certifikát je vlastně zpráva, která je podepsána certifikační autoritou a říká asi toto: „Člověku jménem Josef Novák patří e- mail j.novak@firma.cz a jeho veřejný klíč je …”. Součástí certifikátu je dále například také doba jeho platnosti. Jelikož je certifikát podepsán autoritou, které příjemce důvěřuje (nebo také nedůvěřuje), může si jednoduše a automaticky ověřit jeho pravost (ověřením podpisu autority), a tím získá i informace o pravosti jejího majitele. Jak již bylo řečeno, certifikát je zpráva, která je elektronicky podepsána přesně podle výše popsaných principů. Následující obrázek ukazuje certifikát, který je podepsán za pomocí algoritmu SHA-1.

Obrázek 4: Certifikát podepsaný s využitím algoritmu SHA-1

Uvedená vyhláška zavádí vydávání certifikátů, které budou podepsány s využitím hash algoritmu z rodiny SHA-2. Následující obrázek ukazuje certifikát, který je podepsaný s využitím algoritmu SHA-256.

Obrázek 5: Certifikát podepsaný s využitím algoritmu SHA-2

Vyhláška dále předepisuje minimální přípustnou délku klíče nastavenou na hodnotu 2048 bitů, viz následující obrázek.

Obrázek 6: Délka kryptografického klíče nastavená na hodnotu 2048 bitů

Zde je potřeba poznamenat, že zvolený algoritmus pro podepsání certifikátu nijak neovlivňuje, jakým způsobem budou klíče obsažené v certifikátu použity pro podepsání vlastní datové zprávy. Např. certifikát podepsaný s využitím algoritmu SHA-1 může být použit pro podepsání datové zprávy s využitím algoritmu SHA-256 a naopak. To, jaký hash algoritmus pro podepsání vlastní datové zprávy bude použit, určuje uživatel (odesílatel), resp. aplikace, která provádí podepsání datové zprávy.

Co je třeba změnit pro využití algoritmů SHA-2

Z výše uvedeného popisu principu vytváření elektronického podpisu by bylo možné usoudit, že stačí upravit aplikaci, která data podepisuje, tak, aby dokázala vytvořit hodnotu funkce hash podle příslušného algoritmu. Tím by byl celý problém vyřešen. Bohužel situace je mnohem složitější, protože do celého procesu vstupují další komponenty, které musí pracovat s jinou délkou hash hodnoty. Primárně se jedná o moduly, Cryptographic Service Providers (CSP), které jsou zodpovědné za podepsání hodnoty hash. Tyto komponenty přebírají od aplikací hodnotu funkce hash (pokud ji rovnou nepočítají samy) a s využitím šifrovacích mechanismů, které jsou v CSP zabudovány, provedou operaci podepsání. V případě, že modul CSP neumí s příslušnou délkou hodnoty hash pracovat, dojde k programové chybě a datovou zprávu není možné podepsat zvoleným algoritmem. CSP jsou jednak součástí operačního systému, popř. mohou být realizovány jako doplňkové moduly realizované jinou firmou než výrobcem operačního systému. Pokud tedy příslušný modul CSP nebude schopen podepsat hash definovaného algoritmu, pak samotná úprava aplikace pro podporu dalších hash algoritmů není dostačující. Rozhodnutí o tom, který CSP modul bude podepisující aplikací použit, je dáno tím, jaká informace o CSP je uložena u privátního klíče.

Operační systémy Microsoft Windows obsahují dva základní moduly CSP:

• Microsoft Enhanced Cryptographic Provider v1.0,
• Microsoft Base Smart Card Crypto Provider.

Pokud má uživatel operační systém Microsoft Windows XP SP3, pak je součástí tohoto operačního systému Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype). Operační systémy Microsoft Windows 2003 Server a vyšší, Windows Vista a vyšší místo výše uvedeného CSP pro Windows XP obsahují Microsoft Enhanced RSA and AES Cryptographic Provider.

• Microsoft Enhanced Cryptographic Provider v1.0 nepodporuje podepisování s využitím hash algoritmů rodiny SHA-2.
• Microsoft Enhanced RSA and AES Cryptographic Provider a Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype) podporují podepisování s využitím hash algoritmů rodiny SHA-2.
• Microsoft Base Smart Card Crypto Provider využívá vlastností čipové karty, a proto podpora podepisování s využitím příslušných hash algoritmů je závislá na schopnostech čipové karty.

Dalším faktorem, který vstupuje do hry, je formát, který slouží pro předání datové zprávy a elektronického podpisu. I v tomto případě je důležité, aby komponenty, které připravují výstupní data, byly schopny zpracovat, nebo vytvořit výstup s použitím příslušných hash algoritmů. Jako příklad můžeme uvést výstup ve formátu PKCS#1, PKCS#7 nebo XML Dsig. V neposlední řadě je důležité, aby operační systém resp. CSP modul dokázal pracovat s certifikáty, které jsou podepsány s využitím hash algoritmu rodiny SHA-2, v případě, že takový certifikát je k dispozici. V předchozí kapitole bylo zmíněno, že pro vlastní podepisování dat s využitím algoritmů SHA-2 není nutné mít certifikát takto podepsaný. Samozřejmě přípravu na práci s těmito certifikáty je nutné udělat, protože dle vyhlášky budou akreditované certifikační autority tyto certifikáty nejpozději od 1. 1. 2010 vydávat.

Shrnutí nutných podmínek pro podporu algoritmů SHA-2

Shrneme-li výše uvedené poznatky, dostaneme základní popis nutných podmínek pro dosažení podpory algoritmů SHA-2 v aplikacích.

Operační systém musí být schopen ověřit platnost certifikátu, který je podepsán s využitím algoritmu rodiny SHA-2. Následující tabulka shrnuje podporu ověření planosti certifikátu.

Tabulka 1: Podpora ověření certifikátu podepsaného s využitím algoritmu

1.Cryptographic Provider musí podporovat podepisování výsledné hodnoty hash z rodiny SHA-2.

Upozornění: Privátní klíč podepisujícího subjektu musí být spojen s tímto CSP. Následující kapitoly se budu touto problematikou zabývat podrobněji.

Tabulka 3: Moduly CSP v jednotlivých verzích operačních systémů Windows

Poznámka: Výše uvedené tabulky shrnují možnosti využívání podpisového schématu RSA/SHA. Pro jiné varianty např. s využitím „Elliptic Curve Digital Signature Algorithm (ECDSA)“ by matice podpory v operačních systémech byla jiná.

2.Výměna vlastní zprávy a elektronického podpisu mezi subjekty probíhá na základě definovaného formátu. Následující tabulka shrnuje podporované formáty přímo operačním systémem.

Tabulka 4: Podpora výstupních formátů pro různé verze operačního systému Windows

*) Volání CSP je možné realizovat v prostředí Microsoft.NET nebo přímým voláním Win32 API, popř. se o volání postarají objekty příslušného programovacího jazyka či platformy.

**) – XML DSIG je možné realizovat i s podporou dalších platforem, např. JAVA

Upozornění: Předchozí tabulky shrnují technologie přímo dodávané společností Microsoft. Třetí strany mohou realizovat CSP, výstupní formáty, podepisování vlastními prostředky.

3.Aplikace, která podepisuje data, musí podporovat využití hash algoritmů SHA-2. Funkce musí být přímo zabudována v aplikaci a uživatel musí mít možnost toto nastavení ovlivnit buď výběrem z dialogových oken, nebo pomocí konfigurace aplikace.

Upozornění 1: Nezaměňovat s podpisem vlastního certifikátu, který provádí certifikační autorita (první podmínka).

Upozornění 2: I s certifikátem, který je od certifikační autority podepsán s využitím algoritmu SHA-1, je možné podepisovat data s využitím algoritmů rodiny SHA-2.

Upozornění 3: S certifikátem, který je od certifikační autority podepsán s využitím algoritmu SHA-2, je možné podepisovat data s využitím algoritmu SHA-1.

Následující obrázky jsou příklady použité z aplikace Microsoft Outlook. V prvním případě se jedná o nastavení zabezpečení e-mailové komunikace v aplikaci Microsoft Outlook 2003. Výběrové pole pro nastavení hash algoritmu neumožňuje vybrat jiné algoritmy než MD5 a SHA-1. V praxi to znamená, že v aplikaci Microsoft Outlook 2003 není možné nastavit hash algoritmy rodiny SHA-2.

Obrázek 7: Nastavení zabezpečení v aplikaci Microsoft Outlook 2003

Na dalším obrázku je použito to samé nastavení zabezpečení e-mailové komunikace, ovšem v tomto případě v aplikaci Microsoft Outlook 2007. Zde je vidět, že je již možné vybrat hash algoritmy z rodiny SHA-2 (s výjimkou algoritmu SHA-224).

Obrázek 8: Nastavení zabezpečení v aplikaci Microsoft Outlook 2007

4.Privátní klíč uživatele, který podepisuje data, musí být spojen s CSP, který podporuje podepisování výsledné hodnoty hash z rodiny SHA-2. Splnění této podmínky je spojeno s celou řadou kroků, popř. vytvořením specializované aplikace pro spojení privátního klíče s příslušným CSP. Umístění privátního klíče není možné měnit u CSP spojeného s čipovou kartou. Výchozí spojení privátního klíče s CSP je ovlivněno již při vytváření žádosti o certifikát. V závislosti na aplikaci, která vytváří žádosti, je buď uživateli umožněno zvolit si příslušný CSP, nebo také ne. Následující obrázek ukazuje výřez webových stránek společnosti I.CA při generování žádosti o certifikát, kde je možné učinit výběr CSP.

Obrázek 9: Možnost výběru CSP při generování žádosti na stránkách společnosti I.CA

V době psaní tohoto článku např. nástroj PostSignum Tool společnosti Česká pošta neumožňoval uživatelům výběr CSP, viz následující obrázek.

Obrázek 10: Generování žádosti o certifikát bez možnosti výběru CSP v aplikaci PostSignum Tool

Příslušný certifikát se následně instaluje do počítače uživatele. O instalaci se buď postará nástroj, pomocí kterého byla žádost generována (při dokončení procesu žádosti o certifikát), nebo je certifikát importován pomocí nástrojů operačního systému Windows (Import certifikátu). Při importování certifikátu pomocí prostředků Windows není možné ovlivnit, s jakým CSP bude spojen privátní klíč, ale je použito výchozí nastavení, které bylo u certifikátu nastaveno při generování žádosti. Z výše uvedeného plyne, že standardně vytvořené certifikáty budou s největší pravděpodobností spojeny s CSP, který nemá zabudovánu podporu pro algoritmy rodiny SHA-2. Do budoucna je možné předpokládat, že nově generované žádosti o certifikát již budou na doporučení vydavatelů spojeny s CSP s podporou algoritmů SHA-2. Zde je nutné si uvědomit, že nově generované certifikáty budou podepsány s využitím algoritmů rodiny SHA-2, ale privátní klíč v nich obsažený může být stále spojen s CSP bez podpory SHA-2. Podmínka uvedená v tomto bodě platí pro všechny operační systémy bez ohledu na jejich verzi.

Přestože podmínka pro spojení privátního klíče se správným CSP podle popisu vypadá velmi problematicky, má několik řešení i pro případy, kdy je privátní klíč spojen s CSP bez podpory algoritmů SHA-2. Jednak je možné vytvořit nástroj, který „přehodí“ privátní klíč ke správnému CSP, nebo je možné tuto situaci ošetřit přímo v kódu aplikace, která si za běhu spojí privátní klíč uživatele se správným CSP. Pro jistotu je potřeba znovu zdůraznit, že tyto „opravné“ mechanismy je možné provádět pouze s certifikáty uloženými v souboru, nebo v úložišti Windows, a nelze je použít pro certifikáty na čipových kartách.

Odpovědi na základní otázky

Otázka č. 1: Využívá operační systém Windows XP SP3 nebo Windows 2003 Server algoritmy rodiny SHA-2?

Odpověď č. 1: Operační systémy Windows XP SP3 a Windows 2003 Server pro své interní aplikace algoritmy rodiny SHA-2 nevyužívají. Do těchto operačních systémů je zabudována validace certifikátů podepsaných s využitím hash algoritmu rodiny SHA-2. Pro objasnění této odpovědi použijeme dva příklady. První příklad se bude týkat aplikace – Certifikační autorita zabudovaná v OS Windows 2003 Serveru. Tato aplikace nepodporuje a nebude podporovat vydávání certifikátů, které budou moci být podepsány s využitím algoritmů SHA-2.

Druhý příklad se bude týkat validace certifikátu ve Windows XP v aplikaci Internet Explorer. Tato validace je důležitá pro případy, kdy uživatel navštíví webovou stránku s využitím protokolu SSL a certifikát na straně webového serveru již bude podepsán s využitím algoritmu rodiny SHA-2. Díky zabudované validaci takového certifikátu do operačního systému budou moci uživatelé na tyto stránky přistoupit bez příslušného bezpečnostního varování.

Otázka č. 2: Mohou aplikace běžící nad Windows XP SP3 a Windows 2003 Serveru využívat algoritmy rodiny SHA-2?

Odpověď č. 2: Ano, pokud budou splněny všechny výše v článku uvedené podmínky. V praxi to znamená, že např. aplikace spisové služby nebo účetní systém, který elektronicky podepisuje faktury, mohou při splnění všech uvedených podmínek na platformě Microsoft Windows XP SP3 využívat podepisování s využitím algoritmů rodiny SHA-2.

Otázka č. 3: Stačí upgrade na Windows Vista / 7 nebo Windows 2008 Server? Resp. budou aplikace po upgrade na Windows Vista automaticky podporovat hash funkce rodiny SHA-2?

Odpověď č. 3: Prostý upgrade nestačí, protože i v tomto případě musí být splněny všechny podmínky uvedené v tomto článku.

Závěr

Základním cílem článku bylo vyvrátit tvrzení, že pro přechod na hash algoritmy rodiny SHA-2 je naprosto nezbytný upgrade operačních systémů z Windows XP nebo Windows 2003 Server na vyšší verze. Zavedení hash algoritmů z rodiny SHA-2 je komplexní proces, ve kterém do hry vstupují vlastnosti operačního systému, certifikátů, kryptografických providerů a vlastních aplikací. Aplikace, které podepisují data, budou muset být zrevidovány a s velkou pravděpodobností upraveny pro podporu algoritmů SHA-2. Bude nutné mít proces pro správu certifikátů nastaven tak, aby privátní klíče uživatelů byly spojeny se správným kryptografickým providerem.

Společnost Microsoft doporučuje provést upgrade na nejnovější verze operačních systémů, protože uživatelé mohou vyžadovat scénáře šifrování či podepisování, které již nebude možné v předchozích verzích operačních systémů realizovat, např. využití algoritmů eliptických křivek. Tyto nejnovější algoritmy jsou zabudovány pouze do posledních verzí operačních systémů společnosti Microsoft.

Microsoft Enterprise services připravují sadu odborných seminářů, které umožní zájemcům hlubší seznámení s problematikou a na reálných příkladech ukážou principy tvorby aplikací, které budou schopny využívat hash algoritmy rodiny SHA-2. Pro bližší informace o seminářích se obraťte na e-mailovou adresu cons-cz@microsoft.com.

Modelová situace

Uživatel, který posílá e-maily, elektronicky zasílá data celní správě a prostřednictvím transakční části PVS zasílá elektronicky Evidenční listy důchodového pojištění ČSSZ.

Vybavení

• Windows XP SP2, Microsoft Office 2003.
• Dekarantský sw vytvořený Firmou X, data se zasílají prostřednictvím VAN operátora.
• Personální systém vytvořený Firmou Y, data se zasílají prostřednictvím transakční části PVS.

V polovině ledna 2010 získá od akreditované certifikační autority nový certifikát, který bude podepsán s využitím algoritmu rodiny SHA-2.

Co nastane?

Modelová situace – činnosti uživatele

Uživatel provede import certifikátu vč. kořenových certifikátů certifikační autority (předpokládáme, že budou nové)

Uživatel si musí naistalovat SP3 pro Windows XP

• Operační systém bude schopen ověřit platnost elektronického podpisu certifkátu, který provedla CA s využitím algoritmu SHA-2

Od tohoto okamžiku může uživatel bez prolému certifikát použivat a elektronicky komunikavat s tím, že:

• Outlook 2003 bude elektronicky podepisovat maily s využitím algoritmu SHA-1
• Komunikace s celní správou bude probíhat beze změny. Tj. podpsaná data budou přenášena ve formátu S/MIME (PKCS#7). Podpis bude realizován s využitím algoritmu SHA-1
• Komunikace s ČSSZ bude probíhat dle definovaného formátu datové zprávy a data budou podepisována s využitím algoritmu SHA-2

V této fázi uživatel nemusí provádět upgrade OS. Pouze musí nainstalovat SP3.

Modelová situace – změny na straně GŘC a ČSSZ

Nyní předpokládejme, že na straně GŘC a ČSSZ dojde ke změně datového formátu a nově bude k dispozici i možnost zasílat data, která budou podepsána s využitím algoritmu SHA-2

• Oznámení na stránkách MV přesto stále počítá se zachováním podpory algoritmu SHA-1. Lze předpokládat, že tuto komunikaci resorty dostatečně dlouho zachovají

Po zveřejnění nových principů elektronického podepisování dat musí firmy X a Y do svých programů provést příslušné změny.

• Předpokládá se, že nově bude využíván formát XML DSIG

Po dokončení nových verzí příslušných programů si uživatel udělá upgrade těchto aplikací. Příslušné aplikace, pokud budou „řádně“ napsány, budou funkční i na Windows XP. Koncový uživatel nebude muset provádět upgrade Windows XP SP3 na novější operační systém.

Modelová situace – odesílání e-mailů

Uživatel se rozhodne, že bude chtít odesílat e-maily, které budou elektronicky podepsány a uživatel bude chtít použít hash algoritmus z rodiny SHA-2.

Toto je okamžik, kdy uživatel bude muset přistoupit k povýšení svého prostředí.

Bude nezbytné provést upgrade OS na Windows Vista nebo Windows 7

• Obsahují Cryptography API: Next Generation (CNG)

Bude nezbytné provést upgrade Office 2003 na Office 2007

• Office 2007 má zabudovanou podporu pro algoritmy z rodiny SHA-2 ve spolupráci s CNG

Poznámka: V současné situaci je to dobrovolné rozhodnutí uživatele, protože oznámení MV nemůže uživatele k tomuto kroku nutit.