1 / 33

Kerberos

Kerberos. Projektování distribuovaných systémů Ing. Jiří ledvina, CSc. Úvod. v řecké mytologii Kerberos nebo Cerberus hlídal záhrobí. Obrovský tříhlavý pes s hadem místo ocasu a s nepočitatelně hadími hlavami na zádech. Hlídal bránu do záhrobí, aby mrtví nemohli ven a živí dovnitř.

nantai
Download Presentation

Kerberos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Kerberos Projektování distribuovaných systémů Ing. Jiří ledvina, CSc

  2. Úvod • v řecké mytologii Kerberos nebo Cerberus hlídal záhrobí. Obrovský tříhlavý pes s hadem místo ocasu a s nepočitatelně hadími hlavami na zádech. Hlídal bránu do záhrobí, aby mrtví nemohli ven a živí dovnitř. • vznikl v souvislosti s projektem Athena v MIT • zajišťuje ověřování uživatelů a požadovaných služeb • architektura server/klient • k ověřování využívá důvěryhodnou třetí stranu (ověřovací server AS) Projektování distribuovaných systémů

  3. Úvod • vyžaduje prokazování identity klienta pro každý požadavek na službu • klient se prokazuje heslem pouze jednou (přihlašování) • heslo se nikdy nepřenáší sítí a není uloženo ani v paměti • každý klient a každá služba mají heslo • všechna hesla zná pouze ověřovací server • existuje Kerberos V4 a Kerberos V5 Projektování distribuovaných systémů

  4. Požadavky uživatelů • povolení přístupu podle počítače • kontrola identity uživatele • požadavek dokazování identity pro každou službu • předpokládá, že uživatelé ovládají počítače (boot) • předpokládá, že síť není bezpečná Projektování distribuovaných systémů

  5. Požadavky na identifikační mechanizmus • bezpečný, nedovoluje maskování se • spolehlivý, musí se jevit jako celek jako systém služeb • transparentní, uživatel o něm neví • odstupňovaný, uživatel nemusí být "kerberizovaný" • požadavek na bezpečnost se přesouvá na několik bezpečných serverů • Úrovně ochrany • ověřování při přihlašování • ověřování každé zprávy (zabezpečení pravosti zprávy) • ověřování a šifrování (zabezpečení soukromí) Projektování distribuovaných systémů

  6. Databáze • Databáze Kerbera • obsahuje jméno uživatele a jeho privátní klíč • umožňuje ověření Kerbera i uživatele • pro uživatele generuje dočasné klíče (relační klíče) • použití zejména pro šifrovanou komunikaci dvou klientů • citlivé informace jsou v Kerberu • ostatní v serveru HESIOD (řecký pěvec a básník žijící asi 700 let p.n.l.) Projektování distribuovaných systémů

  7. Šifrování • používá DES, Kerberos V5 i jiné šifrovací algoritmy • metody šifrování zprávy • CBC (Cypher Block Chaining) – pro daný blok cn+1 = E(mn+1  cn) • PCBC (Propagated CBC) – pro celou zprávu cn+1 = E(mn+1  mn  cn) Projektování distribuovaných systémů

  8. Servery • Administrativní server • KDBM (Kerberos Database Management) • zajišťuje přístup do databáze Kerbera • klient může být kdekoliv, server u databáze • Ověřovací server (Kerberos server) • provádí pouze operace čtení nad databází • ověřování uživatelů • generování relačních klíčů • může pracovat s kopiemi databází • uživatelské programy • přihlašování do Kerbera • změna hesla • zobrazení tiketů • ničení tiketů Projektování distribuovaných systémů

  9. Jména • primární jméno – jméno uživatele nebo služby • instance – name.instance@realm • pro uživatele – jkl.root, jkl.admin • pro sužbu – rlogin.stroj • realm – jméno administrativní entity, která obhospodařuje ověřovaná data Projektování distribuovaných systémů

  10. Pověření (Credentials) • tickety (lístky) – časově omezený "průkaz" opravňující čerpat nějakou službu, šifrovaný blok dat obsahující identitu klienta a jeho požadavku • každý požadavek na službu vyžaduje ticket • ticket zajišťuje přístup jednoho klienta k jedné službě • tickety vydává Ticket Granting Server (TGS), který má přístup ke všem šifrovacím klíčům • tickety nemají vztah ke klientům – pouze zajišťují přístup k serverům • každý ticket má omezenou dobu života (hodiny, dny) • {S, C, IPC, TS, TTL, KS,C}K(S) Projektování distribuovaných systémů

  11. Pověření (Credentials) • authenticators (ověřovače) • umožňuje ověřit pravost klienta, šifrovaná informace o klientovi (pro jedno použití) • {C, IPC, TS}K(S,C) Projektování distribuovaných systémů

  12. Ticket {S, C, IPC, TS, TTL, KS,C}K(S) • může být použit vícekrát (omezeno dobou života – hodiny, dny) • obsahuje následující informace • jméno serveru (S) • jméno klienta (C) • IP adresu stroje klienta (IPC) • časové razítko (TS) • dobu života ticketu (TTL) • náhodný relační klíč (KS,C) • šifrováno klíčem serveru, kterému je určen (KS) Projektování distribuovaných systémů

  13. Authenticator {C, IPC, TS}K(S,C) • slouží k ověření pravosti klienta (údaje o klientovi se porovnají s údaji v ticketu) • vystaven klientem pro jedno použití • obsahuje následující informace • jméno klienta (C) • IP adresu stroje klienta (IPC) • běžný čas • šifrováno relačním klíčem K(S,C) Projektování distribuovaných systémů

  14. Funkce Kerbera • pokud chce klient kontaktovat server, musí si nejprve vyžádat od TGS ticket a relační klíč • pokud chce komunikovat s TGS, musí mít TGT (Ticket Granting Ticket) a relační klíč pro komunikaci s TGT • obojí získá na základě ověření hesla od AS • existují tři fáze ověřování • získání pověření pro přístup k dalším službám (credentials – pověřovací listiny) • požadavek ověření pro specifickou službu • prezentace pověření koncovému serveru • ověřovací server (Kerberos AS) ověří pravost klienta • Ticket granting server – na základě ověření klienta poskytuje tickety (lístky) pro přístup k požadovaným serverům (službám) • Komunikace mezi entitami vyžaduje přísnou synchronizaci času Projektování distribuovaných systémů

  15. Získání prvotního ticketu • klient zadá jméno a pošle AS požadavek přístupu k TGS (otevřený text) • klient zadá heslo, převede je na klíč KC a dešifruje zprávu od AS • obdrží relační klíč pro komunikaci s TGS (KC,tgs) a ticket pro komunikaci s TGS {TC,tgs}Ktgs C: {C, tgs} AS: {KC,tgs, {TC,tgs}Ktgs}KC Projektování distribuovaných systémů

  16. Získání prvotního ticketu • ticket obsahuje jméno klienta, jméno TGS, čas, dobu života, IP adresu klienta a relační klíč pro komunikaci klient – TGS • informaci není možné změnit, protože je šifrována tajným klíčem Ktgs pro komunikaci AS – TGS • ticket TC,tgs jméno klienta, jméno TGS, čas, dobu života, IP adresu klienta, relační klíč pro komunikaci klient – TGS • klient KC,tgs a {TC,tgs}Ktgs schová, KC a heslo smaže. Projektování distribuovaných systémů

  17. Získání ticketu pro server • pro každý server je třeba jiný ticket • tickety poskytuje TGS (Ticket Granting Server) • klient vytvoří authenticator AC, obsahující jméno klienta, IP adresu a čas • Zašifruje jej relačním klíčem KC,tgs, přidá {TC,tgs}Ktgs a pošle požadavek TGS C: {S, {TC,tgs}Ktgs , {AC}KC,tgs} TGS: {{TC,S}KS , KC,S} KC,tgs} Projektování distribuovaných systémů

  18. Požadavek na službu • klient má ticket pro vybraný server • opět (aplikace) vytvoří authenticator AC, obsahující jméno klienta, IP adresu a čas • Zašifruje jej relačním klíčem KC,S, přidá {TC,S}KS a pošle požadavek serveru S • server dešifruje požadavek, porovná jméno klienta, IP adresu, čas, dobu platnosti • klient vyžaduje vzájemné ověření • server pošle zpět hodnotu časové značky zvýšenou o 1 C: {{TC,S}KS , {AC}KC,S} S: {{TS+1}KC,S} Projektování distribuovaných systémů

  19. Přihlášení klienta na server s ověřením (shrnutí) C  AS:[C, tgs] AS  C: [{KC,tgs, {TC,tgs}Ktgs}KC] C  TGS: [S, {TC,tgs}Ktgs , {AC}KC,tgs] TGS  C: [{KC,S {TC,S}KS , } KC,tgs] C  S: [{TC,S}KS , {AC}KC,S] S  C: [{TS+1}KC,S] Projektování distribuovaných systémů

  20. Operace databáze Kerbera • operace read – používá se pro ověřování (ochrana – není možné data modifikovat) • operace r/w – administrativní operace – údržba databáze • prováděny tzv. administrativní službou – Kerberos Database Management Service (KDBM) • opravy jsou prováděny do master kopie, neběží-li, nemohou být prováděny • požadavky uživatelů na změnu hesla • kpasswd – změna hesla, přidání/ubrání uživatele, přidání/ubrání služby • kadmin – klientský program administrátora Projektování distribuovaných systémů

  21. Administrativní protokol C  AS:[C, kdbm] AS  C: [{KC,kdbm, {TC,kdbm}Kkdbm}KC] C  KDBM: [S, {TC,kdbm}Kkdbm , {AC}KC,kdbm] (požadavek S = {kadmin | kpasswd}) Projektování distribuovaných systémů

  22. Replikace databáze • každý realm (království) má master Kerberos server (hlavní) • údržba master copy databáze • mohou existovat kopie v podřízených Kerberos serverech • problém údržby konzistentní databáze – přepis každou hodinu • kprop – program pro posílání obrazu databáze • kpropd – daemon v podřízených serverech • nejprve se pošle kontrolní součet databáze (šifrovaný klíčem pro komunikaci master – slave Kerberos (Master Database Key)) • pak se pošle databáze a zkontroluje se kontrolní součet • všechna hesla v databázi jsou šifrována pomocí Master Database Key Projektování distribuovaných systémů

  23. Programy Kerbera • kinit – přihlášení do Kerbera • program pro obdržení nového ticketu od ověřovacího serveru (AS) • implicitně tgt, ale i jiné tickety (kinit –S <service_name>) • klogin – pokud máme ticket, umožní přihlásit se na počítač • klist – výpis všech ticketů uživatele • kdestroy – vymazání ticketů Projektování distribuovaných systémů

  24. Kerberos v5 • K reprezentaci syntaxe používá ASN.1 • Není jednoduché číst • Velmi flexibilní(Volitelná pole, proměnná délka polí, rozšiřitelný soubor hodnot) • Rozšířený soubor šifrovacích algoritmů • Podporuje delší dobu života ticketů • Podporuje více adres v ticketu • Zavádí předauthentikaci – obrana proti útokům na heslo • Dovoluje delegování uživatelských práv Projektování distribuovaných systémů

  25. Delegování práv • Delegování – předání práv někomu jinému aby mohl využívat naše služby • Klasické řešení bez delegování • Předání mého klíče nebo hesla někomu jinému • Předání mých tiketů někomu jinému • Kerberos v5 podporuje následující metody • A požádá KDC o vytvoření TGT ticketu se síťovou adresou B • Předání TGT s odpovídajícím relačním klíčem do B • A požádá KDC o vytvoření TGT přímo pro B se síťovou adresou B • A vezme TGT a předá jej B • Spolu s „autorizačními daty“ které budou poslány do aplikační služby Projektování distribuovaných systémů

  26. Delegování práv • Tranzitivní delegování • B deleguje do C práva, delegovaná do B z A • TGT: dovoluje to, pokud je označen jako „forwardovatelný“ • Tikety: dovoluje to, pokud je označen jako „proxiable“ (zastupitelný) Projektování distribuovaných systémů

  27. Pre-authentikace • Druhá zpráva je šifrována klíčem KA,AS AS  C: [{KC,tgs, {TC,tgs}Ktgs}KC] • Revize: A posílá do AS předautentikační data • Časová značka šifrovaná sdíleným klíčem KC • Dokazuje, že zná klíč Projektování distribuovaných systémů

  28. Obnova ticketů • Tikety ve v5 mají prodlouženou platnost • Musí být ale periodicky obnovovány • Obsahují • Čas autorizace • Počáteční a koncový čas (platný od – do) • Čas do kterého musí dojít k obnově • Tiket, kterému vypršela doba platnosti nemůže být obnoven • Musí se požádat o nový tiket • Tikety mohou být také „datovány post “ • Platí až v budoucnosti Projektování distribuovaných systémů

  29. Kryptografické algoritmy • Zajištění integrity zpráv • MD5 + šifrování výsledku DES s využitím sdíleného tajného klíče • Šifrování plus integrita • Základ – DES/CBC s CRC • Rozšíření – 3DES s HMAC/SHA1 • Nově – AES/CBC s HMAC/SHA1 Projektování distribuovaných systémů

  30. Zavedení konverzačních klíčů • Použití různých klíčů pro různá spojení s týmž serverem • Realizováno při předávání ticketu z klienta do serveru • Omezuje použití relačního klíče pouze pro tuto relaci Projektování distribuovaných systémů

  31. Ověřování mezi oblastmi • Oblasti (realms) – skupina zdrojů sdílená jednou autoritou z hlediska ověřování • Často je to totéž jako DNS doména • Označováno jménem domény • Oblast obsahuje • KDC (Key Distribution Center) – TGS, AS, databáze • Uživatele • Servery • Pokud potřebuje uživatel přistupovat ke službám v jiných oblastech? Projektování distribuovaných systémů

  32. Ověřování mezi oblastmi • Pokud potřebuje uživatel přistupovat ke službám v jiných oblastech • Jednoduché řešení – vyžaduje registraci uživatele ve všech oblastech • Uživatel se musí ověřovat ve všech znova • Složitější řešení • KDC vzájemně kooperují při ověřování • Inter-realm authentication • Předem se musí domluvit na sdílených klíčích • Pokud chce klient přistupovat ke službám v jiné oblasti, musí požádat o cross-realm TGT • Ten pak použije při požadování cizí služby Projektování distribuovaných systémů

  33. Ověřování mezi oblastmi Projektování distribuovaných systémů

More Related