1. Kerberos & X.509 فصل يازدهم مبتني بر فصل 11 از کتاب
Network Security, Principles and Practice,2nd Ed.
ويرايش شده توسط: حميد رضا شهرياري

2. افسانه يوناني سگ سه سر افسانه يوناني : محافظان دروازه هاي جهنم!
سرها نماد:
Authentication
Authorization
Accounting
اگرچه در عمل تنها احراز هويت اعمال شد.

3. انگيزه محيطهاي جديد: به صورت توزيع شده
در يک محيط توزيع شده سه روش براي امنيت:
اعتماد به ايستگاه کاري در معرفي کردن کاربران خود و اعمال سياست امنيتي مبتني بر شناسه کاربران
نياز به احراز هويت سيستمهاي client توسط کارگزار ولي اعتماد به سيستمهاي client نسبت به هويت شناسي کاربران خود
نياز به احراز هويت هر يک از کاربران نسبت به سرويس درخواستي و بالعکس

4. کربروس احراز هويت بر اساس رمز نگاري کليد مخفي (متقارن)
طراحي شده در MIT
به جاي احراز هويت در هر کارگزار به صورت توزيع شده، يک کارگزار خاص را به احراز هويت اختصاص ميدهيم
نسخه هاي 4 و 5 آن در حال استفاده هستند

5. نيازمنديها/ويژگيهاي عمومي کربروس
عمومي بودن(Common)
در محيط توزيع شده همراه با سرورهاي متمرکز و غير متمركز
امنيت (Security)
ادعاي اصلي
اطمينان (Reliability)
اطمينان از دسترسي پذيري کارگزار هويت شناسي (کربروس)
شفافيت (Transparency)
کاربران بايد سيستم را همانند يک سيستم ساده “شناسه و کلمه عبور” ببينند.
مقياس پذيري (Scalability)
قابليت كار با تعداد زيادي ماشين كاربر و كارگزار

6. ويژگيهاي عمومي کربروس چند تعريف
دامنه: يک محدوده دسترسي را مشخص مي کند. به نوعي معادل دامنه هاي تعريف شده در ويندوز مي باشد.
مرکز توزيع کليد: معادل کارگزار کربروس مي باشد.
Principal : به سرويس ها، دستگاه ها، کاربران و کليه عناصري که احتياج به شناساندن خود به کارگزار کربروس دارند، گفته مي شود.

7. کربروس
براي معرفي کربروس به صورت گام به گام از پروتکلهاي ساده شروع مي کنيم و سعي مي کنيم اشکالات هر يک را برطرف کنيم تا به کربروس برسيم.

8. ديالوگ ساده احراز هويت-0
فرص: بين AS و هر کارگزار يک کليد مشترک وجود دارد.
درخواست خدمات توسط کارفرما از کارگزار:
Client  AS: IDclient || PassClient || IDServer
AS  Client: Ticket
Client  Server: IDclient || Ticket
AS : Authentication Serverکارگزار احراز هويت
Kserver: Shared key between AS and Server
Ticket = EKserver [IDclient || Addrclient || IDserver]

9. بليط
در واقع نوعي گواهي است كه هنگام ورود كاربر به قلمرو کربروس به او داده مي شود كه بيانگر اعتبار او براي دسترسي به منابع شبكه مي باشد.

10. بررسي ديالوگ چرا آدرس کارفرما (Client) در بليط ذکر ميشود؟
در غير اين صورت هر شخصي که بليط را از طريق شنود به دست آورد نيز ميتواند از امکانات استفاده کند. اما اکنون تنها خدمات به آدرس ذکر شده در بليط ارايه ميشود.
مشکل جعل آدرس
چرا شناسه کارفرما IDclient در گام سوم به صورت رمز نشده ارسال ميشود؟
زيرا اين اطلاعات به صورت رمزنگاري شده در بليط وجود دارد.
اگر شناسه با بليط مطابقت نداشته باشد خدمات ارايه نمي شوند.

11. مشکلات ديالوگ ساده احراز هويت-0
ناامني
ارسال كلمه عبور بدون رمزگذاري (به شكل متن واضح)
امکان حمله تکرار
ناکارآيي
لزوم تقاضاي بليط جديد براي هر خدمت

12. استفاده مجدد از بليط ها
چرا استفاده مجدد از بليط ها (Tickets) اهميت دارد؟
جلوگيري از تايپ مجدد کلمه عبور در يک بازه زماني کوتاه
شفافيت احراز هويت
کاربر متوجه فرآيندهاي هويت شناسي نمي شود.

13. افزايش ايمني-ديالوگ 1
استفاده از يک کارگزار جديد با نام کارگزار اعطا کننده بليط
TGS: Ticket Granting Server
کارگزار احراز هويت، AS ، کماکان وجود دارد.
بليط “اعطاء بليط” ticket-granting ticket توسط آن صادر مي شود.
اگرچه بليطهاي اعطاء خدمات توسط TGS صادر ميشوند.
بليط “اعطاء خدمات” service-granting ticket
اجتناب از انتقال کلمه عبور با رمز کردن پيام کارگزار احراز هويت (AS) به کارفرما توسط کليد مشتق شده از کلمه عبور

14. کارفرما با کمک کليد مشترک خود و AS بليط TGS را بازيابي ميکند.
افزايش ايمني -ديالوگ1
TGS
Client
جلسه Log In
1. IDClient || IDTGS
3. IDClient || IDServer || TicketTGS
2. EKClient [TicketTGS]
4. TicketServer AS
کارفرما با کمک کليد مشترک خود و AS بليط TGS را بازيابي ميکند.
5. IDClient || TicketServer
Server

15. افزايش ايمني -ديالوگ1
پيامهاي شماره يک و دو به ازاء هر جلسه Log on رد و بدل ميشوند.
پيامهاي شماره سه و چهار به ازاء هر نوع خدمات رد و بدل ميشوند.
پيام شماره پنج به ازاء هر جلسه خدمات رد و بدل ميشود.
Client  AS: IDClient || IDTGS
AS  Client: EKClient [TicketTGS]
Client  TGS: IDClient || IDServer || TicketTGS
TGS  Client: TicketServer
Client  Server: IDClient || TicketServer

16. محتوي بليط ها
بليط اعطاي بليط :
بليط اعطاي خدمات :

17. ويژگي هاي ديالوگ 1
دو بليط صادر شده ساختار مشابهي دارند. در اساس به دنبال هدف واحدي هستند.
رمزنگاري TicketTGS جهت احراز هويت
تنها کارفرما مي تواند به بليط رمزشده دسترسي پيدا کند.
رمز نمودن محتواي بليطها تماميت (Integrity) را فراهم ميکند.
استفاده از مهر زماني (Timestamp) در بليطها آنها را براي يک بازه زماني تعريف شده قابل استفاده مجدد مي کند.
هنوز از آدرس شبکه براي احراز هويت بهره مي گيرد.
چندان جالب نيست زيرا آدرس شبکه جعل (Spoof) مي شود.
با اين حال، درجه اي از امنيت مهيا مي شود

18. نقاط ضعف ديالوگ 1 مشكل زمان اعتبار بليطها:
زمان كوتاه : نياز به درخواست هاي زياد گذرواژه
زمان بلند : خطر حمله تکرار
هويت شناسي يک سويه : عدم احراز هويت کارگزار توسط كارفرما
رسيدن درخواست ها به يك کارگزارغيرمجاز

19. کربروس نسخه 4 توسعه يافته پروتکل هاي قبلي است.
مشکل حمله تکرار حل شده است.
احراز هويت دو جانبه (mutual) برقرار ميشود.
کارگزاران و کارفرمايان هر دو از هويت طرف مقابل اطمينان حاصل ميکنند

20. مقابله با حمله تکرار
يک نياز جديد: کارگزار يا TGS بايد اطمينان حاصل نمايند که کاربر بليط همان کسي است که بليط براي او صادر شده.
مفهوم جديدي به نام اعتبار نامه (Authenticator) ابداع شده است:
علاوه بر بليط ها از مفهوم کليد جلسه بهره مي جويد

21. کربروس نسخه 4: بررسي الگوريتم-1
1. IDClient|IDtgs|TS1
2. EKClient[KClient,tgs|IDtgs|TS2|Lifetime2|Tickettgs]
Client AS
Tickettgs=EKtgs[KClient,tgs|IDClient|AddrClient|IDtgs|TS2|Lifetime2]

22. تمامي با کليد مشترک AS و TGS رمز شده اند
Tickettgs=EKtgs[KClient,tgs|IDClient|AddrClient|IDtgs|TS2|Lifetime2]
کليد جلسه بين کارفرما و TGS
شناسه کارفرما
مهر زماني و
دوره اعتبار بليط
آدرس کارفرما
شناسه TGS

23. نتايج اين مرحله براي كارفرما
بدست آوردن امن بليط ”اعطاء بليط“ از AS
بدست آوردن زمان انقضاي بليط(TS2)
بدست آوردن كليد جلسه امن بين کارفرما و TGS

24. بدست آوردن بليط “اعطاء خدمات”
3. IDserver|Tickettgs|AuthenticatorClient
4. EKClient,tgs [KClient,server|IDserver|TS4|Ticketserver]
Client
TGS
TicketServer=
EKserver[KClient,server|IDClient|AddrClient|IDserver|TS4|Lifetime4]
AuthenticatorClient=
EKClient,tgs[IDClient|AddrClient|TS3]

25. تمامي با کليد کارگزار رمز شده اند
بليط کارگزار
تمامي با کليد کارگزار رمز شده اند
TicketServer= EKserver[KClient,server|IDClient|AddrClient|IDserver|TS4|Lifetime4]
کليد جلسه بين کارفرما و کارگزار
شناسه کارفرما
مهر زماني و
دوره اعتبار بليط
آدرس کارفرما
شناسه TGS

26. تمامي با کليد جلسه رمز شده اند
اعتبار نامه کارفرما
تمامي با کليد جلسه رمز شده اند
AuthenticatorClient= EKClient,tgs[IDClient|AddrClient|TS3]
آدرس کارفرما
شناسه کارفرما
مهر زماني

27. نتايج اين مرحله براي كارفرما
جلوگيري از حمله تکرار با استفاده از يك اعتبار نامه (Authenticator) يكبار مصرف كه عمر كوتاهي دارد.
بدست آوردن كليد جلسه براي ارتباط با کارگزار V

28. دستيابي به خدمات سرور 6. EKClient,Server [TS5+1]
5. TicketServer|AuthenticatorClient
6. EKClient,Server [TS5+1]
Server
Client

29. نتايج اين مرحله براي كارفرما
احراز هويت کارگزار در گام ششم با برگرداندن پيغام رمزشده
جلوگيري از بروز حمله تکرار

30. کربروس نسخه 4: شماي کلي

31. کربروس نسخه 4: شماي کلي

32. قلمرو کربروس (realm)
قلمرو کربروس از بخشهاي زير تشكيل شده است:
کارگزار کربروس
کارفرمايان
کارگزاران كاربردي Application Servers
کارگزار کربروس گذرواژه تمام کاربران را در پايگاه داده خود دارد.
کارگزار کربروس با هر کارگزار كاربردي کليدي مخفي به اشتراک گذاشته است.
معمولاً هر قلمرو معادل يک حوزه مديريتي است.

33. هويت شناسي بين قلمرويي

34. کربروس نسخه 5 مشخصات در اواسط دهه 1990 مطرح شد
نقص ها و كمبودهاي نسخه قبلي را برطرف كرده است
به عنوان استاندارد اينترنتي RFC 1510 در نظر گرفته شده است.
ويندوز 2000 از استاندارد اينترنتي کربروس نسخه 5 به عنوان روش اصلي هويت شناسي کاربران استفاده مي کند.

35. مشكلات Kerberos v4 و نحوه رفع آنها در نسخه 5
وابستگي به يك سيستم رمزنگاري خاص(DES)
+ در نسخه 5 مي توان از هر الگوريتم متقارن استفاده كرد
وابستگي به IP
+ در نسخه 5 مي توان از هر آدرس شبكه(مثلا OSI يا IP) استفاده كرد
محدود بودن زمان اعتبار بليطها
+ در نسخه 5 اين محدوديت وجود ندارد

36. مشكلات Kerberos v4 و نحوه رفع آنها در نسخه 5
امكان انتقال اعتبار يك كاربر به يك سرور ديگر وجود ندارد
+ مثلا DBMS نياز دارد براي پاسخ دادن به پرس و جوي کاربر، برخي داده ها را از يک پايگاه داده ديگر بگيرد.
با افزايش تعداد قلمروها، تعداد كليدها بصورت تصاعدي افزايش مي يابد
+ در نسخه 5 اين مشكل حل شده است.

37. کربروس نسخه 5: شماي کلي V V

38. پياده سازي هاي موجود
دانشگاه MIT : اولين پياده سازي کربروس که هنوز به عنوان مرجع مورد استفاده قرار مي گيرد
Heimdal : تنها پياده سازي انجام شده در خارج آمريکا
Active Directory : پياده سازي ارائه شده توسط مايکروسافت که در RFC 1510 آمده است

39. گواهي X-509 CA Directory Certificate Authority Bob Alice
Alice’s Public Key CA
Bob’s Public Key
Publish
Retrieve Alice’s
Certificate
Retrieve Bob’s
Certificate
Bob’s Public
Key Certificate
Alice’s Public
Key Certificate
Directory

40. مباني PKI نكته اصلي در رمزنگاري نامتقارن:
“ چه كسي كليد خصوصي متناظر با يك كليد عمومي را دارد؟”
در پاسخ به يك پيغام، بايد مطئن بود كه دريافت كننده همان است كه مورد نظر ما است.

41. مباني PKI بايد كليد عمومي در دسترس عموم باشد با تضمين تعلق.
با كليد عمومي يك نفر، چه كاربردي مجاز است؟ ارسال نامه يا امضاء قرارداد؟
راه حل بايستي مقياس پذير (Scalable) باشد.

42. گواهي‌‌هاي ساده كارت ويزيت به عنوان حمل كننده كليد عمومي.
روي كارت مشخصات دارنده كارت.
پشت كارت RSA Public key
شكل 3-1

43. گواهي‌‌هاي ساده

44. ويژگي‌ها 1 خيلي رايج است. تماس مستقيم لازم است تا كارت داده شود.
صرفاً ادعاي ارائه دهنده كارت است و لذا اعتبار صددرصد ندارد.
كليد عمومي را بايد تايپ كرد.

45. ويژگي‌ها 2 اگر كليد خصوصي گم شود نمي‌توان به دارندگان كارت اعلام كرد.
اگر آدرس تغييركند نمي‌توان به دارندگان كارت اعلام كرد.
قابل جعل است.

46. كارت اعتباري 1 حاوي كليد عمومي نيست. مشخصات دارنده كارت را دارد.
صادركننده مشخص است.
تاريخ انقضاء.

47. كارت اعتباري 2
صرفاً به كساني كه همديگر را ملاقات كرده‌اند محدود نمي‌باشد. صادركننده، دارنده كارت، فروشنده سه عنصر متمايز هستند.
امضاء‌ دارد به نحوي كه مي‌توان تعلق كارت را به دارنده كنترل كرد.
اطلاعات كارت از طريق نوار مغناطيسي قابل انتقال است.

48. تركيب كارت ويزيت و كارت اعتباري.
گواهي ايده‌آل
تركيب كارت ويزيت و كارت اعتباري.
ويژگي‌‌ها:
1- شيئي ديجيتالي باشد كه توزيع آن ساده باشد.
2- حاوي نام و مشخصات كاربري كه دارنده كليد خصوصي متناظر است، باشد.
3- تاريخ توليد گواهي را دارا باشد.

49. گواهي ايده‌آل
4- صادركننده گواهي معتبر باشد. 5- گواهي صادره بين گواهي‌هاي توليد شده توسط صادر كننده منحصر بفرد باشد. 6- منقضي نشده باشد. 7- اطلاعات گواهي قابل تغيير و جعل نباشد. 8- به سرعت بتوان اعلام كرد كه منبع گواهي معتبر نيست. 9- ذكرشده باشدكه گواهي به چه كاربردهايي تناسب دارد.

50. Certificate:= ( Public Key, ID, EKRCA(Certificate - Signature) )
گواهي كليد عمومي 1
گواهي (Certificate) مستند رسمي براي تضمين تعلق شناسه به كليد.
گواهي به وسيله يك مركز مطمئن (CA) امضا، شده است.
Certificate:= ( Public Key, ID, EKRCA(Certificate - Signature) )

51. گواهي كليد عمومي 2
جامعيت گواهي به راحتي قابل كنترل است. هر تغييري در آن به سادگي كنترل مي‏شود.
ارسال و ذخيرة گواهي به شكل رمز نشده.
براي خواندن محتوي گواهي به كليد عمومي CA نياز داريم.
تقريباً همگي مشخصات گواهي ايده‌آل در گواهي كليد عمومي است. (مورد 1 تا 7)

52. گواهي كليد عمومي 2

53. استفاده از گواهي براي كنترل درستي امضاء

54. عدم اعتبار گواهي 1
براي اعلام عدم اعتبار گواهي بايستي به صادر كننده اعتمادكرد ونه به اعلام كننده. گواهي‌هاي جديد نيز بايد به تأييد يك مركز مورد اعتماد برسد.
براي ارضاء اعلام عدم اعتبار گواهي از CRL استفاده مي‌شود. Certificate Revocation List

55. عدم اعتبار گواهي 2
تغيير شغل و پس از آن تغيير كليد عمومي :: ضرورت اطمينان از اطلاع همه دنيا از اين تغيير.
يك راه اين است كه هركس هرگاه كليد عمومي خواست از مركز مورد اعتماد در خواست كند.
راه ديگر اينكه با گم شدن، تغيير و يا لو رفتن كليد خصوصي ليستي از گواهي‌هاي منقضي نشده بي‌اعتبار به همگان منتشر شود.

56. عدم اعتبار گواهي 3 ممكن است قبل از انقضا، ابطال صورت گيرد:
كليد خصوصي لو رفته باشد.
كاربر توسط اين CA تاييد نمي‏شود.
تاريخ انقضاء، ليست گواهي‌هاي نامعتبر، به همراه امضاء صادر كننده در CRL وجود دارد.

57. عدم اعتبار گواهي 3

58. هدف از گواهي؟
هركاربر يك ميزان اعتبار دارد و آن ميزان اعتبار متناسب با سطحي از حساسيت كارها است.
كارت اعتباري هم به افراد مختلف اعتبارهاي متفاوت مي‌دهد (كارت نقره‌اي، طلايي، پلاتيني، و تيتانيومي)
:Certificate Policy امضاء نامه، امضاء قرارداد،…..

59. هدف از گواهي؟

60. وظايف PKI هدف فراهم ‏آوردن اعتماد به تراكنشهاي الكترونيكي.

61. CA
CA به عنوان آژانس اعتماد در يك PKI است و لذا طرف سوم امن ناميده مي‏شود.

62. نسخه‏برداري و بازيابي كليد
كليد ممكن است گم شود! داده‏ها غير قابل دسترس مي‏شوند. بايد مركزي براي بازيابي كليد وجود داشته باشد.
دو دليل براي نسخه‏برداري كليد
فراموشي كلمة رمز: نابودي داده‏هاي حساس. حتي رمز نكردن به خاطر ترس از گم‏شدن كلمة رمز وجود دارد.
گم شدن، دزديده شدن، و يا خرابي رسانه‏اي كه كليدها روي آن ذخيره شده است.

63. نسخه‏برداري و بازيابي كليد - 2
عدم انكار دليلي بر عدم نسخه‏برداري كليد
انكار يعني اعلام عدم دخالت در يك تراكنش. در فرم كاغذي امضاء‌ اين كار را كنترل مي‏كند.
در فرم الكترونيكي: امضاء رقمي.
عدم انكار مستلزم توليد و ذخيرة امن كليد امضاء در محدوده تحت كنترل كاربر (در همة‌حالات) است و لذا نبايد از آن Backup گرفت.
از نظر فني هم ضرورت ندارد چرا كه يك زوج كليد ديگر توليد و استفاده مي‏شود.
==> دو زوج كليد براي هر كاربر لازم است!

64. مديريت سابقة كليدها نبايد كليدها ابدي باشند. پس بايد:
كليدها را بروز آورد.
سابقه زوج كليدهاي قبلي را نگهداشت تا داده‏هاي رمز شده با زوج قبلي قابل رمزبرداري باشند. اين كار توسط نرم‏افزار طرف كارفرما انجام مي‏شود.
بروزآوري كليد بايد شفاف (Transparent) باشد،‌قبل از انقضاء ‌بروز آيد.
نقطه مقابل: وقتي كليدهاي امضاء بروز مي‏آيند بايد كاملا نابود شوند!

65. مؤلفه‌‌‌‌‌‌هاي PKI
تا حال صادر كننده را مسئول توليد، مديريت، و توزيع گواهي و CRL تلقي كرده‌ايم.
PKI از تعدادي مؤلفه تشكيل شده است كه هركدام بخشي از وظايف را به خوبي انجام مي‌دهند...

66. مؤلفه‌‌‌‌‌‌هاي PKI چهار مؤلفه اصلي: Certificate Authority : CA
Registration Authority: RA کنترل محتواي گواهي و اطمينان از تعلق به دارنده آن.
انباره(Repository): توزيع گواهي‌ها و CRLها (حداكثر كارآيي و دسترس پذيري را لازم دارد.)
آرشيو (Archive): انباره طولاني و امن براي آرشيو اطلاعات.

67. مؤلفه‌‌‌‌‌‌هاي PKI استفاده كنندگان:
.همچنين كاربران شامل : "مشترك" و يا "Certificate Holder”
كاربر گواهي يا طرف اعتماد.

68. CA مجموعه‌اي از سخت افزار، نرم افزار، و اپراتورها.
با دو صفت شناخته مي‌شود: نام و كليد عمومي.
وظايف...

69. وظايف CA صدور گواهي (توليد و امضاء) به كاربران و يا ديگر CAها.
نگهداري وضعيت گواهي‌ها و صدور CRL.
انتشار گواهي‌ها و CRL موجود
نگهداري آرشيو اطلاعات وضعيتي از گواهي‌هاي صادره منقضي يا ابطال شده، به منظور تعيين اعتبار گواهي‌ها پس از انقضاء.

70. صدور گواهي
تأييد اينكه فاعل (دارنده گواهي) كليد خصوصي متناظر با كليد عمومي موجود در گواهي را دارد.
اگر كليد خصوصي CA لو برود، همه گواهي‌‌هاي صاده‌اش در معرض شك است.
پس اولين وظيفه CA حفاظت از كليد خصوصي خودش است، حتي وقتي در حافظه اصلي درحال پردازش است.
وظيفه ديگر CA اطمينان از درستي گواهي و درستي ادعاي درخواست كننده گواهي است.

71. اجزاي تشكيل دهنده CA

72. RA دو روش براي تأييد هويت متقاضي
RA قبل از ارائه در خواست به CA اطلاعات لازم را جمع آوري و كنترل مي‌كند: مراجعه شخص، تأييد هويت.
اگر قبلاً زوج كليد توليد كرده باشد كه همان به CA ارسال مي‌شود.
در غير اين صورت يك هويت شناسي يكبار مصرف مي‌گيرد تا پس از توليد به CA ارائه دهد.

73. معماري PKI
مادام كه دارندگان گواهي از يك CA گواهي گرفته باشند مسئله ساده است.
وقتي كه دارندگان گواهي از CAهاي مختلف گواهي گرفته باشند چگونه اعتماد كنند؟
معماري سادهPKI
تنها يك CA در سازمان گلوگاه و Single point of failure هرگونه اشكال منجر به لطمه ديدن اعتماد و احتمالاً صدور مجدد گواهي‌ها.

74. X.509 محصول ITU-T و بخشي از توصيه‏هاي سري X.500
گواهي X.509 در S/MIME، IPSec، SSL/TLS،‌و SET استفاده شده است.
CA << A >> O به معناي گواهي صادره CA براي كاربر A است.
همه كاربران در محدودة يك CA: وجود اعتماد مشترك و امكان وريف كردن گواهي صادره.

75. ساختار گواهي رقمي
Version 1
Version 2
Version 3
Versions
All

76. ساختار گواهي رقمي -2 Certificate  Public Key Algorithm
Signature Algorithm
(object Identifier)
Public Key
(bit string)
Subject
(name)
Issuer
Not Before
Not After
Validity Period
(date and time) 
Signed
Optional
Attributes
Version
(Integer)

77. X1 <<X2>> X2 <<B>> O
Cross-Certificate
در محيط بزرگتر: چند CA يا درختي از CA.
هر CA به كاربران خود سرويس مي‏دهد و لي به ازاء هر CA ديگر هم يك گواهي نزد خود دارد.
با فرض A و B مربوط به در CA مختلف X1 و X2:
X1 <<X2>> X2 <<B>> O
X2 <<X1>> X1 <<A>> O
با توجه به شكل مي‏توان داشت:
X <<W>> W <<V>> V <<Y>>Y<<Z>>Z<<B>> O
Z <<Y>> Y <<V>> V <<W>>W<<X>>X<<A>> O

78. Enterprise PKI
دومعماري مختلف براي PKI بزرگ.
سلسله مراتبي
Mesh

79. گواهي براي كاربران سيستم

81. CRLs Hot List در مورد Credit Card ليست سوء استفاده کنندگان را دارد.
CRL همان Hot List است که در آن شماره سريال قرار مي گيرد.
کاربران گواهي، CRL را براي وجود شماره سريال گواهي در داخل آن کنترل مي کنند.
CRL به امضاء CA مي رسد تا هويت شناسي و صحت محتواي آن تأييد شود.
يک چارچوب مورد استفاده در حداکثر کاربردهاي CRL در اين جا مورد انتظار است.

82. ساختار CRL Version Signature tbsCertList Issuer signAlgorithm
ThisUpdate
NextUpdate
RevokedCerts
CRLExtensions
tbsCertList
signAlgorithm
signatureValue

83. توليد و استفاده از CRL
Full CRL در مواقعي که يک CA هر از چندگاه ليست کامل Revoke شده ها را مي دهد.
از next update time براي کنترل کهنه بودن CRL استفاده مي شود.
CRL Location: اگر محل توزيع CRL مشخص نباشد بايد در محلي باشد که CA مشخص کرده است.
اندازه CRL مسئله است چرا که همه Revoke شده ها را بايد پشتيباني کند.
Delta CRL اختلاف اخير ترين بروز رساني و CRL جديد.

84. رويه ها و خط مشي ها براي داشتن PKI دو دسته مستند لازم است
(CP) Certificate Policy
(CPS) Certificate Practices Statement
اين دو قالب مشترک دارند ولي شنونده متفاوت و هدف متفاوتي دارند.

85. رويه ها و خط مشي ها -2
CP يک مستند سطح بالا است که خط مشي اي امنيتي براي صدور گواهي و نگهداري اطلاعات گواهي را شرح مي دهد.
شرح عمليات CA، مسئوليت هاي کاربر براي درخواست، استفاده، و مديريت کليدها و گواهي ها را دارد.
عمر اين خط مشي از مرحله توليد تا انقضاء گواهي است.
CPS يک مستند خيلي جزئي است که نحوه اجرايي شدن CP را بيان مي کند.