m.mohammadzadeh/lte-security-profile
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

s2

Browse Source
This commit is contained in:
Ario
2026-06-10 13:19:29 +03:30
parent 41495cd72c
commit 54e48a8985
2107 changed files with 386246 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/40.md
+28
View File
@@ -0,0 +1,28 @@
2. ## کلاس پشتیبانی از رمزنگاری {#کلاس-پشتیبانی-از-رمزنگاری-1}
با توجه به اینکه پروتکل‌های پایه TLS و DTLS از احراز هویت دوطرفه پشتیبانی نمی‌کنند، پشتیبانی از این ویژگی به عنوان یک انتخاب اختیاری در نظر گرفته شده است که الزامات آن در این قسمت شرح داده شده است. در صورتی که هر یک از این پروتکل‌ها انتخاب شده باشد، برای پشتیبانی از احراز هویت دوطرفه این قسمت باید رعایت شود.
با توجه به کارکرد این پروتکل‌ها به صورت client/server، الزامات مربوطه نیز برای هر یک از کاربر (client) یا سرور (server) جداگانه بیان شده است که هر یک از دو طرف مودم و موجودیت دوم مانند سرور خارجی رکوردهای ممیزی می‌توانند نقش کاربر DTLS یا سرور DTLS را بگیرند (همین‌طور برای TLS).
| شماره الزام | نام الزام |
| ----: | ----: |
| 5 | احراز هویت دوطرفه DTLS client (1) (FCS_DTLSC_EXT.2.1) |
| مودم با نقش کاربر باید از احراز هویت دوطرفه سرور DTLS بر مبنای گواهینامه‌های X.509v3 پشتیبانی کند. |
| 6 | احراز هویت دوطرفه DTLS client (2) (FCS_DTLSC_EXT.2.2) |
| در صورتی که هر پیام دریافت شده از سمت سرور دارای مقدار MAC نادرست باشد، کاربر باید ]انتخاب: نشست را خاتمه دهد، به صورت خاموش پیام را نادیده بگیرد[. نکات کاربردی: منظور از خاموش یعنی کنار گذاشتن بسته بدون فیدبک دادن یا ارسال Ack. |
| 7 | احراز هویت دوطرفه DTLS client (3) (FCS_DTLSC_EXT.2.3) |
| مودم با نقش کاربر باید پیام‌های باز ارسال شده (مربوط به replay attack) برای: رکوردهای DTLS که قبلاً دریافت شده‌اند (یعنی شماره ترتیب آن تکراری است)، رکوردهای DTLS بسیار قدیمی که شماره ترتیب آن‌ها در sliding receive window قرار نمی‌گیرد، را به صورت خاموش نادیده بگیرد. نکات کاربردی: حمله replay attack در RFC 6347 برای DTLS 1.2 و RFC 4347 برای DTLS 1.0 شرح داده شده است. |
| 8 | احراز هویت دوطرفه DTLS server (1) (FCS_DTLSS_EXT.2.1) |
| مودم با نقش سرور باید از احراز هویت دوطرفه کاربران DTLS بر مبنای گواهینامه‌های X.509v3 پشتیبانی کند. |
| 9 | احراز هویت دوطرفه DTLS server (2) (FCS_DTLSS_EXT.2.2) |
| به هنگام برقراری کانال امن، سرور بدون تأیید گواهینامه کاربر نباید با آن تشکیل کانال دهد. در صورت نامعتبر بودن گواهینامه، مودم در ادامه همچنین باید ]انتخاب: هیچ کار دیگری نکند، درخواست مجوز برای تشکیل کانال بدهد[. |
| 10 | احراز هویت دوطرفه DTLS server (3) (FCS_DTLSS_EXT.2.3) |
| بدون تأیید اینکه (DN) distinguished name و (SAN) Subject Alternative Name موجود در گواهینامه با شناسه‌های مورد انتظار برای کاربر تطابق ندارند، سرور نباید با کاربر کانال امن تشکیل دهد. |
| 11 | احراز هویت دوطرفه TLS client (1) (FCS_TLSC_EXT.2.1) |
| مودم با نقش کاربر باید از احراز هویت دوطرفه سرور TLS بر مبنای گواهینامه‌های X.509v3 پشتیبانی کند. |
| 12 | احراز هویت دوطرفه TLS server (1) (FCS_TLSS_EXT.2.1) |
| مودم با نقش سرور باید از احراز هویت دوطرفه کاربران TLS بر مبنای گواهینامه‌های X.509v3 پشتیبانی کند. |
| 13 | احراز هویت دوطرفه TLS server (2) (FCS_TLSS_EXT.2.2) |
| به هنگام برقراری کانال امن، سرور بدون تأیید گواهینامه کاربر نباید با آن تشکیل کانال دهد. در صورت نامعتبر بودن گواهینامه، مودم در ادامه همچنین باید ]انتخاب: هیچ کار دیگری نکند، درخواست مجوز برای تشکیل کانال بدهد[. |
| 14 | احراز هویت دوطرفه TLS server (3) (FCS_TLSS_EXT.2.3) |
| بدون تأیید اینکه (DN) distinguished name و (SAN) Subject Alternative Name موجود در گواهینامه با شناسه‌های مورد انتظار برای کاربر تطابق ندارند، سرور نباید با کاربر کانال امن تشکیل دهد. |