نحوه کار کردن Kerberos V5
در ابتدا باید به این نکته اشاره کنم که ما در این مقاله درباره نحوه کار کردن پروتکل امنیتی Kerberos v5 صحبت میکنیم. نوشتن این مقاله بیشتر برای دوستانی هست که متخصص سرویس های مایکروسافتی هستند و خُب قطعا پایه ای ترین سرویس مایکروسافتی یعنی Active Directory. دیگه زیاد حرف نمیزنم بریم سراغ اصل مطلب، امیدوارم لذت ببرید و براتون مفید باشه.
Kerberos در مایکروسافت
خُب دوستان همونطور که شما بهتر از من اطلاع دارید، این پروتکل فقط مُختص مایکروسافت نیست و تو برند های دیگه مثل لینوکس، مک و یونیکس هم استفاده میشه.
اما در پیاده سازی که مایکروسافت انجام داده، این پروتکل رو تحت دو عنوان ارائه میکنه :
۱- Microsoft SSP(Security Support Provider)
۲- DLL(Dynamic-Link Library)
اما از اونجایی که شاید خیلی از شما با DLL آشناییت داشته باشید یا به گوشتون خورده باشه ما بیشتر درمورد SSP صحبت میکنیم. چون در اکثر موارد پروتکل Kerberos تحت عنوان SSP مطرح میشه.
حالا این سوال پیش میاد که SPP چی هست و آیا در SSP فقط پروتکل Kerberos وجود دارد یا خیر.
SSP چیه؟
درواقع SSP یک قسمتی از ویندوز هست که وظیفه انجام امور امنیتی را داره، مثل Authentication یا همان اهراز هویت. که این کار رو با استفاده از SSPI انجام میده.
SSPI چی هست؟!
SSPI یا Security Support Provider Interface، همونطور که از اسمش پیدا هست یک رابط بین SSP و اون Application هست که نیاز به مثلا Authentication داره. به عکس زیر دقت کنید :
SSP هایی که در ویندوز وجود دارند :
۱- Kerberos
۲- NTLM
۳- Digest
۴- Schannel
۵- Negotiate
۶- SSP های دیگری که میتوانند با SSPI تعامل داشته باشند.
سوال مهم!!
آیا Kerberos و NTLM استفاده میشن؟؟
در جواب این سوال باید بگم، همونطور که مایکروسافت میگه بصورت دیفالت از Kerberos استفاده میشه و اگر با Kerberos به نتیجه نرسه از NTLM استفاده میکنه. به عبارت دیگه، Kerberos SSP, Kerberos .dll رو به عنوان گزینه اول استفاده میکنه. حالا اینکه از NTLM استفاده بکنه یا نه بستگی به اون پالیسی داره که ما برای اون کامپیوتر تعریف کردیم.
نقش LSA(Local Security Authority) چیه؟
دوستان وظیفه LSA اینه که بستری امن فراهم کنه برای ارتباط بین SSP و SSPI و اون Application که نیاز به Authentication داره. به عکس زیر دقت کنید :
شاید عکس یخورده پیچیده به نظر بیاد ولی همونطور که گفتم LSA داره وظیفه خودش رو به این صورت انجام میده.
توضیح درمورد خود Kerberos
این کلمه که ریشه یونانی هم داره، به معنای سگ سه سر نگهبان هست. اما این سه سر در مایکروسافت به چه شکل هست؟
۱- Client
۲- Server(Application)
۳- KDC(Key Distribution Center)
در اینجا KDC درواقع Trusted بقیه اجزا هست یعنی Server, Client بهش اعتماد دارن.
همونطور که در عکس زیر مشاهده میکنید :
در این عکس Workstation درواقع همون Client هست.
توضیح Shared-Secret Keys
درواقع Kerberos برای Authentication شدیدا به قابلیت Shared-Secret Keys متکی هست.
درکل اگر بخوام درمورد Shared-Secret Keys صحبت کنم، باید بگم این قابلیت به این صورت است که برای مثال شما فکر کنید میلاد و علی یک رمز برای اینکه از یکدیگر مطمئن شوند دارند و این دو نفر با استفاده از این رمز میتوانند همدیگر رو اهراز هویت کنن.
دقیقا این همون اتفاقی هست که در Kerberos رخ میده. حالا برای اینکه، این کار در پروتکل Kerberos درست عمل بکنه باید Symmetric یا همون متقارن باشه. متقارن یعنی با اون تک کلید هم عملیات Encrypt و هم عملیات Decrypt انجام بشه.
در Kerberos برای اینکه هردو طرف همدیگر رو Authenticate کنن، یکی باید با اون Share-Secret key درخواست رو Encrypt کنه و طرف مقابل هم باید اگر اون کلید رو داشته بتونه Decrypt کنه و محتوا درخواست رو ببینه.
انواع Kerberos Keys
۱- Long-term symmetric keys
۲- Long-term asymmetric keys
۳- Short-term symmetric keys
پایین تر درمورد هر کدوم از این ها صحبت میکنیم.
۱- Long-term symmetric keys
– برای User, System, Service و Inter Realm keys به این صورت هستند.
– این کلید ها از Password ها بدست میان. به این صورت که از یک تابع رمزنگاری بوجود میان.(Cryptographic Function)
- User Keys :
– Long-term key از پسورد یوزر بدست میاد.
– این کلید به عنوان یک آبجکت در AD نگهداری میشه.
– User key زمانی که یوزر لاگین میکنه ساخته میشه.
– System Keys :
– وقتی سیستمی جوین دامین میشه، یک پسورد بهش داده میشه.
– از این پسورد برای ساخت Long-term key استفاده میشه.
– Service Keys :
– سرویس از کلید User Account استفاده میکنه که با اون استارت میشه.
– برای مثال اگر Service A با یوزر Milad ران میشه، از Long-term key همون یوزر استفاده میکنه.
– نکته مهم : تمامیه KDC ها در یک Realm(Domain) از یک Long-term Key استفاده میکنن. برای اینکه همه KDC ها از یوزر krbtgt استفاده میکنن.
– Inter-Realm Keys :
– برای اینکه بین دامین ها Authentication رخ بده باید KDC هایی که در دامین های متفاوت هستند، Inter-Realm Key داشته باشن تا برای ارتباط با یکدیگر بین دامین استفاده کنن.
– این Inter-Real Key درواقع مبنای Transitive Trust در Forest هست.در ادامه بیشتر توضیح داده میشه…
– اگر Shortcut Trust ایجاد کنیم، این به این معناست که اون دو دامین Inter-Realm Key مختص خودشون رو با هم Share میکنن.
۲- Long-term asymmetric keys
– درواقع همون Certificate و مبنای استفاده از Public , Private Keys هست.
۳- Short-term symmetric keys
– در Session Keys ها استفاده میشه. بعدا کاملا درمورد Session keyها توضیح میدم.
اجزای Kerberos
پروتکل Kerberos به دو سرویس اصلی تقسیم شده، که در قسمت پایین میبینید :
| KDC Service That Receives Request | Requested Ticket Type |
| Authentication Service(AS) | TGT |
| Ticket-granting Service(TGS) | Service Ticket |
همونطور که در جدول مشاهده می کنید، Kerberos client برای گرفتن TGT باید به سرویس AS وصل شود و برای درخواست Service Ticket باید به سرویس TGS وصل شود.
فرآیند درخواست TGT
TGT چیست؟
احتمالا اولین سوالی که به ذهن شما بیاید اینست که اصلا TGT چیست و چه کاربردی داره.
– زماین که کلاینت بعد از روشن شدن،ریستارت و یا Log off میخواهد Log in کند وقتی یوزر و پسورد را وارد میکند از KDC این TGT را دریافت میکند.
– TGT فقط برای درخواست دادن Service Ticket استفاده می شود.
چه کسی میتواند داخل TGT را ببیند؟
– کلاینت نمیتواند داخل TGT را ببیند.
– TGT با استفاده ازKDC Shared-secret key انکریپت می شود.
– پس فقط KDC ها میتوانند اطلاعات درون TGT را ببینند.
Session Key چیست؟
وقتی کلاینت از KDC تیکت TGT را میگیرد، KDC به کلاینت یک Session key میدهد، که کلاینت از آن Session key برای انکریپت کردن درخواست های بعدی خود استفاده میکند. برای مثال وقتی میخواهد به فایل سرور که یک سرویس در شبکه هست وصل شود، با استفاده از Session key درخواست خود را انکریپت میکند.
آیا Session key در TGT وجود دارد؟
همونطور که در بالاتر توضیح دادم KDC به همراه TGT یک Session key هم برای کلاینت ارسال میکند. اما نکته ای که وجود دارد اینست که KDC این session key با استفاده از User’s long-term key انکریپت میکند تا فقط کلاینت بتواند آن را با کلیدی که فقط بین او و KDC به اشتراک گزاشته شده است دیکریپت کند. اما درون خود TGT نیز یک session key برای خود KDC وجود دارد و همانطور که گفتم کل TGT هم با استفاده از KDC Key انکریپت شده است تا فقط خود KDC ها که در یک Realm(Domain) هستند بتوانند محتویات آن را ببینند.
نکته : از دید کلاینت TGT فقط یک تیکت معمولی هست که برای درخواست Service ticket به آن نیاز دارد. کلاینت اطلاعاتی از محتویات TGT ندارد.
دید KDC نسبت به TGT چیست؟
از نظر KDC تیکت TGT بهش این قابلیت رو میده تا هر دفعه که کلاینت درخواست میده نیاز نباشه از کلید یوزر استفاده و هر دفعه دنبال Long-term key یوزر بگرده. KDC فقط یکبار سراغ Long-term key یوزر میره اونم زمانیه که کلاینت میخواد Log in کنه.
درخواست Service Ticket(خلاصه)
– در ابتدا کلاینت credential cache خودش رو چک میکنه برای اینکه Service ticket مورد نظرش رو پیدا کنه.
– اگر نباشه دنبال TGT خودش میکرده.
– بعد Session key که باید برای ارتباط با KDC استفاده کنه رو پیدا میکنه.
– بعد با استفاده از Session key، Authenticator رو آماده میکنه.(درمورد Authenticator صحبت میشه)
– بعد درخواست Service ticket رو به همراه TGT و Authenticator میفرسته به KDC.
فرآیند درخواست Service Ticket
Service ticket برای چی استفاده میشه؟
– Service Ticket این اجازه رو به سرویس TGS(Ticket Granting Service) میده تا بتونه بصورت امن، Credential یوزر درخواست کننده رو انتقال بده به سرور مقصد.
TGS چه جوابی به درخواست Service Ticket میده؟
– در جواب، سرویس TGS دو عدد Session key رو به همراه Service ticket برای کلاینت ارسال میکنه.
– Session key که برای کلاینت هست رو با استفاده از Long-term Key خود کلاینت encrypt میکنه.
– و Session key که برای اون سرویس مدنظر هست رو، داخل Service Ticket قرار میده و کل Service Ticket رو هم با کلیدی که فقط بین KDC و اون سرویس به اشتراک گزاشته شده encrypt میکنه. پس داخل این Service Ticket رو فقط KDC و اون سرویس میتونن ببینن.
– البته این Service Ticket به کلاینت سپرده میشه، تا زمانی که بهش نیاز داره ازش استفاده بکنه و بفرسته برای سرویس مورد نظر.
چطور کلاینت از Service ticket استفاده میکند؟
– به Target service یک پیام میفرسته که شامل Service ticket و Authenticator هست.
– Service ticket هم که با کلیدی که بین KDC و Target service شِیر هست، encrypt می شود.
– Authenticator هم با Session Key که بین کلاینت و Target service استفاده میشود، encrypt میشود.
مزایای Service ticket؟
– نیازی نیست Target service، همه Session key ها رو داشته باشه و رو سیستم خودش ذخیره کنه.
– هرموقع Service ticket ارسال بشه، Target service اون Session key رو از داخل Service ticket پیدا میکنه و استفاده میکنه.
– کلاینت هم نیازی نیست، هر دفعه سراغ KDC بره و درخواست Service ticket بده. میتونه از یک Service ticket بی نهایت استفاده کنه تا زمانی که اون تیکت منقضی بشه.
یک تیکت تا چه مدت معتبر است؟
– بستگی به پالیسی Realm(Domain) داره.
– زمانی هم که یوزر Log off کند، تمامیه Credential cache پاک میشود.
داخل یک تیکت چه اطلاعاتی هست؟
– به غیر از ۳ قسمت اول، بقیه اطلاعات انکریپت میشوند.
یکی از مهمترین قسمت ها، Authorization Data هست.
Authorization Data برای Windows Client ها:
– در این قسمت اطلاعاتی مربوط به SID و Group Relative(RID) یوزر در آن قرار میگیرد.
– این اطلاعات توسط KDC و در هنگام درخواست Service ticket و یا TGT بوجود می آید.
– این اطلاعات میتونه توسط یک چیزی به اسم PAC(Privilege Attribute Certificate) هم ارائه بشه.
PAC چیه؟
– هر بار که کلاینت برای درخواست TGT یا Service ticket سراغ KDC میره، KDC این PAC رو میسازه.
– داخل PAC اطلاعاتی از کاربر مثل :
– SID و Group Relative(RID) یوزر در آن قرار میگیرد.
– اطلاعاتی درمورد User Profile. مانند Home directory و Log on script در آن قرار دارد.
– Password Credential هایی که در طول فرآیند استفاده از Smart card صورت میگیرد.
کلاینت چه اطلاعاتی درمورد Ticket داره؟
– وقتی KDC برای کلاینت Session key میفرسته، در اون پیامی که داره Session key رو میفرسته اطلاعاتی از خود تیکت رو در اون قرار میده. برای اینکه کلاینت بتونه این تیکت هارو Manage و مدیریت بکنه.
– اطلاعاتی مثل :
Authentication Time , Start Time, End Time, Renew Till
Authenticator چیست؟
– Authenticator نشون دهنده اینه که کلاینت واقعا خودش این درخواست رو داده.
– هروقت کلاینت بخواد درخواستی ارسال بکنه، فرقی نداره به KDC یا یه سرویس تو شبکه باشه. باید یک Authenticator به همراه درخواستش بفرسته.
چه ضرورتی تو ارسال Authenticator هست؟
– اون target service میتونه اعتماد بکنه به Service ticket به این دلیل که اون تیکت با کلیدی که فقط بین اون و KDC شِیر هست، encrypt شده و مطمئن هست.
– اما نمیتونه اعتماد بکنه که اون کلاینتی که صاحب این Service ticket هست، خودش این رو فرستاده. یعنی امکان داره این Service ticket توسط یک فرستنده دیگه ارسال شده باشه.
این Authenticator چطور کار میکنه؟
۱- اول از همه Authenticator با استفاده از Session key که فقط کلاینت و Target service اون رو دارن، Encrypt میشه. پس فقط اون target service و کلاینت از این session key خبر دارن و میتونن پیام های همدیگر رو با اون encrypt و decrypt کنند.
۲- خب، بعد target service از Session key خودش، که داخل Service ticket بوده استفاده میکنه و اون Authenticator رو decrypt میکنه.
۳- اگر بتونه decrypt بکنه، میتونه به اون فرستده Service ticket اعتماد بکنه.
Timestamp که داخل Authenticator هست چیه؟
– مهمترین قسمت Authenticator همین Timestamp هست.
– وقتی کلاینت داره درخواست میده و Authenticator رو میسازه، زمان سیستم خودش رو هم داخل اون data structure قرار میده.
– حالا اگر Target service به اون timestamp نگاه کنه و بفهمه که بیشتر از چند دقیقه با تایم سیستم خودش فاصله داره درخواست کاربر رو رد میکنه.
– این چند دقیقه رو ما تو پالیسی ها تعریف میکنیم و یا خود سرویس تشخیص میده که چقدر باید رو اون Timestamp حساس باشه.
دوستان این تازه قسمتی از کار KDC بود و خیلی نکات گفته نشد، امیدوارم تو مقاله های بعدی بتونم نکات بیشتر و کاربردی تری رو ارائه بدم.
منابع :
– Docs.Microsoft.com : How Kerberos V5 Works
