Čas vypršení platnosti slouží k omezení životnosti oprávnění k provádění povolené akce kýmkoli, kdo má podepsanou adresu URL.
Čas vypršení platnosti v adrese URL nelze změnit bez zneplatnění podpisu, Samozřejmě, protože je to jeden ze vstupů do HMAC, ale doba vypršení platnosti sama o sobě nepřispívá ničím ke skutečnému zabezpečení podpisového algoritmu , protože:
-
Přestože přidává informace k hašované zprávě, nepřidává žádné tajné informace.
-
Skutečnost, že adresa URL již vypršela, nezabrání zlomyslný herec z brutálního vynucení, pokud bychom předpokládali, že brutální vynucení bylo výpočetně proveditelné ... protože nepotřebujete S3, abyste potvrdili, že jste hrubě vynucené mé podpisové tajemství. Když váš podpisový algoritmus vytvoří stejný výstup jako já na základě stejného vstupu, vyhrajete. Jistě, konkrétní adresa URL, kterou jste měli, nyní vypršela, ale nyní máte moje podpisové tajemství a můžete podepsat libovolnou adresu URL, která se vám líbí, s libovolnou dobou vypršení platnosti.
Vezměte prosím na vědomí, že nic, co zde říkám, by nemělo být bráno v náznaku, že se domnívám, že bezpečnost podpisového algoritmu je chybná - můj jediný bod je, že žádný dopad na jakoukoli úroveň zabezpečení, kterou by algoritmus poskytl, kdyby doba vypršení platnosti nebyla komponentou.
Kvůli srozumitelnosti je doba vypršení platnosti součástí podepsané zprávy, protože doba vypršení platnosti je odolná proti neoprávněné manipulaci, podle definice. Platnou moji adresu URL, jejíž platnost vypršela včera, nelze vylepšit tak, aby „vypršela zítra“ a její podpis byl stále platný.
Algoritmus podpisu verze 2, který jste zmínili, je velmi přímočarý. Koncepčně můžete kanonizovat požadavek, který budete dělat, a poté jej spustit prostřednictvím HMAC. Nic zapojeného do požadavku není tajné, kromě tajného klíče. Samotný požadavek (vstupní zpráva do funkce HMAC), včetně doby vypršení platnosti, nemá žádné skryté součásti. Nemohlo to, protože pak by S3 nebyl schopen vygenerovat stejný podpis, protože ode mne neměl žádnou tajnou komunikaci o nadcházejícím požadavku - což je způsob, jakým podpisový algoritmus funguje - pro jakýkoli daný požadavek (HTTP sloveso, Content -MD5 hodnota záhlaví, pokud bude odeslána, hodnota záhlaví Content-Type, pokud bude odeslána, doba platnosti, Canonicalized X-Amz záhlaví, pokud budou odeslány, a nakonec / $ { bucket} / $ {key} {$ canonical_query_string} , všechny tyto prvky jsou zřetězeny společně s \ n mezi nimi.
S3 zná moje tajemství (jako ve skutečnosti všechny služby AWS to zjevně dělají, aby mohly ověřit mé požadavky) a pokusí se vygenerovat stejný podpis jako já. Pokud uspěje, požadavek je povolen, pokud je uživateli, jehož pověření podepsalo požadavek, skutečně umožněn požadavek.
Pokud vlastníte podepsanou adresu URL, kterou jsem vygeneroval, můžete na ni jít hrubou silou a reprodukovat zprávu, kterou bych podepsal (už víte všechno y Potřebujete to z adresy URL) a v okamžiku, kdy vypočítáváte stejný Podpis , který jsem vám dal ve své podepsané adrese URL, jste prolomili můj tajný klíč. Pro jakýkoli daný požadavek a dobu vypršení platnosti může existovat pouze přesně jeden správný podpis.
Hodně štěstí s tímto crackovacím projektem, samozřejmě, protože svůj klíč (a jeho doprovodné tajemství) otočím z aktivního stavu a deaktivuji po několika týdnech nebo měsících, dlouho předtím, než budete mít smysluplný šanci to prolomit.
Ale jde o to, že stejně jako všechny ostatní komponenty, které vstupují do zprávy, kterou používám HMAC, vidíte v adrese &Expires = a víte, jaká hodnota tam jde, v za účelem reprodukce původní zprávy, kterou jsem podepsal. Vypršení platnosti nedělá nic pro to, aby váš úkol zkomplikovalo.
Ne, vypršení platnosti je přísně určeno k řízení platné doby trvání podepsané adresy URL, kterou rozdávám, na základě teorie, že k neoprávněnému přístupu k této adrese URL trvá určitou dobu . Čím jsou informace obecně citlivější, tím kratší byste měli nastavit dobu vypršení platnosti požadavku.
Boční poznámky: Zahrnutí doby vypršení platnosti také poskytuje serverům typu back-end menší optimalizaci, která můžete prokázat sami - doba platnosti je kontrolována první , než je ověřena platnost podpisu. Koneckonců nemá smysl utrácet cykly CPU za pokus o ověření podpisu, který je doprovázen časem vypršení platnosti, který jasně naznačuje, že jeho platnost vypršela. Zdá se, že S3 zkratuje tuto zbytečnou práci tím, že po uplynutí doby vypršení platnosti vrátí stejnou chybu „Žádost vypršela“, bez ohledu na to, zda je podpis platný či nikoli. Můžete to potvrdit ruční změnou doby vypršení platnosti platného požadavku. Pokud jej nastavíte do minulosti, podpis se zneplatní, ale zobrazí se chyba „Žádost vypršela.“ Nastavíte-li to do budoucna, také to zneplatní podpis, ale chyba, kterou získáte, znamená, že podpis je neplatný.
Také: Podpis verze 4 je mnohem složitější - a dokonce bezpečnější - algoritmus než V2, používající 5 vnořených iterací HMAC-SHA256 ... a není jich 5 iterací kvůli mylné představě, že „více je lepší.“
Ve skutečnosti to trvalo chvíli, než se se mnou ponoří důsledky designu tohoto algoritmu, a vypadá to jako docela geniální.
Pokud odloupnete vrstvy, je zřejmé, že AWS navrhl tento algoritmus tak, aby interně (tj. v rámci AWS) delegoval důvěru podle principu nejmenších privilegií.
Nejvnitřnější iterací HMAC je zpráva skládající se z dnešního data, podepsaná tajemstvím složeným z řetězce „AWS4“ + moje tajemství. To je DateKey. Je to dobré jen 7 dní. Úložiště centrálního zabezpečení IAM je jediná entita, která zná mé tajemství a můj DateKey.
Další iterace podepíše doslovný název oblasti AWS (např. us-west-2 ) pomocí výstupu DateKey odvodit DateRegionKey. IAM pak může dodat tuto hodnotu svým subsystémům v každé oblasti, aby věděli vše, co potřebují vědět, aby mohli ověřit své podpisy pro svou oblast, ale ne globálně.
Dále název služby AWS ( např. s3 ) je podepsán s DateRegionKey, aby vygeneroval DateRegionServiceKey. S každou oblastí mohou subsystémy IAM generovat toto tajemství pro každou službu a doručovat každé službě vše, co služba potřebuje vědět, aby mohla ověřit své podpisy pro svou službu, v této jedné oblasti - a (znovu) nic víc.
Poté je řetězec „aws4_request“ podepsán DateRegionServiceKey, aby vytvořil můj denní podpisový klíč. Jelikož „aws4_request“ je v podstatě jen řetězec, může každá služba odvodit (nikoli uložit) podpisový klíč, který dnes použiji k podepisování požadavků, takže bude mít pouze informace, které potřebuje, a nic víc.
Nakonec se můj denní podpisový klíč používá k podepsání každé kanonizované žádosti.
Vidíte, co tam udělali?
Žádný systém kromě jádrového systému IAM nemusí znát mé skutečné tajemství. Pokud by došlo k vnitřnímu narušení, řekněme, v infrastruktuře regionu S3 (jakkoli nepravděpodobné to je), informace, které by útočník mohl získat, by jim neprozradilo mé skutečné tajemství - pouze tajemství, které si S3 v tomto regionu bylo vědomo. Pokud by došlo k narušení regionální infrastruktury, získané pověření by bylo zbytečné v jiných regionech atd., V řetězci až ke kořenu.
Algoritmus V4 je jádrem toho, co se jeví jako bezpečný, globálně distribuovaný tajný systém pro podepisování klíčů, kde je vše interně založeno na potřebě vědět. Jak říkám ... vypadá to docela brilantně.