Analýza SASL, druhý díl

Pokračování předchozího článku SASL díl první, rozebírá další jednotlivé algoritmy a jejich vlastnosti. Cílem je poskytnout materiál, ze kterého je možné vycházet v případě analýzy použitých technologií.

EAP-AES128 a EAP-AES128-PLUS

EAP (Extensive Authentication Protocol) je framework, obsahující sadu autentizačních mechanismů. Původně byl navržený pro PPP spojení (Point to Point Protocol). Dnes je ovšem využívaný i v rámci Ethernet a WiFi sítí (IEEE 802.1x), pro autentizaci v rámci VPN sítí, mobilních sítí (nejčastěji EAP-SIM), může být používán i na DSL/ADSL a HDSL spojeních a lze pokračovat. Jeho nasazení je provázané s protokolem RADIUS a DIAMETER (EAP v protokolu EAPOL). Standardizaci zastřešuje IANA, v současnosti je evidováno zhruba 50 algoritmů.
SASL dokáže využít autentizační mechanismy poskytované v rámci EAP , vlastní přenášený rámec je poté šifrován pomocí algoritmu AES. Ve valné většině se patrně jedná o šifrování pomocí CBC nebo CTR módu, ale nenalezl jsem žádnou dokumentaci, která by uvedený postup formalizovala. Stejně tak jsem nenalezl informaci o formalizaci ochrany integrity. Z hlediska bezpečnosti by bylo lepší použít např. GCM nebo CCM mód (AEAD, tedy autentizované šifrování s asociovanými daty) buď na úrovni SASL EAP-AES128, nebo alespoň použít v rámci EAP šifrování zajišťující ochranu důvěrnosti i integrity. V současnosti je rozhodně možné použít EAP-TLS, nebo EAP-PSK, teoreticky by mělo být možné použít jakékoliv další EAP mechanismy. Základní verze přenáší informace mezi klientem a serverem, rozšířená verze (EAP-AES128-PLUS) navazuje komunikaci na další kanál.
Vlastní EAP-AES128 využívá jednoduchý způsob ochrany komunikace, kde probíhá zpracování klíčového materiálu a autentizačních informací následujícím způsobem.

Klient - Server: Domluva na sdíleném tajemství nebo poskytnutí klíče K_Server pomoci asymetrických algoritmů mimo EAP
Klíč: k=PBKDF2(K_Server, salt, iteration, 128b)

Klient→ Server: AES128(k,EAP message)
Server→ Client: AES128(k,EAP message)

V případě channel binding by mělo dojít k nějaké formě ověření kanálu, tedy buď zajištění integrity nebo vložení informace dovnitř kanálu způsobem, který bude v rámci EAP akceptován. Uvedené se mi nepodařilo nasimulovat, ale možná představa takového vyhodnocování může být realizována např. následujícím postupem, kde CCC představuje kryptografický kontrolní součet a CSD představují Channel Specific Data (certifikáty, MAC adresy obou stran a další).

CCC = HMAC(PBKDF2(k, salt, iteration),AES128(k(EAP message))||CSD)

Channel Binding: Ne pro základní verzi, ano pro PLUS verzi
Realms: dle EAP algoritmu
Kryptoprimitiva: Zastaralé (MD4, MD5, SHA-1), výběhové (RSA), aktuální ECDH
Účastníků autentizace: 2
PQC/QRC: Ne, současná asymetrická kryptografie je nedostatečná.
ZKP: Ne
Podpora crypt interface: dle EAP algoritmu
Tokenizace: dle EAP algoritmu
Jedinečnost: Ano
Ochrana credentials: Ano, heslo, za určitých podmínek i uživatelské jméno
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ne pro základní verzi, ano pro PLUS verzi
Ochrana proti Forge: Ano
Podpora MFA: dle EAP algoritmu
Ochrana integrity: Ne (nenalezl jsem)
Typ šifrování: Interní, volitelně dle EAP např. TLS

ECDH-X25519-CHALLENGE

Autentizace tímto algoritmem vyžaduje registraci veřejného klíče k uživatelskému jménu na straně ověřujícího serveru. V rámci SASL zajišťuje domluvu na sdíleném tajemství pomocí Montgormeryho reprezentace Curve25519 (x25519). Domluva na sdíleném tajemství probíhá následujícím způsobem. Jsou definovány parametry křivky, privátní klíče a funkce pro odvození hodnot. Na základě vstupů najdou společné sdílené tajemství, které dovolí klientovi dešifrovat maskovanou hodnotu výzvy pro spojení. Pokud se na konci výpočtu prokáže odpovídající výzvou spojení serveru, je ověření úspěšné.

Klient→ Server: ID_Client (0x00h || username)

Server → Client: C_Server(PubKey_Server||sůl|| (Challenge_Session ⊕ ECDH-X25519-KDF)

Client → Server: C_Client(PubKey_Server||sůl|| (Masked Challenge_Session ⊕ ECDH-X25519-KDF)

ECDH-X25519-KDF
 {
   IKM = Hash(SharedSecret || PubKey_Client || PubKey_Server)
   PRK = HKDF-Extract(sůl, IKM)
   OKM = HKDF-Expand(PRK, "ECDH-X25519-CHALLENGE", Lenght=32)
 }

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: aktuální
Účastníků autentizace: 2
PQC/QRC: Ne, současná asymetrická kryptografie je nedostatečná.
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne, tvorba sdíleného tajemství
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ano
Typ šifrování: Interní

ECDSA-NIST256P-CHALLENGE

Uvedný mechanismus vyžaduje generování páru privátního a veřejného klíč. Veřejný klíč musí být ve vztahu k danému uživateli registrován na požadované službě. V tomto případě dochází k ověření držení privátního klíče na základě výsledku podpisy výzvy poskytnuté serverem.

Client → Server: Base64(username)
Server → Client: C
Client: Signature=ECDSA_Signature(x,C)
Client → Server: Signature

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: aktuální
Účastníků autentizace: 2
PQC/QRC: Ne, současná asymetrická kryptografie je nedostatečná.
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne, tvorba sdíleného tajemství
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ano
Typ šifrování: Interní

EXTERNAL

Jedná se o metody, využívající externí autentizace. Příkladem může být ověření na úrovni SSL/TLS nebo jiné metody. Tyto metody musí být určeny a vyžadují kontrolu odpovídající architektury.

Channel Binding: N/A
Realms: N/A
Kryptoprimitiva: N/A
Účastníků autentizace: N/A
PQC/QRC: N/A
ZKP: N/A
Podpora crypt interface: N/A
Tokenizace: N/A
Jedinečnost: N/A
Ochrana credentials: N/A
Ochrana proti Replay: N/A
Ochrana proti Relay: N/A
Ochrana proti Hijack: N/A
Ochrana proti Forge: N/A
Podpora MFA: N/A
Ochrana integrity: N/A
Typ šifrování: N/A

NMAS_AUTHEN

Původní Novell Modular Authentication Services byly k dispozici od roku 1999 společně s verzí Novell NetWare 5. Tyto mechanismy byly určeny pro ověřování proti NDS (NetWare Directory Services), orientovaly se na bezpečnost a širokou podporu autentizačních metod. Souběžně s představením Novell NetWare 6.x a dalším rozvojem eDirectory (původní NDS) došlo po roce 2000 k podpoře SASL rozhraní. V současnosti technologie NMAS přešla s mezikroky přes společnost NetIQ a Microfocus pod společnost OpenText.
NMAS podporují širokou škálu authentizačních metod, od klasických metod založených na ověření hesla, přes podporu biometrického ověřování až použití tokenů. V případě zpracování hesel je jejich předzpracování založeno na PBKDF2 algoritmu, aby byla zajištěna vyšší ochrana uvedených údajů. Vlastní autentizační mechanismus NMAS_AUTHEN je určen pro ověření uživatele v rámci eDirectory a pracuje následujícím způsobem:

Client → Server: InitMessage_Client=MechanismID||ClientData
Server → Client: Challenge_Server= AuthRequestID||Nonce_Server||AdditionalData
Client → Server: RespMessage_Client = AutheRequestID||HMAC(KeyMaterial,Nonce_Server||AdditionalData)||SessionContext

Pokud je přijatá hodnota HMAC(KeyMaterial,Nonce_Server||AdditionalData) shodná se spočteno hodnotou na straně serveru, LogonStatus=Success, jinak Failure.

Server → Client: LogonStatus||HMAC(ServerKey,AuthRequestID||HMAC(KeyMaterial,Nonce_Server||AdditionalData))

Channel Binding: Ano
Realms: Ne
Kryptoprimitiva: Zastaralé(MD5, SHA-1), aktuální (SHA2)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo, biometrické údaje, klíčový materiál
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: Ano
Typ šifrování: Interní

NMAS_LOGIN

Tato metoda je návazná na ověření uživatele (NMAS_AUTHN) a slouží k jeho přihlášení ke zdrojům jako jsou síťové disky, tiskárny atd. Na rozdíl od NMAS_AUTHN nedokáže využívat vícefaktorové ověření, ale je schopná využít základní ověření zajištěné pomocí předchozí metody. Stejně jako v případě NMAS_AUTHN jsou hesla předzpracována pomocí PBKDF2.

Server → Client: Challenge_Server= Metoda||Nonce_Server
Client → Server: RespMessage_Client = Hash(Password||Nonce_Server)

Pokud odpovídá přijatá hodnota výstupu jednosměrné funkce na straně serveru, je LogonStatus=OK, jinak Fail.

Server → Client: LogonStatus

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralé(MD5, SHA-1), aktuální (SHA2)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ano
Typ šifrování: Interní

NMAS-SAMBA-AUTH

Jedná se o způsob, jak umožnit přihlášení na SMB servery (Samba, Windows) klientům NMAS. Na rozdíl od běžných systémů na platformě Microsoft Windows je zde podporováno i jednorázové heslo (OTP), což může být za jistých podmínek užitečné.

Server → Client: Challenge_Server=Metoda||Nonce_Server
V tuto chvíli závisí na volbě metody. Pro Kerberos i NTLM se liší postup, více detailů je možné najít u rozboru těchto konkrétních metod.
Po ukončení autentizace dochází k porovnání výstupů. Pokud odpovídá přijatá hodnota výstupu jednosměrné funkce na straně serveru, je LogonStatus=OK, jinak Fail.

Server → Client: LogonStatus

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Dle zvolené metody, v případě Kerberos i dle zvoleného algoritmu. Účastníků autentizace: 2, v případě použití Kerberos 5 tři strany, v případě dedikovaného SMB serveru i čtyři strany.
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne, výjimkou je použití Kerberos 5
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne, pouze v případě použití protokolu Kerberos
Ochrana proti Hijack: Ne, pouze v případě použití protokolu Kerberos
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ano
Typ šifrování: Interní

NTLM

Protokol NTLM slouží pro ověřování v sítích poskytujících služby pomocí protokolu SMB. Jedná se o starý protokol, více na toto téma je možné najít v samostatném článku na uvedené téma (Autentizace ke sdíleným složkám využívajících protokol SMB). Do jisté míry popisuje problémy, se kterými se potkává i protokol NMAS-SAMBA-AUTH.
Výzva C_Server a C_Client je náhodná 8B hodnota.

Client –> Server: Send U=Username
Server –> Client: Send C_Server

Tag_Client = (version, time, C_Client, domain name)
LMv2 = HMAC-MD5(HMAC-MD5(MD4(Password), User Name||Domain Name), C_Server, C_Client)
NTv2 = HMAC-MD5(HMAC-MD5(MD4(Password), User Name||Domain Name), C_Server, Tag_Client)

Client –> Server): LMv2 || C_Client || NTv2 || Tag_Client

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralé (MD4, MD5)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: Ano
Typ šifrování: Interní

OTP

Metoda OTP (One Time Password) spočívá v generování jednorázového hesla na základě aktuálního času nebo změny čítače. Generování zpravidla provádí token (např. RSA SecureID), ale není podmínkou. V současnosti existují podobné aplikace do mobilních telefonů a je možné je tak využít jako další faktor pro přihlašování. Obecně by se tyto metody neměly používat samostatně, důvodem může být únik inicializačních údajů (seed, jinak také user secret) a jejich následné zneužití.
Tento algoritmus využívá dvě základní metody, buď HOTP (RFC 4226) nebo TOTP (RFC 6238). Zatímco HOTP používá obecný přístup hash(seed, counter), TOTP používá hash(seed, časový interval od 1.ledna 1970). Obě uvedené metody spadají pod OATH. V obou případech je nezbytně nutné zajistit synchronizaci času tokenu a serveru, ověřujícího tuto informaci.

OTP = HMAC(seed, krok)

HOTP = RIGHT(HMAC(Seed,Counter),6)
TOTP = RIGHT(HMAC(Seed,Second since 1.Jan 1970/Time Interval,6)

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralé (MD4, MD5, SHA-1), aktuální (SHA2-256, SHA2-512)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne, slouží jako 2FA a neměl by být používán jinak
Ochrana integrity: Ne
Typ šifrování: Ne

SKEY

Algoritmus SKEY nebo S/KEY (Secure Key) je metoda pro ověření identity pomocí jednorázového hesla. Používá rekurzivní složené funkce a obvykle se používá jako druhý faktor.

SKEY=HMAC(seed, HMAC(seed, HMAC(seed, ...)))

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralé (MD5, SHA-1), aktuální (SHA2-256)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne, slouží jako 2FA a neměl by být používán jinak
Ochrana integrity: Ne
Typ šifrování: Ne

SECUREID

Jedná se o původní technologii RSA SecureID. Původně se jednalo o fyzické tokeny, časem byly dostupné i software verze. Token nebo jeho software emulace na základě tajného klíče (seedu) generovaly pomocí jednoduchých nebo složených hash funkcí každých 30s nové, zpravidla šestimístné heslo.
Časem došlo k nalezení několika zranitelností, které byly způsobeny problémy se synchronizací, úniky seedů (generujících informací) a zranitelností MITM. Obecný princip práce je podobný jako u jiných OTP:

OTP=Hash(Seed,Counter)

Channel Binding: Ne
Realms: Ne
Kryptoprimitiva: Zastaralé (MD5, SHA-1), aktuální (SHA2-256)
Účastníků autentizace: 2
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Ne
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne
Ochrana proti Hijack: Ne
Ochrana proti Forge: Ano
Podpora MFA: Ne, slouží jako 2FA a neměl by být používán jinak
Ochrana integrity: Ne
Typ šifrování: Ne

SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA2-256, SCRAM-SHA2-256-PLUS

Algoritmus SCRAM má za úklo zajistit bezpečnou alternativu pro výměnu hesla oproti čistým složeným hash funkcím. V tomto případě
klient a server sdílí klientské heslo, pro hash funkce mohou použít jak funkcí SHA-1 tak funkci SHA2-256, SHA2-384 nebo SHA2-512. Existuje ve verzích SCRAM a SCRAM-PLUS, kde druhá jmenovaná podporuje technologii Channel Binding. Ta se uplatňuje např. u GS2 nebo TLS, kde dovoluje provázat autentizaci s externí metodou nebo protokolem. V případě TLS dochází ke kódování odpovídajícího autentizačního řetězce pomocí Base64 a přidává uvedenou metodu do autentizační zprávy. Možné volby pro volbu metody ověření jsou:
tls-server-end-point: pro ověření používá hash certifikátu (fingerprint, obvykle založený na SHA2-256).
tls-unique: Používá identifikátor TLS na základě zpráv potvrzující domluvu na klíčích.
tls-exporter: Založeno na mechanismu exportu TLS klíčů dle RFC 5705.

Key1 = Hash(HMAC_algoritmus(PBKDF2_algoritmus(Password, salt, iterations),Password)
Key2 = HMAC_algoritmus(PBKDF2_algoritmus(Password, salt, iterations)
Client → Server: Signature=HMAC_algoritmus(Key1,AuthMessage)
Client → Server: Proof=Key2 ⊕ Signature

Verifikace na serveru proti přijaté zprávě:
Verify=HMAC(HMAC(PBKDF2(Hash,Password, salt, iterations),Auth Message)

Channel Binding: Ne pro základní verzi, ano pro PLUS verzi
Realms: Ne
Kryptoprimitiva: Zastaralé (SHA-1), aktuální (SHA2)
Účastníků autentizace: 2
PQC/QRC: Pouze pro SHA2-384 a SHA2-512
ZKP: Ne
Podpora crypt interface:
Tokenizace: Ne
Jedinečnost: Ano
Ochrana credentials: Heslo
Ochrana proti Replay: Ano
Ochrana proti Relay: Ne, ano pro PLUS verzi
Ochrana proti Hijack: Ne, ano pro PLUS verzi
Ochrana proti Forge: Ano
Podpora MFA: Ne
Ochrana integrity: N/A
Typ šifrování: Interní

SXOVER-PLUS

Algoritmus XOVER byl v původních návrzích pro SASL již od ranných verzí. Přestože byl popisován i ve standardu pro SASLv1 s cílem zajistit schopnost spolupráce mezi systémy (DIAMETER, EAP, Kerberos, ...), nejsou o něm žádné další zmínky. Výjimkou jsou informace o nízké bezpečnosti, způsobené chybějící podporou kryptografie. Algoritmus se spoléhal na ochranu na transportní vrstvě a byl ekvivalentem algoritmu PLAIN. Autorem byl patrně J. G. Myers, který stojí i za původním standardem. Z tohoto algoritmu se vyvinul SXOVER a jeho rozšířená verze s podporou Channel Binding SXOVER-PLUS byla následně přijata do standardu SASLv2.
Současný algoritmus SXOVER-PLUS stále není standardizován, proto veškeré poskytnuté informace popisují, jak by měl pracovat. Na základě dostupných informací by měl využívat asymetrickou kryptografii.
Výměna klíčů pomoci asymetrické kryptografie (RSA, DH, ECDH) dovoluje vytvořit sdílený symetrický klíč Key.

Server → Client: Message_Server = ("r=" || C_Server ||",cb="|| hash(Channel) ||",sk="|| PublicKey_Server ||",sid="|| ServerID )
Client → Server: Message_Client = ("c="||hash(Channel) ||",r="|| C_Client ||",ck="|| PublicKey_Client ||",sig="|| Signature_Client )

Kde v za výměnou uvedených informací stojí ECDH (Diffie Hellman domluva nad eliptickými křivkami NIST P-256 nebo Curve25519). Pro generování jednotlivých údajů se používají následující funkce:
KeyMaterial = HMAC(SharedKey, "SXOVER Key Derivation")
KeyENC = KDF(KeyMaterial, "enc")
KeyMAC = KDF(KeyMaterial, "mac")
Signature_Client = DSA(PrivateKey_Client, ServerID || PublicKey_Client || PublicKey_Server )
Pro vlastní výpočet páru klíčů se využívá běžných rovnic:

PublicKey_Server=g^{PrivateKey_Server} mod p
PublicKey_Client=g^{PrivateKey_Client} mod p
které následně dovolí domluvu nad sdíleným tajemstvím:
SharedKey_Server=PublicKey_Client^{PrivateKey_Server} mod p
SharedKey_Client=PublicKey_Server^{PrivateKey_Client} mod p

Channel Binding: Ano
Realms: Ano
Kryptoprimitiva: Aktuální
Účastníků autentizace: 2 a více
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Ne
Tokenizace: Možné, standardně ne
Jedinečnost: Ano
Ochrana credentials: Ano
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Standardně ne, ale možné konfiguračně
Ochrana integrity: Ano
Typ šifrování: Interní

Závěr

Tímto prakticky uzavřen přehled mechanismů sloužících pro ověření mezi klientem a serverem, tedy pro dvě strany (přestože některé mechanismy podporují stran více). Je vidět, že přes veškerý vývoj si dnes některé mechanismy zaslouží další rozvoj nebo nahrazení. Jejich implementace může v současnosti přinést závažné dopady, proto je nutné se u volby autentizačních mechanismů zamyslet nad jejich výhodami a nevýhodami. Další díly se budou věnovat mechanismům založeným na protokolech Kerberos, protokolům vzešlým z OAUTH a protokolům s nimi souvisejícím. Poslední díl pak bude porovnávat jednotlivé knihovny, podporované algoritmy a další zajímavé software produkty, použitelné při ověřování.

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.