m.mohammadzadeh/lte-security-profile
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
41495cd72c64f4498c99dd6217a557d8cc288984
lte-security-profile/security-requirements.md
T
Ario 41495cd72c Rename document to professional name
2026-06-06 11:26:01 +03:30

1.2 MiB
Raw Blame History

پروفایل حفاظتی مودم‌های نسل چهار (LTE)

پروژه تدوین سند پروفایل حفاظتی و روش آزمون امنیتی براي
مودم‌هاي 4G و 5G

پژوهشگاه ارتباطات و فناوری اطلاعات

شناسنامه مستند
عنوان پروژه تدوین سند پروفایل حفاظتی و روش آزمون امنیتی براي مودم‌هاي 4G و 5G
عنوان مستند پروفایل حفاظتی مودم‌های نسل چهار (LTE)
کد مستند 2
کارفرما مرکز تحقیق و توسعه همراه اول
پیمانکار مرکز تحقیقات مخابرات ایران
تاریخ تهیه 02/10/1401
تعداد صفحات
تاریخچه تغییرات
ردیف ویرایش هدف انتشار تهیه‌کننده بررسی تأیید
1- نهایی □ جهت بررسی و اعلام نظر 🗹 جهت تأیید □ جهت اطلاع □ ....

فهرست تغییرات

ملاحظات شماره نسخه صفحه
06 05 04 03 02 01 00
x 1
x 2
x 3
x 4
x 5
x 6
x 7
x 8
x 9
x 10
x 11
x 12
x 13
x 14
x 15
x 16
x 17
x 18
x 19
x 20
x 21
x 22
x 23
x 24
x 25
x 26
x 27
x 28
x 29
x 30
x 31
x 32
x 33
x 34
x 35
پیشگفتار

امروزه با رشد سریع علوم کامپیوتر و مخابرات شاهد عرضه‌ نسل‌های جدیدی از شبکه‌های سلولی هستیم که افزایش حجم و سرعت ارسال داده‌ها از مهم‌ترین وجوه تمایز این نسل‌ها نسبت به یکدیگر است. در همین راستا مودم‌های نسل چهار LTE با فراهم کردن مکانیزم‌ها و پروتکل‌های مورد نیاز برای اتصال به شبکه LTE، امکان استفاده از اینترنت پرسرعت LTE را برای کاربران فراهم می‌کنند. با این حال برای اطمینان از امنیت این فرایند و نیز پیروی از روندها و مکانیزم‌های استاندارد، نیاز است تا مودم‌های مربوطه طبق یک استاندارد دقیق و کامل ارزیابی شوند. سند پیش‌رو برای رسیدن به این هدف و با تکیه بر الگوهای معیار مشترک در نگارش پروفایل‌های حفاظتی تدوین شده است، به طوری که با الگو قرار دادن آخرین نسخه از پروفایل حفاظتی مرجع برای محصولات شبکه و نیز مجموعه استانداردهای امنیتی تدوین‌شده توسط سازمان‌های 3GPP و NIST برای معماری شبکه‌های LTE نگاشته شده است.

این سند در 9 فصل اصلی و به همراه 1 فصل پیوست فنی تدوین شده است. فصل اول به طور گذرا به بررسی مودم LTE و اتصالات آن در شبکه LTE می‌پردازد. قابل ذکر است که پیوست فنی به تفصیل به معرفی شبکه‌های LTE، جایگاه مودم در این شبکه و نیز مکانیزم ارتباطی آن‌ها با یکدیگر می‌پردازد. فصل دوم انطباق سند با سطوح معیار مشترک را ذکر می‌کند. فصل سوم به معرفی داراییها، فرضیات، سیاست‌های سازمانی و تهدیدات می‌پردازد. فصل چهارم با دو زیربخش، نخست به تشریح تهدیدات امنیتی موجود می‌پردازد، به طوری که به صورت خلاصه و تیتروار به کارکردهای امنیتی در نظر گرفته شده برای رفع هر تهدید نیز اشاره می‌کند. همچنین در زیربخش دوم از آن نگاشت میان اهداف و فرضیات، سیاست‌های سازمانی و تهدیدات ذکر شده است. اما بخش اصلی از این سند فصل 5ام آن است که به تفصیل به بیان الزامات کارکردی امنیتی مورد نظر برای رفع تهدیدها می‌پردازد. بدین منظور، الزامات مربوطه به صورت دستهبندی شده و در قالب کلاس‌های مختلف ذکر شده‌اند. در ادامه این فصل نیز رویه‌ها و الزامات در نظر گرفته شده برای ارزیابی محصول توسط ارزیاب و نحوه تعیین پایبندی آن به الزامات کارکردی امنیتی ذکر شده است. فصل‌های 6 و 7 نیز به الزامات کارکردی-امنیتی اختیاری و انتخابی اختصاص دارد که در فصل 5 به آن‌ها اشاره خواهد شد. فصلهای 8 و 9 نیز به بیان الزامات کارکردی-امنیتی مربوط به بخشهای Wi-Fi و مسیریاب در مودم میپردازد. در پایان، لیست مراجع مورد استفاده در نگارش این سند ارائه شده است.

فهرست مطالب

عنوان صفحه

فهرست جدول‌ها ‌ه

فهرست شكل‌‌ها ‌و

فصل 1- معرفی مودم LTE (TOE) 1

1-1- اجزای یک مودم LTE 1

1-2- لینک هوایی میان مودم و مؤلفه‌ eNodeB 2

1-3- انواع اتصالات میان مودم و مؤلفه‌‌های شبکه 3

1-4- کارکرد محصول 4

فصل 2- انطباق با سطوح معیار مشترک CC (ASE_CCL) 6

فصل 3- تعریف مسأله امنیت (ASE_SPD) 8

3-1- دارایی‌ها 8

3-2- تهدیدات 8

3-3- سیاست‌های امنیتی سازمانی 11

3-4- فرضیات 12

فصل 4- اهداف امنیتی (ASE_OBJ) 14

4-1- اهداف امنیتی برای مودم 14

4-2- اهداف امنیتی برای محیط عملیاتی 18

4-3- منطق اهداف امنیتی 19

4-3-1- نگاشت اهداف امنیتی به مسأله امنیت 19

4-3-2- استدلال نگاشت‌ها به اهداف امنیتی 21

4-3-2-1- نگاشت تهدیدات 21

4-3-2-2- نگاشت سیاست‌های امنیتی سازمان 22

4-3-2-3- نگاشت فرضیات 22

فصل 5- الزامات امنیتی (ASE_REQ) 24

5-1- کارکردهای امنیتی مورد نیاز (ASE_REQ_SFR) 24

5-1-1- کلاس ثبت رکوردهای ممیزی از رویدادهای امنیتی 29

5-1-2- کلاس پشتیبانی از رمزنگاری 36

5-1-3- کلاس شناسایی و احراز هویت 44

5-1-4- کلاس مدیریت امنیت 50

5-1-5- کلاس محافظت از محصول 54

5-1-5-1- محافظت از داده‌های امنیتی 54

5-1-5-2- خودآزمایی خودکار عملکرهای امنیتی 55

5-1-5-3- به‌روزرسانی امن محصول 55

5-1-5-4- مهرهای زمانی قابل اعتماد 56

5-1-6- کلاس دسترسی به محصول 57

5-1-7- کلاس کانال‌ها/مسیرهای مورد اعتماد 58

5-2- الزامات تضمین امنیت (ASE_REQ_SAR) 60

5-2-1- کلاس هدف امنیتی 61

5-2-2- کلاس توسعه 64

5-2-3- کلاس اسناد راهنما 65

5-2-4- کلاس پشتیبانی از چرخه حیات 67

5-2-5- کلاس آزمون 68

5-2-6- کلاس ارزیابی آسیب پذیری 69

فصل 6- پیوست یک: الزامات اختیاری 71

6-1- کلاس ثبت رکوردهای ممیزی از الزامات اختیاری 71

6-2- کلاس پشتیبانی از رمزنگاری 73

6-3- کلاس مدیریت امنیت 75

فصل 7- پیوست دو: الزامات انتخابی 76

7-1- کلاس ثبت رکوردهای ممیزی از الزامات اختیاری 76

7-2- کلاس پشتیبانی از رمزنگاری 78

7-2-1- الزامات پروتکل DTLS 78

7-2-2- الزامات پروتکل HTTPS 82

7-2-3- الزامات پروتکل IPSEC 83

7-2-4- الزامات پروتکل SSH 89

7-2-5- الزامات پروتکل TLS 95

7-3- کلاس شناسایی و احراز هویت 98

7-4- کلاس محافظت از محصول 100

7-4-1- خودآزمایی خودکار عملکرهای امنیتی 100

7-4-2- به‌روزرسانی امن محصول 101

7-5- کلاس مدیریت امنیت 101

فصل 8- پیوست سه: الزامات امنیتی مربوط به Wi-Fi 103

8-1- مقدمه‌ای بر Wi-Fi 103

8-2- مسأله امنیت برای Wi-Fi 105

8-3- الزامات Wi-Fi 105

فصل 9- پیوست چهار: الزامات مربوط به مسیریاب 119

فصل 10- پیوست فنی 136

10-1- مروری بر معماری شبکه‌های LTE و جایگاه مودم‌های LTE در این ساختار 136

10-1-1- اجزای یک شبکه LTE 137

10-1-1-1- مودم LTE 138

10-1-1-2- شبکه E-UTRAN 140

10-1-1-3- شبکه هسته (Evolved Packet Core) EPC 141

10-2- اینترفیس هوایی بین مودم و eNodeB 143

10-2-1- پشته پروتکل لینک هوایی میان مودم و eNodeB 143

10-2-2- انواع اتصالات روی لینک هوایی 146

10-3- فرایند اتصال مودم به شبکه 147

10-4- کلیدهای رمزنگاری روی لینک هوایی 149

10-5- مکانیزم AKA برای احراز هویت دوطرفه 152

واژه‌نامه 155

علائم اختصاری 157

فصل 11- مراجع 160

فهرست جدول‌ها

عنوان صفحه

جدول ‏4-1 نگاشت تهدیدات/دارایی‌ها/سیاست‌های سازمان به اهداف امنیتی/محیط عملیات 19

جدول ‏5-1 نگاشت الزامات کارکردی امنیتی به اهداف 24

جدول ‏7-1 لیست رویدادهای قابل ممیزی به تفکیک کارکردهای امنیتی اختیاری 71

جدول ‏8-1 لیست رویدادهای قابل ممیزی به تفکیک کارکردهای امنیتی انتخابی 76

جدول ‏8-2 لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS 78

جدول ‏9-1 واژه نامه انگلیسی به فارسی 155

فهرست شكل‌‌ها

عنوان صفحه

شکل ‏1-1 اتصال مودم به یک روتر WiFi 5

شکل ‏2-1 سطح تضمین ارزیابی بر اساس کلاس‌های تضمین 7

شکل ‏3-1 ایستگاه پایه قلابی 9

شکل ‏9-1 اجزای اصلی یک شبکه LTE 138

شکل ‏9-2 اتصال مودم به یک روتر WiFi 140

شکل ‏9-3 اتصالات ایستگاه‌های eNodeB در یک شبکه E-UTRAN 141

شکل ‏9-4 مؤلفه‌‌های اصلی EPC 142

شکل ‏9-5 پشته پروتکل لینک هوایی میان مودم و eNodeB 144

شکل ‏9-6 پشته پروتکل برای صفحه کاربر 145

شکل ‏9-7 پشته پروتکل برای صفحه کنترل (شامل زیرلایه‌های AS و NAS و پروتکل‌های آن‌ها) 145

شکل ‏9-8 اتصالات صفحه کاربر 147

شکل ‏9-9 پیام‌های ارسالی در فرایند اتصال مودم به شبکه 148

شکل ‏9-10 کلیدهای رمزنگاری در لایه‌های مختلف از پشته پروتکل لینک هوایی 149

شکل ‏9-11 طول انواع کلیدها در پشته پروتکل لینک هوایی 150

شکل ‏9-12 تأمین محرمانگی و صحت داده برای اتصالات مدیریتی و داده 150

شکل ‏9-13 توافق روی الگوریتم‌های رمزنگاری و صحت داده و انشعاب کلیدهای رمزنگاری 151

شکل ‏9-14 فرایند احراز هویت دوطرفه میان مودم و مؤلفه‌ MME 153

  1. معرفی مودم LTE (TOE) {#معرفی-مودم-lte-(toe)}

مودم مورد بررسی در این پروفایل حفاظتی یک مودم LTE است. به عنوان یک عضو از شبکه نسل چهار LTE، وظیفه اصلی یک مودم LTE برقراری اتصال به اینترنت و شبکه IP از طریق ارتباط با نودهای eNodeB و اتصال به شبکه هسته‌ EPC است. از این رو، فرایند اتصال به شبکه LTE و کسب اطمینان از امن بودن این اتصال و عدم شنود یا ربوده نشدن آن مهم‌ترین مسأله از بعد امنیتی بوده و هدف اصلی این پروفایل حفاظتی تعیین مجموعه‌ای از الزامات کارکردی امنیتی1 است که با تأمین آن‌ها نگرانی‌های امنیتی مربوطه نیز برطرف خواهند شد. قابل ذکر است که این بخش به طور خلاصه به معرفی مودم می‌پردازد، اما با توجه به پیچیدگی‌ اتصالات یک مودم در شبکه LTE، یک پیوست فنی در سند در نظر گرفته شده است که با جزئیات دقیق، معماری یک شبکه LTE، جایگاه یک مودم LTE در این شبکه و نیز چگونگی اتصال مودم به شبکه را شرح می‌دهد و برای کسب اطلاعات بیشتر، خواننده محترم می‌تواند به آن پیوست مراجعه نماید.

  1. اجزای یک مودم LTE

به طور کلی یک مودم LTE از اجزای نرم‌افزاری و سخت‌افزاری اصلی زیر تشکیل می‌شود:

  1. زیر سیستم تلفنی2 برای مدیریت اتصال با ایستگاه‌های پایه (eNodeB) جهت برقراری ارتباط با شبکه LTE: این زیر سیستم تلفنی خود شامل اجزای زیر است.

    1. یک پردازنده اختصاصی تحت عنوان پردازنده باند پایه که سیستم‌عامل مخصوص به خود را دارا بوده و پردازش سیگنال دریافتی یا ارسالی بر عهده آن خواهد بود.
    2. یک عدد سیم‌کارت LTE که تحت عنوان UICC3 نیز شناخته می‌شود. این سیم‌کارت‌ها هوشمند بوده و یک برنامه مبتنی بر زبان جاوا تحت عنوان اختصاری 4 USIM را اجرا می‌کنند که اینترفیس نرم‌افزاری لازم برای اتصال به eNodeB را فراهم می‌کند.

    قابل ذکر است که سیم‌کارت‌ شامل اطلاعات شخصی کاربر و همچنین دو مؤلفه‌ مهم دیگر شامل کلید رمزنگاری K و شناسه هویتی IMSI5 است که هویت یک کاربر (اینجا مودم) را به صورت یک موجودیت یکتا به شبکه سلولی معرفی می‌کند.

    در حالت پیشرفته ممکن است اپراتور شبکه از یک شناسه هویتی موقتی بنام 6 GUTI استفاده کند تا از ارسال IMSI در شبکه و خطرات امنیتی ناشی از آن جلوگیری شود. (علاوه بر مواد ذکر شده شناسه هویتی دیگری به نام 7 IMEI وجود دارد که هویت مودم و نه سیم‌کارت را به صورت یکتا مشخص کرده و معمولاً در حافظه مودم ذخیره می‌شود و نه در سیم‌کارت).

  2. یک سیستم‌عامل عمومی (مانند لینوکس) که برای مدیریت مودم و اتصالات آن به دیگر تجهیزات موجود در شبکه کاربر روی آن نصب شده است.

    1. لینک هوایی میان مودم و مؤلفه‌ eNodeB

تمامی ارتباطات میان مودم و شبکه LTE از طریق اتصال آن به eNodeB انجام می‌شود. به عبارت دیگر، برای اتصال به شبکه، مودم باید نخست به یک eNodeB متصل شود. در طول این سند، برای اشاره به کانال ارتباطی میان مودم و یک ایستگاه رادیویی eNodeB از عبارت لینک هوایی یا اینترفیس هوایی استفاده خواهیم کرد (با توجه به اهمیت این اینترفیس توصیه می‌شود تا برای شناخت بیشتر از پشته پروتکل آن به پیوست فنی مراجعه کنید).

  1. انواع اتصالات میان مودم و مؤلفه‌‌های شبکه

    یک مودم LTE با مؤلفه‌‌های مختلفی در شبکه در تعامل بوده و اتصال برقرار می‌کند. این اتصالات را به دو گروه اتصالات مبتنی بر لینک هوایی8 و اتصالات غیر مبتنی بر لینک هوایی9 تقسیم‌بندی می‌کنیم. همچنین هر یک از این اتصالات را می‌توان به دو گروه اتصالات مدیریتی و اتصالات داده تقسیم کرد.

مقصود از اتصالات مدیریتی مبتنی بر لینک هوایی اتصالاتی است که در طول فرایند وصل شدن مودم به eNodeB و سپس ارتباط با مؤلفه‌ MME برای وصل شدن به شبکه LTE و IP برقرار می‌شود و منظور از اتصالات داده، کانال ارتباطی تشکیل‌شده میان مودم و مؤلفه‌ P-GW است که پس از اتصال مودم به شبکه IP برقرار شده و وظیفه آن تنها انتقال ترافیک مبادله‌شده میان مودم و شبکه IP بوده و هم مودم و هم eNodeB نقشی در تولید آن ندارند و در واقع ترافیک کاربران اینترنت است.

تعاملات غیر مبتنی بر لینک هوایی نیز شامل 1) اتصال مدیریتی مانند اتصال ادمین، از طریق یک ماشین خارجی به مودم برای پیکربندی آن و یا اتصال به یک نود خارجی برای ارسال رکوردهای ممیزی و 2) اتصال غیر مدیریتی مانند اتصال مودم به یک روتر یا فراهم‌کننده نقطه دسترسی که سرویس اینترنت را به کاربران ارائه خواهد داد، است.

همچنین ترافیک عبوری، ارسالی یا رسیده به مودم را نیز می‌توان به دو دسته ترافیک تصدیق‌شده10 و تصدیق‌نشده11 تقسیم کرد. منظور از ترافیک تصدیق‌شده ترافیکی است که توسط خود مودم و به جهت اتصال به سایر مؤلفه‌‌های شبکه مانند eNodeB تولید شده و یا توسط نود مقابل و برای اتصال و احراز هویت با مودم تولید شده است (ترافیک مربوط به اتصالات مدیریتی از این نوع است). منظور از ترافیک تصدیق‌نشده نیز ترافیکی است که مودم تنها نقش عبور دادن آن از شبکه را ایفا کرده و در تولید آن نقشی ندارد؛ مانند ترافیک داده کاربران که بعد از اتصال مودم به اینترنت تولید خواهد شد (ترافیک مربوط به اتصالات غیر مدیریتی از این نوع است).

  1. کارکرد محصول

همچنان که در شکل ‏1-1 نشان داده شده است، وظیفه اصلی تعریف‌شده برای یک مودم LTE برقراری ارتباط با شبکه LTE از طریق مدوله کردن سیگنال دیجیتال به صورت آنالوگ و ارسال آن به ایستگاه رادیویی همتا12 شده eNodeB روی باند رادیویی تعریف شده برای شبکه‌های LTE و دمدوله کردن آن در جهت معکوس است.

از سوی دیگر، ضمن فراهم کردن این اتصال، مودم می‌تواند به یک روتر نیز متصل باشد که این روتر دسترسی به اینترنت فراهم‌شده توسط مودم را برای تجهیزات و کاربران موجود در شبکه محلی مودم فراهم خواهد کرد. به عبارت دیگر نقطه دسترسی13 را برای کاربران اینترنت فراهم می‌کند. امروزه بسیاری از تجهیزات موجود در بازار که تحت عنوان مودم‌ LTE فروخته می‌شوند، هر سه نقش مودم، روتر و نقطه دسترسی را فراهم می‌کنند، ولی لزومی برای این کار نبوده و کارکرد اختصاصی تعریف‌شده برای مودم همان مواردی است که بیان شد. از این رو، تمرکز اصلی این سند عمدتاً در تعریف کارکردهای امنیتی مورد نیاز برای کانال اتصالی مودم به شبکه LTE بوده و در نظر گرفتن نقش‌های اضافه‌ای چون مسیریاب و فراهمکننده نقطه دسترسی خارج از هدف این پروفایل حفاظتی است. لذا الزامات مربوط به قابلیت فراهم‌کننده‌ نقطه دسترسی در فصل 8 و همچنین برخی الزامات اصلی مربوط به نقش مسیریاب بر طبق سند پروفایل حفاظتی "مسیریاب" در سایت مرکز راهبردی افتا و ارم در فصل 9 ارائه شده است. در صورتی که مودم دارای قابلیت نقطه دسترسی یا مسیریاب باشد، سازنده مودم ملزم به پیاده‌سازی الزامات مربوطه در این دو فصل است.

شکل ‏1-1 اتصال مودم به یک روتر WiFi

  1. انطباق با سطوح معیار مشترک 14 CC (ASE_CCL) {#انطباق-با-سطوح-معیار-مشترک-cc-(ase_ccl)}

ادعای انطباق این پروفایل حفاظتی با CC به این شرح است:

  • تطابق با CC نسخه 3.1 (بازنگری پنجم)
  • تطابق با الزامات کارکردی امنیت: تطبیق با CC Part 2
  • تطابق با الزامات تضمین امنیت: تطبیق با CC Part 3

انطباق محض15 با این پروفایل حفاظتی (PP) در صورت ادعای انطباق با آن در دیگر پروفایل‌های حفاظتی یا در هر سند هدف امنیتی (ST) الزامی است. به جهت یادآوری، میزان تطابق ST با هر PP به دو صورت ذیل می‌تواند باشد:

  • انطباق محض: ST شامل یا فراتر از PP است.
    • تعریف مسأله امنیت: ST باید کاملاً حاوی تعریف مسأله امنیت موجود در PP باشد. فرضیات ST می‌تواند کمتر باشد و افزودن فرض اضافی، به شرط عدم ایجاد تهدید جدید، ممکن است.
    • اهداف امنیتی: تمامی اهداف امنیتی PP باید برای ST نیز باشد و علاوه بر آن، ST می‌تواند اهداف بیشتری نیز داشته باشد.
    • الزامات امنیتی: ST حاوی تمامی الزامات کارکردی و تضمین امنیت PP است و علاوه بر آن، می‌تواند الزامات اضافی نیز داشته باشد.
  • انطباق قابل اثبات16 : ST می‌تواند با ارائه دلایل منطقی، برخی موارد PP را تقلیل دهد یا مقید سازد.

این PP هیچ ادعایی برای انطباق با PP دیگری ندارد. همچنین این PP در انطباق با سطح یک تضمین ارزیابی یا EAL1 است. سطوح تضمین ارزیابی در شکل ‏2-1 نشان داده شده است.

شکل ‏2-1 سطح تضمین ارزیابی بر اساس کلاس‌های تضمین

  1. تعریف مسأله امنیت (ASE_SPD) {#تعریف-مسأله-امنیت-(ase_spd)}

تعریف مسأله امنیت شامل بیان دارایی‌ها، تهدیدات، فرضیات و سیاست‌های امنیتی سازمان است.

  1. دارایی‌ها

  2. FIRMWARE: سفت‌افزار مودم که کارکرد آن را کنترل و مدیریت می‌کند.

  3. USER_DATA: اطلاعات کنترلی و ترافیکی مربوط به کاربر یکی از مهم‌ترین‌ دارایی‌ها هنگام استفاده از مودم هستند که از طریق مودم به مقصد حرکت می‌کنند.

  4. MODEM_DATA: اطلاعات پیکربندی، کنترلی و ترافیکی مربوط به مودم که به کمک آن‌ها مودم به ایستگاه پایه و دیگر تجهیزات شبکه وصل می‌شود.

  5. SECURITY_DATA: کلیدهای رمزنگاری، گواهی‌های امنیتی، اطلاعات احراز هویت، شناسه‌ها و غیره که در مودم نگه‌داری یا از آن عبور می‌کند.

    1. تهدیدات

به عنوان یک عضو از شبکه نسل چهار LTE، وظیفه اصلی یک مودم LTE برقراری اتصال به اینترنت و شبکه IP از طریق ارتباط با نودهای eNodeB و اتصال به شبکه EPC است. از این رو، فرایند اتصال به شبکه LTE با تهدیدات مختلفی همراه بوده و کسب اطمینان از امن بودن این اتصال و عدم شنود یا ربوده نشدن آن مهم‌ترین مسأله از بعد امنیتی است. اما جدا از این نقش، به عنوان یک مؤلفه‌ از شبکه، مودم مربوطه ممکن است به مؤلفه‌‌های دیگری از شبکه مانند یک سرور خارجی جهت ذخیره رکوردهای ممیزی یا به‌روزرسانی نرم‌افزار متصل باشد، و یا جهت پیکربندی مودم، سرپرست آن از اتصال راه دور استفاده کند. لذا گستره تهدیدات روی مودم می‌تواند لیست طولانی‌تری را شامل شود. همچنین ذخیره‌سازی داده‌های امنیتی مانند پسورد مدیر یا کلیدهای رمزنگاری روی مودم نیز بستر تهدیدات امنیتی بیشتری را فراهم می‌کند. تلاش در شناسایی کارکردهای امنیتی دارای مشکل نیز همواره از روش‌های مطلوب برای تهدید مودم است. از سویی دیگر عامل تهدیدکننده همواره سعی خواهد کرد تا هیچ اثری از خود باقی نگذارد. از این رو، کلیه فعالیت‌ها در سیستم باید به صورت رکوردهای ممیزی ثبت و ضبط شود. بر مبنای توضیحات ارائه‌شده، تهدیدات شناساییشده برای یک مودم LTE از قرار زیر است:

  1. T.UNAUTHORIZED_DEVICE_OAM_ACCESS: منظور از این تهدید، تلاش یک هکر یا عامل بیگانه برای نفوذ به مودم ضمن کسب دسترسی در سطح مدیر است. عامل مربوطه به روش‌های مختلفی می‌تواند این حمله را انجام دهد؛ از جمله اینکه خود را به عنوان مدیر به مودم معرفی کند و وارد آن شود، یا به طور معکوس در حالت پیکربندی مودم از راه دور، در میانه کانال ارتباطی میان مودم و مدیر قرار گرفته و خود را به عنوان مودم به مدیر معرفی کند و از طریق ذخیره پیام‌های احراز هویتی که از جانب مدیر به مودم ارسال می‌شود و بازارسال آن‌ها در همان زمان یا وقت دیگری دسترسی در سطح مدیریت به مودم پیدا کند. با برخورداری از چنین سطح از دسترسی، ضمن سرقت اطلاعات، هکر می‌تواند با نصب بدافزار روی سیستم‌عامل مودم و یا حتی سیستم‌عامل پردازنده باند پایه مانع از اتصال آن به شبکه LTE شده و یا یک حمله منع سرویس روی نودهای eNodeB و MME17 آغاز کند. ارسال متعدد درخواست‌های اتصال به شبکه از جمله راه‌های انجام حمله منع سرویس عادی (DOS) یا توزیع شده (DDOS) است.

  2. T.CONNECTION_EAVESDROP_AND_MANIPULATION: در این تهدید مهاجم با قرار گرفتن در مسیر انتقال اطلاعات میان مودم و eNodeB و یا با مؤلفه‌‌های دیگر مانند سرور Syslog به استراق سمع و جاسوسی و یا حتی تغییر اطلاعات می‌پردازد.

    در خصوص اتصال میان مودم و eNodeB لازم است تا به ایستگاه پایه تقلبی یا Rogue Base Station اشاره کنیم که بخش عمده‌ای از تهدیدات روی لینک هوایی از جانب آن خواهد بود.

شکل ‏3-1 ایستگاه پایه قلابی

همچنان که در شکل ‏3-1 نشان داده شده، ایستگاه پایه تقلبی با قرارگیری در میان مودم و eNodeB انواع مختلفی از حملات مانند مرد-در-میانه18 و ضبط و بازارسال پیام‌ها با هدف شنود و تغییر ترافیک را می‌تواند انجام دهد.

  1. T.CONNECTION_REJECTION_ATTACK: این تهدید که از جانب ایستگاه پایه تقلبی ناشی می‌شود، مانع از اتصال مودم به شبکه LTE می‌شود. به طوری که با هر بار ارسال درخواست اتصال به شبکه از جانب مودم، ایستگاه پایه تقلبی پیام رد درخواست را ارسال خواهد کرد. علت وقوع این حادثه از آنجایی است که پیام ATTACH REJECT پیش از انجام احراز هویت دوطرفه می‌تواند ارسال شود و از این رو، مودم نمی‌تواند تشخیص دهد که این پیام از جانب یک ایستگاه پایه معتبر و یا تقلبی ارسال شده است. از سوی دیگر با دریافت این پیام معمولاً سیم‌کارت تلاش مجددی برای اتصال به شبکه انجام نمی‌دهد و گاهاً نیاز به ریستارت آن است.

  2. T.DOWNGRADE_ATTACK: یکی از تهدیدات مهم دیگر که یک ایستگاه پایه تقلبی می‌تواند بر مودم اعمال کند، اجبار کردن آن برای استفاده از تکنولوژی‌های قدیمی‌تر مانند GSM به جای LTE برای اتصال به شبکه است. از آنجایی که رمزنگاری مورد استفاده در GSM دارای ایرادات اساسی است، لذا در صورت وقوع این تهدید ترافیک ارسالی در لینک هوایی به راحتی قابل شنود خواهد بود.

  3. T.DEVICE_AND_IDENTITY_TRACKING: همچنان که در فصل پیوست فنی در فرایند اتصال مودم به شبکه LTE نشان داده شده است، ارسال شناسه IMSI اولین چیزی است که بدون رمز شدن در لینک هوایی به eNodeB ارسال می‌شود. لذا در صورتی که مودم به جای شناسه‌های موقتی، این شناسه دائمی را ارسال کند، یک ایستگاه پایه تقلبی به راحتی قادر به شناسایی محل استقرار مودم در یک ناحیه خواهد بود. در حالی که استفاده از شناسه‌های موقتی منجر به عدم موفقیت ایستگاه تقلبی در شناسایی هویت مودم در آن ناحیه شده و داشتن این شناسه موقتی کمک چندانی به هکر نخواهد کرد. از سوی دیگر پشتیبانی از PIN Code برای استفاده از سیم‌کارت امکان استفاده از سیم‌کارت مودم در صورت سرقت‌شدن آن را محدود می‌کند.

  4. T.DEVICE_FUNTIONALITY_FAILURE_ EXPLOIT: این تهدید اشاره به کارکرد نادرست کارکردهای امنیتی و شناسایی شدن و بهره‌برداری از آن‌ها توسط مهاجم یا هکر برای نفوذ به سیستم دارد.

  5. T.ATTACK_ON_STORED_CREDENTIALS: واضح است که برای ارتباط با شبکه، اطلاعات پیکربندی و امنیتی مختلفی در حافظه مودم و سیم‌کارت ذخیره خواهند شد که شامل اطلاعاتی چون نام کاربری و پسورد مدیران سیستم، کلیدهای رمزنگاری عمومی و خصوصی، گواهینامه‌های X.509 و کلید مستر K روی سیم‌کارت برای اتصال به شبکه LTE است.

    افشای این اطلاعات محرمانه نه تنها خود مودم بلکه تمام شبکه را می‌تواند درمعرض خطر شنود ترافیک و تغییر اطلاعات امنیتی و پیکربندی قرار دهد. این تهدید اشاره به سرقت اطلاعات مذکور دارد.

  6. T.MALICIOUS_UPDATE: این تهدید اشاره به آلودهشدن مودم به واسطه به‌روزرسانی‌های نامعتبر آن دارد.

  7. T.UNDETECTED_ACTIONS: این تهدید اشاره به برجای نگذاشتن رد از خود توسط هکر دارد که نتیجه آن می‌تواند عدم توانایی در شناخت آسیب‌های رسیده و عامل آن باشد.

    1. سیاست‌های امنیتی سازمانی

هر سازمان یا به طور کلی هر محصولی مجموعه‌ای از قوانین و مقررات و یا فرضیات خاص خود را برای محافظت از محصول یا سازمان خود دارد. درصورت وجود، این قوانین باید به هنگام دسترسی کنسول به مودم برای سرپرست یا کاربر مربوطه نمایش داده شده و در صورت موافقت با موارد ذکرشده اجازه دسترسی به مودم را پیدا کند.

  1. OSP.ACCESS_BANNER: به هنگام لاگین کنسول در مودم، محصول باید قادر به نمایش بنری باشد که مجموعه قوانین و رویه‌های مورد نظر سازمان (یا محصول) جهت دسترسی به مودم را نشان دهد. بدون اعلام موافقت با قوانین مربوطه نباید اجازه ورود داده شود.

    الزام کارکردی امنیتی درنظر گرفته شده:

  • الزام FTA_TAB.1 نمایش و پیکربندی این بنر دسترسی را تعریف می‌کند.

    1. فرضیات

  1. A.PHYSICAL_PROTECTION: فرض بر این است که مودم در محیط عملیاتی خود به صورت فیزیکی محافظتشده و در معرض حملات فیزیکی و خسارت‌های ناشی از آن‌ها قرار ندارد. فرض می‌شود که این محافظت برای تأمین امنیت دستگاه و داده‌های آن کافی است. در نتیجه، این پروفایل حفاظتی شامل هیچ الزامی در زمینه حفاظت فیزیکی و ابزارهای لازم برای کاستن از خسارت‌های ناشی از حملات فیزیکی نیست. این پروفایل از خود محصول انتظار ندارد که از دسترسی فیزیکی به دستگاه جلوگیری به عمل آورد. دسترسی فیزیکی به موجودیت‌های غیرمجاز امکان می‌دهد تا داده‌ها را استخراج کنند، سایر کنترل‌ها را دور بزنند یا به هر طریق دیگری دستگاه را دستکاری کنند.

  2. A.TRUSTED_ADMIN: مودم دارای دفترچه راهنما است و توسط فرد متخصص نصب و پیکربندی اولیه آن صورت می‌گیرد. علاوه بر این، اعتماد کامل به این فرد متخصص از نظر پیکربندی و تنظیم کلمات عبور وجود دارد.

  3. A.LIMITED_FUNCTIONALITY: فرض بر این است که مودم قرار است نقش یک مودم LTE را به عنوان کارکرد اصلی خود ارائه دهد و سرویس‌های همه منظوره و غیر مرتبط با نقش مودم را ارائه نمی‌دهد.

  4. A.NO_THRU_TRAFFIC_PROTECTION: محصول مودم هیچ ضمانتی در خصوص محرمانگی ترافیکی که از آن می‌گذرد ارائه نمی‌کند و تنها باید محرمانگی داده‌هایی را حفظ کند که از آن نشأت گرفته یا به آن ارسال شده‌اند. محرمانگی ترافیکی که صرفاً از مودم می‌گذرد (مانند ترافیک کاربران اینترنت) در این پروفایل حفاظتی پوشش داده نشده است.

  5. A.REGULAR_UPDATES: فرض بر این است که در صورت منتشر شدن به‌روزرسانی‌های جدید در پاسخ به آسیب‌پذیری‌های شناسایی شده، سرپرست محصول آن را به صورت منظم به‌روزرسانی می‌کند.

  6. A.ADMIN_CREDENTIALS_SECURE: فرض می‌شود که اطلاعات محرمانه سرپرست (مانند کلید خصوصی) که برای دسترسی (محلی یا راه دور) به مودم استفاده می‌شوند، توسط سیستمی که روی آن قرار دارند محافظت می‌گردند (منظور از سیستم، مودم نیست، بلکه فرضاً کامپیوتر شخصی سرپرست برای اتصال از راه دور به مودم است).

  7. A.RESIDUAL_INFORMATION: فرض می‌شود که برای اطلاعات حساس باقیمانده (مانند کلیدهای رمزنگاری، اجزای سازنده کلید، PINs، گذرواژه‌ها و غیره) روی مودم، زمانی که مودم از محیط عملیاتی حذف یا برداشته می‌شود، امکان دسترسی غیرمجاز وجود ندارد.

  8. A.UNINTENTIONAL_JEM: در محل عملیات مودم اختلالات غیرعمدی همچون تشعشعات الکترومغناطیسی و تداخل فرکانسی با سایر دستگاه‌ها وجود ندارد.

  9. A.COVERAGE: محیط عملیات دارای آنتن‌دهی مناسب 4G بوده و اندازه محیط نیز به نحوی است که مودم بتواند با قابلیت‌های خود (مثل بهره آنتن و غیره) پوشش لازم را برای کاربران خود فراهم نماید.

  10. اهداف امنیتی (ASE_OBJ) {#اهداف-امنیتی-(ase_obj)}

در این پروفایل حفاظتی، اهداف امنیتی ذیل به منظور ارزیابی امنیتی مودم در نظر گرفته شده است.

  1. اهداف امنیتی برای مودم

در این قسمت ضمن بیان اهداف امنیتی درنظر گرفته شده، نیازمندی‌های کارکردی امنیتی19 مربوطه برای رفع تهدیدات و رسیدن به این اهداف نیز لیست شده است. شرح این کارکردهای امنیتی مورد نیاز در بخش بعدی بیان شده است.

  1. O. DEVICE_ ACCESS_CONTROL: مودم باید تعریف و پیاده‌سازی دقیقی از نقش‌ها و دسترسی‌های امنیتی ارائه کند و از مکانیزم‌های امن برای دسترسی و نیز مدیریت نشست‌های برقرار شده استفاده کند.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • نقش‌های امنیتی در سری الزام FMT_SMR.2 و قابلیت‌ها و دسترسی‌های مدیریتی-امنیتی مربوطه در الزامات FMT_SMF.1 و FMT_MTD.1/CoreData تعریف شده است. همچنین امکانات و دسترسی‌های بیشتری نیز در الزامات انتخابی FMT_MOF.1/Services و FMT_MOF.1/Functions در نظر گرفته شده است.
  • الزام FIA_UIA_EXT.1 سرویس‌های قابل ارائه بدون نیاز به انجام احراز هویت به همراه الزام به احراز هویت پیش از انجام کارهای مدیریتی و FTA_TAB.1 نیز امکان نمایش یک بنر شامل پیام هشدار در زمان ورود به مودم را بررسی می‌کنند.
  • نیازمندی‌های مربوط به احراز هویت و لاگین سرپرست مودم در الزام FIA_UAU_EXT.2 لحاظ شده است.
  • الزامات FTA_SSL_EXT.1، FTA_SSL.3 و FTA_SSL.4 چگونگی مدیریت نشست‌های مدیریتی راه دور و محلی را بررسی ‌می‌کنند.
  • اطمینان از امن بودن نشست‌های مدیریتی راه دور در الزام FTP_TRP.1/Admin و با تأکید بر ایجاد یک کانال امن تضمین شده است.
  • به الزامات مرتبط با شناسایی رویدادهای مشکوک و محافظت از اطلاعات امنیتی مانند گذرواژهها نیز در ادامه این بخش به طور جداگانه اشاره شده است.
  1. O. CONNECTION_SECURITY: به طور کلی تأمین هر سه شاخصه محرمانگی، صحت داده و احراز هویت برای اتصالات مدیریتی ضروری خواهد بود، ولی برای اتصالات داده تنها تأمین مکانیزمی امن برای احراز هویت دوطرفه اجباری است و باقی موارد اختیاری خواهد بود. در مورد اتصالات داده و مدیریتی روی لینک هوایی، احراز هویت دوطرفه از طریق مکانیزمی تحت عنوان AKA در ابتدای اتصال به شبکه LTE تأمین می‌شود. مکانیزم AKA و نیز کلیدهای رمزنگاری روی لینک هوایی در پیوست فنی تشریح شده است.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  1. برای اتصالات غیر مبتنی بر لینک هوایی:
  • الزامات FTP_ITC.1 و FTP_TRP.1/Admin با پیشنهاد پروتکل‌های مناسب برای برقراری کانال راه دور امن میان مودم و سرپرست یا با دیگر مؤلفه‌‌های شبکه، اطمینان از انجام احراز هویت امن را نیز تضمین می‌دهند. همچنین بر اساس انتخاب انجام شده در خصوص پروتکل ایجاد کانال، الزامات مربوط به آن پروتکل نیز باید از پیوست این سند رعایت شود. علاوه بر این بخش پیوست شامل الزامات FIA_X509_EXT.1، FIA_X509_EXT.2 و FIA_X509_EXT.3 است که در صورت تمایل به استفاده از گواهینامه‌های کلید عمومی باید رعایت شوند.
  • الزامات FCS_CKM.1 و FCS_CKM.2 در خصوص تولید و استقرار کلید رمزنگاری درنظر گرفته شده است.
  • الزامات FCS_COP.1/DataEncryption، FCS_COP.1/SigGen، FCS_COP.1/Hash و FCS_COP.1/KeyedHash نیز برای انجام رمزنگاری، تولید امضا و تضمین صحت داده لحاظ شده است.
  • الزام FCS_RBG_EXT.1 برای تولید بیت تصادفی مورد استفاده در تولید کلید لحاظ شده است.
  1. برای اتصالات مبتنی بر لینک هوایی:
  • الزام FIA_UAU_EXT.3.1 اجبار به پیاده‌سازی پروتکل AKA در فرایند اتصال به شبکه LTE را اعمال می‌کند.
  • الزام FCS_CKM_EXT.1 به انشعاب یا استخراج کلیدهای رمزنگاری مورد استفاده روی لینک هوایی از کلید مستر K اختصاص دارد.
  • الزامات FCS_COP_EXT.1/DataEncryption و FCS_COP_EXT.2.1/Data نیز به انجام رمزنگاری و تأمین صحت داده روی این لینک اختصاص دارند.
  1. مدیریت کارکردهای امنیتی نیز در الزام FMT_SMF.1 اعمال می‌شود.
  1. O. CONNECTION_REJECTION_PREVENTION: برای رفع این مشکل باید مکانیزمی لحاظ شود تا در صورت دریافت پیام مربوطه، مودم به تلاش برای اتصال به دیگر ایستگاه‌های پایه ادامه دهد.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • الزام FIA_UAU_EXT.3.2 به مقابله با تهدید فوق اشاره دارد.
  1. O. DOWNGRADE_ATTACK_PREVENTION: باید از مجبور شدن مودم به استفاده از تکنولوژی آسیب‌پذیر (مثل GSM) جلوگیری شود.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • الزام FIA_UAU_EXT.3.3 به مقابله با تهدید فوق اشاره دارد.
  1. O. DEVICE _IDENTITY_TRACKING_PREVENTION: باید از شناسایی و دنبال شدن هویت دارنده مودم و نیز قابل استفاده بودن سیم‌کارت توسط سارقین جلوگیری شود.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • الزامات FIA_UAU_EXT.3.4 و FIA_UAU_EXT.3.5 به موارد فوق اشاره دارند.
  1. O. DEVICE_FUNTIONALITY_ASSURANCE: محصول باید از سلامت کارکردهای امنیتی خود اطمینان حاصل کند.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • الزام FPT_TST_EXT.1 پیاده‌سازی انجام تست خودکار را اعمال می‌کند.
  1. O. CREDENTIALS_SECURITY: محصول باید قادر به محافظت از اطلاعات امنیتی ذخیره شده روی آن مانند نام کاربری و پسورد سرپرستان سیستم، کلیدهای رمزنگاری عمومی و خصوصی، گواهینامه‌های X.509 و کلید مستر K روی سیم‌کارت برای اتصال به شبکه LTE بوده و سرپرستان را مجبور به تعیین گذرواژه‌های امن کند.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • الزام FPT_SKP_EXT.1 به محافظت از کلیدهای عمومی و خصوصی می‌پردازد.
  • پاک‌سازی یا نابودسازی کلیدها در الزام FCS_CKM.4 اعمال می‌شود.
  • الزام FMT_SMF.1 برای مدیریت کلیدها و الزام اختیاری FMT_MTD.1/CryptoKeys نیز به محدود کردن این دسترسی به سرپرستان مودم اختصاص دارد.
  • الزامات FIA_UAU.7، FIA_AFL.1، FPT_APW_EXT.1 و FIA_PMG_EXT.1 به موارد مختلفی از جمله طول و سختی گذر واژه مدیران، جلوگیری از نمایش گذرواژه در زمان وارد کردن و ذخیره امن آن‌ها روی محصول می‌پردازند.
  1. O. UPDATE_SECURITY: برای حفظ آمادگی مودم در جلوگیری از حملات جدید، نرم‌افزار و در صورت نیاز سفت‌افزار آن باید به صورت مرتب به‌روزرسانی شود. اما پیش از به‌روزرسانی می‌بایست اصالت محتوا و نیز مبدأ انجامدهنده آن تأیید هویت شوند. در غیر این صورت احتمال آلودهشدن مودم و نفوذ هکرها بالا خواهد بود.
    الزامات کارکردی امنیتی در نظر گرفته شده:
  • مجموعه الزام FPT_TUD_EXT.1 برای امنکردن فرایند به‌روزرسانی لحاظ شده است. همچنین به دنبال انتخاب انجام‌شده در این الزام برای سازوکار تصدیق فایل به‌روزرسانی، نیازمندی‌های بیشتری نیز باید پیاده‌سازی شود که در همان مجموعه الزام FPT_TUD_EXT.1 به آن‌ها اشاره شده است.
  • الزامات FMT_SMF.1 و FMT_MOF.1/ManualUpdate و همچنین مورد اختیاری FMT_MOF.1/AutoUpdate نیز برای مدیریت و تنظیم فرایند به‌روزرسانی در نظر گرفته شده‌اند.
  1. O. ACTION_MONITORING: تولید و ثبت رکورد‌های ممیزی از فعالیت‌های انجام گرفته در مودم، کمک شایانی به سرپرست در بررسی وضعیت آن، شناسایی خطاهای موجود، تولید گزارش و نیز در امور مربوط به حسابرسی سیستم می‌کند. لذا بسیار مهم است که در وهله اول تمامی فعالیت‌های دارای اهمیت رکورد شود و در وهله دوم این رکوردها از تغییر و دستکاری در امان باشند، بخصوص در حالتی که از یک سرور syslog خارجی برای ارسال رکوردهای مربوطه استفاده می‌شود.
    طبق این پروفایل حفاظتی و نیز با استناد به پروفایل حفاظتی عمومی ثبت‌شده برای تجهیزات شبکه، مودم باید قابلیت ارسال رکوردهای ممیزی به یک سرور syslog خارجی را از طریق یک کانال امن داشته باشد.
    الزامات کارکردی امنیتی در نظر گرفته شده:

  • الزامات FAU_GEN.1 و FAU_GEN.2 به ثبت رکوردهای ممیزی اختصاص دارد. همچنین الزام FPT_STM_EXT.1 به ثبت مهر زمانی روی رکوردهای ممیزی و نیز در صورت استفاده از سرور NTP برای تنظیم زمان، الزام FCS_NTP_EXT.1 نیز به امنکردن کانال ارتباطی با سرور مربوطه اختصاص دارد.

  • الزام FAU_STG_EXT.1 به مدیریت چگونگی ذخیره‌سازی رکوردهای ممیزی روی دیسک محلی و نیز ارسال آن‌ها به یک سرور syslog خارجی اشاره دارد.

  • الزام اختیاری FAU_STG.1 مربوط به محافظت از رکوردهای ممیزی ذخیرهشده روی مودم است و دیگر الزام اختیاری FAU_STG_EXT.2/LocSpace به ثبت آمار از تعداد رکوردهای از دست رفته یا رونویسی‌شده در مواقعی که حافظه مودم پر می‌شود، اشاره دارد.

  • در صورت قابل پیکربندی بودن پارامترهای مختلفی چون پروتکل ارتباطی با سرور syslog خارجی یا تعیین چگونگی رونویسی رکوردها در زمان پر شدن حافظه، الزام FMT_MOF.1/Functions انجام چنین پیکربندی‌هایی را به سرپرستان مجاز محدود می‌کند.

    1. اهداف امنیتی برای محیط عملیاتی

  1. OE.PHYSICAL_DEVICE_PROTECTION: امنیت فیزیکی مودم و داده‌هایی که در آن قرار دارند، توسط محیط باید تضمین شود.

  2. OE.TRUSTED_OAM: این هدف اشاره به این دارد که سرپرستان مودم باید قابل اعتماد باشند و تمام موارد ذکرشده در اسناد راهنما را به طور صحیح انجام ‌دهند و به طور عمدی محصول و اطلاعات موجود روی آن را در معرض تهدید قرار ندهند.

  3. OE.NO_GENERAL_PURPOSE: به جز کارکرد اصلی مودم که همان فراهمکردن اتصال با شبکه LTE از طریق یک مکانیزم امن است و نیز سرویس‌های مرتبط برای مدیریت و پشتیبانی مودم، سرویس جانبی دیگری ارائه نمی‌شود.

  4. OE.NO_THRU_TRAFFIC_PROTECTION: مودم محرمانگی ترافیکی که از آن عبور می‌کند را تأمین نمی‌کند. در صورت نیاز، محرمانگی این ترافیک توسط سایر ابزارهای امنیتی و تضمینی موجود در محیط عملیاتی مانند الگوریتم‌های رمزنگاری می‌بایست صورت پذیرد.

  5. REGULAR_UPDATE_CHECKING: نرم‌افزارها و میانافزارهای مودم باید به طور منظم توسط سرپرست مودم به‌روزرسانی ‌شوند.

  6. OE. CREDENTIALS_SECURITY_OTHER_PLATFORMS: اطلاعات حساب کاربری سرپرست مودم (مانند کلید خصوصی) مورد استفاده برای دسترسی به آن، در هر پلتفرمی که قرار دارند باید حفاظت‌شده باشند (مقصود در تجهیزات غیر از مودم است).

  7. OE.RESIDUAL_INFORMATION: سرپرست امنیتی باید اطمینان یابد که به اطلاعات باقیمانده حساس (مانند کلیدهای رمزنگاری، اجزای سازنده کلید، PINs، رمز عبورها و غیره) روی محصول، وقتی که مودم از محیط عملیاتی حذف یا برداشته می‌شود، امکان دسترسی غیرمجاز وجود ندارد.

  8. OE.NETWORK_ACCESS: مودم باید در مکانی نصب گردد که هم بتواند به خدمات شبکه 4G دسترسی داشته باشد و هم خدمات آن به کاربران هدف برسد و اختلالات و تشعشعات الکترومغناطیسی و تداخل فرکانسی وجود نداشته باشد.

    1. منطق اهداف امنیتی

در این بخش به وسیله یک جدول نگاشت اهداف امنیتی به تهدیدات، فرضیات و سیاست‌های سازمانی را نشان داده‌ایم. در ادامه توجیهات لازم برای این نگاشت‌‌ها نیز بیان شده است.

  1. نگاشت اهداف امنیتی به مسأله امنیت

در جدول ‏4-1، محور افقی اهداف امنیتی درنظر گرفته‌شده برای مودم و محیط عملیاتی آن را نشان داده و محور عمودی نیز تهدیدات، فرضیات و سیاست‌های سازمانی را نشان می‌دهد. هر خانه تیک خورده از جدول نشان می‌دهد که هدف امنیتی مربوطه به کدام تهدید(ات)، فرضیه(ها) و سیاست(های) سازمانی مرتبط می‌شود.

جدول ‏4-1 نگاشت تهدیدات/دارایی‌ها/سیاست‌های سازمان به اهداف امنیتی/محیط عملیات

OE.NETWORK_ACCESS OE.RESIDUAL_INFORMATION_SECURITY OE.CREDENTIALS_SECURITY_OTHER_PLATFORMS OE.REGULAR_UPDATE_CHECKING OE.NO_THRU_TRAFFIC_PROTECTION OE.NO_GENERAL_PURPOSE OE.TRUSTED_OAM OE.PHYSICAL_DEVICE_PROTECTION O. ACTION_MONITORING O. UPDATE_SECURITY O. CREDENTIALS_SECURITY O. DEVICE_FUNTIONALITY_ASSURANCE O. DEVICE _IDENTITY_TRACKING_PREVENTION O. DOWNGRADE_ATTACK_PREVENTION O. CONNECTION_REJECTION_PREVENTION O. CONNECTION_ SECURITY O. DEVICE_ ACCESS_CONTROL
✔ T.UNAUTHORIZED_DEVICE_OAM_ACCESS
✔ T.CONNECTION_EAVESDROP_AND_MANIPULATION
✔ T.CONNECTION_REJECTION_ATTACK
✔ T.DOWNGRADE_ATTACK
✔ T.DEVICE_AND_IDENTITY_TRACKING
✔ T.DEVICE_FUNTIONALITY_FAILURE_ EXPLOIT
✔ T.ATTACK_ON_STORED_CREDENTIALS
✔ T.MALICIOUS_UPDATE
✔ T.UNDETECTED_ACTIONS
✔ OSP.ACCESS_BANNER
✔ A.PHYSICAL_PROTECTION
✔ A.TRUSTED_ADMIN
✔ A.LIMITED_FUNCTIONALITY
✔ A.NO_THRU_TRAFFIC_PROTECTION
✔ A.REGULAR_UPDATES
✔ A.ADMIN_CREDENTIALS_SECURITY
✔ A.RESIDUAL_INFORMATION
✔ A.UNINTENTIONAL_JEM
✔ A.COVERAGE

  1. استدلال نگاشت‌ها به اهداف امنیتی

در این قسمت استدلال نگاشت اهداف به تهدیدات، سیاست‌های امنیتی سازمان و فرضیات به طور مختصر ارائه شده است.

  1. نگاشت تهدیدات

در این سند به ازای هر تهدید یک هدف برای مقابله با آن لحاظ شده است. به طور دقیقتر هر تهدید یا حذف کامل می‌شود یا به وسیله کاهش انگیزه مهاجم یا ایجاد محدودیت برای آن، به اندازه کافی تقلیل پیدا می‌کند. قابل ذکر است که رسیدن به اهدف امنیتی مربوطه نیز با رعایت الزامات کارکردی امنیتی محقق می‌شود که نگاشت آن در همان بخش اهداف برای هر هدف ذکر شد و توضیحات کامل این الزامات کارکردی امنیتی نیز در بخش بعد آورده شده است.

  1. T.UNAUTHORIZED_DEVICE_OAM_ACCESS: هدف DEVICE_ACCESS_ CONTROL از طریق مجموعه الزامات مربوطه، راه را برای دسترسی غیرمجاز به مودم می‌بندد.

  2. T.CONNECTION_EAVESDROP_AND_MANIPULATION: هدف مربوطه در جدول فوق به تأمین هر سه ویژگی امنیتی احراز هویت، صحت و محرمانگی اتصالات اختصاص دارد و از شنود و تغییر اتصالات جلوگیری می‌کند.

  3. T.CONNECTION_REJECTION_ATTACK: این تهدید از طریق هدف مربوطه و الزام کارکردی امنیتی FIA_UAU_EXT.3.2 به منظور تلاش برای اتصال به دیگر ایستگاه‌های باند پایه برطرف می‌شود.

  4. T.DOWNGRADE_ATTACK: این تهدید از طریق هدف اختصاصی DOWNGRADE_ATTACK_PREVENTION و الزام مربوطه (FIA_UAU_EXT.3.3) جهت امکان تعیین نوع شبکه قابل رفع است.

  5. T.DEVICE_AND_IDENTITY_TRACKING: هدف اختصاصی مربوطه در جدول فوق به محدود کردن امکان دنبالکردن هویت کاربر (صاحب سیم‌کارت) با استفاده از شناسه‌های موقتی و کد PIN می‌پردازد.

  6. T.DEVICE_FUNTIONALITY_FAILURE_ EXPLOIT: این تهدید با هدف نگاشت‌شده در جدول فوق از طریق انجام تست خودکار و اطمینان از کارکرد توابع امنیتی رفع می‌شود.

  7. T.ATTACK_ON_STORED_CREDENTIALS: هدف CREDENTIALS_SECURITY به ارائه سیاست‌ها و مکانیزم‌های امن برای ذخیره اطلاعات محرمانه روی مودم اختصاص دارد.

  8. T.MALICIOUS_UPDATE: هدف UPDATE_SECURITY به تأیید صحت به‌روزرسانی‌ها ارتباط دارد.

  9. T.UNDETECTED_ACTIONS: هدف ACTION_MONITORING به تهیه رکوردهای ممیزی از رخدادهای مهم روی مودم ارتباط دارد.

    1. نگاشت سیاست‌های امنیتی سازمان

  10. OSP.ACCESS_BANNER: هدف O. DEVICE_ ACCESS_CONTROL از طریق الزام کارکردی امنیتی FTA_TAB.1 امکان نمایش و پیکربندی این بنر دسترسی را برای نمایش سیاست‌های سازمانی فراهم می‌کند.

    1. نگاشت فرضیات

همچنان که واضح است اهداف امنیتی در نظر گرفته‌شده برای محیط عملیاتی توسط فرضیات بیان‌شده تأمین می‌شوند. همچنین قرار بر این است که فرضیات بیان‌شده توسط محیط عملیاتی تأمین شود و در نتیجه این سند هیچ الزام امنیتی برای تأمین اهداف امنیتی محیط عملیاتی بیان نمی‌کند.

  1. A.PHYSICAL_PROTECTION: این فرض تأمین‌کننده هدف امنیتی OE.PHYSICAL_DEVICE_PROTECTION خواهد بود و فرض بر این است که امنیت فیزیکی مودم توسط محیط تأمین خواهد شد.

  2. A.TRUSTED_ADMIN: این فرض تأمین‌کننده هدف امنیتی OE.TRUSTED_OAM است. به عبارت دیگر کلیه عملیات مدیریتی مودم توسط سرپرستان قابل اعتماد انجام می‌شود.

  3. A.LIMITED_FUNCTIONALITY: این فرض به هدف OE.NO_GENERAL_PURPOSE نگاشت شده و بیان می‌کند که قرار بر این است که مودم تنها نقش مودم را ایفا کرده و الزامی به ایفای نقش‌های بیشتر نیست.

  4. A.NO_THRU_TRAFFIC_PROTECTION: این فرض به هدف OE.NO_THRU_TRAFFIC_PROTECTION نگاشت شده و بیان می‌کند که مودم وظیفه محافظت محرمانگی از ترافیک عبوری از خود را ندارد (منظور از ترافیک عبوری، ترافیک لایه اپلیکیشن کاربر است).

  5. A.REGULAR_UPDATES: این فرض به هدف OE.REGULAR_UPDATE_CHECKING نگاشت شده و تضمین می‌دهد که محصول به طور مرتب به‌روزرسانی خواهد شد.

  6. A.ADMIN_CREDENTIALS_SECURE: این فرض با نگاشت به هدف مربوطه بیان می‌کند که فرض بر این است که اطلاعات ذخیره‌شده روی تجهیزات دیگر (مانند کلید خصوصی روی کامپیوتر یک سرپرست) امن بوده و وسیله‌ای برای حمله به مودم نخواهد شد. به عبارت دیگر مودم مسئول حفاظت از اطلاعات امنیتی روی خود است.

  7. A.RESIDUAL_INFORMATION: این فرض با نگاشت به هدف OE.RESIDUAL_INFORMATION_SECURITY بیان می‌کند که در صورت خاموش کردن و جدا کردن مودم از محیط عملیاتی توسط سرپرست، اطلاعات باقی مانده در آن مانند کلیدهای نامتقارن امن خواهند بود.

  8. A.UNINTENTIONAL_JEM: این فرض به هدف OE.NETWORK_ACCESS نگاشت شده و تضمین می‌دهد که در محیط عملیاتی اختلالات و تشعشعات الکترومغناطیسی و تداخلات فرکانسی وجود نداشته باشد.

  9. A.COVERAGE: این فرض نیز به هدف OE.NETWORK_ACCESS نگاشت شده و تضمین می‌دهد که مودم در مکانی نصب خواهد شد که هم بتواند به خدمات شبکه 4G دسترسی داشته باشد و هم خدمات آن به کاربران هدف برسد.

  10. الزامات امنیتی (ASE_REQ) {#الزامات-امنیتی-(ase_req)}

    1. کارکردهای امنیتی مورد نیاز (ASE_REQ_SFR) {#کارکردهای-امنیتی-مورد-نیاز-(ase_req_sfr)}

در این بخش کارکردهای امنیتی مورد نیاز و اشاره‌شده در بخش تهدیدات شرح داده خواهند شد. مطابق با سند مرجع Common Criteria یا CC که استاندارد و الگوی اصلی و پیروی‌شده در نگارش این پروفایل حفاظتی است، کارکردهای امنیتی مورد نیاز به صورت کلاس‌‌بندی شده شرح داده خواهند شد، به طوری که هر کلاس شامل کارکردهای مرتبط است.

شایان ذکر است که پیاده‌سازی تمامی الزامات کارکردی که در این بخش شرح داده می‌شوند برای یک مودم LTE مدعی به انطباق و التزام با این پروفایل حفاظتی اجباری است. همچنان که جلوتر خواهیم دید برای پیاده‌سازی برخی از نیازمندی‌ها، مانند الگوریتم رمزنگاری روی لینک هوایی، امکان انتخاب از میان گزینه‌های موجود فراهم شده است. این نوع نیازمندی‌ها را انتخابی می‌نامیم. همچنین برخی از نیازمندی‌ها اختیاری است که بالطبع پیاده‌سازی آن‌ها نیز اختیاری خواهد بود. هر یک از موارد اختیاری یا انتخابی به صورت ]اختیاری[ و ]انتخابی[ در طول سند مشخص شده است. علاوه بر این، ممکن است در داخل نیازمندی‌های ]انتخابی[ یکی از گزینه‌ها برای انتخاب با عنوان ]اختصاص[ مطرح شود که منظور از آن عموماً این است که نویسنده سند هدف امنیتی خود می‌تواند موارد جدیدی را با توجه به ویژگی‌های مودم خود به بخش مربوطه اضافه کند. پیاده‌سازی موارد اختیاری همان‌طور که از عنوان آن نیز مشخص است اختیاری است، اما برای برخی از موارد انتخابی الزاماتی نیز در بخش پیوست درنظر گرفتهشده که باید پیاده‌سازی شوند. به عنوان مثال، در صورت انتخاب پروتکل IPSec برای پیکربندی کانال امن باید الزامات پروتکل IPSec نیز از پیوست الزامات انتخابی پیاده‌سازی شود.

جدول ‏5-1 نگاشت میان الزامات کارکردی امنیتی و اهداف امنیتی ذکر شده برای مودم را نشان می‌دهد. این الزامات تحقق اهداف مربوطه را تضمین خواهند کرد.

جدول ‏5-1 نگاشت الزامات کارکردی امنیتی به اهداف

شماره الزام الزام هدف
1 تولید داده ممیزی 1.1 (FAU_GEN.1.1) O. ACTION_MONITORING
2 تولید داده ممیزی 2.1 (FAU_GEN.1.2) O. ACTION_MONITORING
3 تولید داده ممیزی 2 (FAU_GEN.2) O. ACTION_MONITORING
4 محل ذخیره‌سازی داده‌های ممیزی 1 (FAU_ STG_EXT.1.1) O. ACTION_MONITORING
5 محل ذخیره‌سازی داده‌های ممیزی 2 (FAU_ STG_EXT.1.2) O. ACTION_MONITORING
6 محل ذخیره‌سازی داده‌های ممیزی 3 (FAU_ STG_EXT.1.3) O. ACTION_MONITORING
7 مدیریت کلید رمزنگاری 1 (FCS_CKM.1) O. CONNECTION_ SECURITY
8 مدیریت کلید رمزنگاری 2 (FCS_CKM.2.1) O. CONNECTION_ SECURITY
9 نابودسازی کلید رمزنگاری (FCS_CKM.4.1) O. CREDENTIALS_SECURITY
10 انشعاب کلیدهای رمزنگاری برای اتصالات مبتنی بر لینک هوایی (FCS_CKM_EXT.1) O. CONNECTION_ SECURITY
11 عملیات رمزنگاری/رمزنگاری داده‌ها (FCS_COP.1/DataEncryption) O. CONNECTION_ SECURITY
12 عملیات رمزنگاری/ترافیک مدیریتی روی لینک هوایی 1 (FCS_COP_EXT.1.1/DataEncryption) O. CONNECTION_ SECURITY
13 عملیات رمزنگاری/ترافیک داده روی لینک هوایی 2 (FCS_COP_EXT.1.2/DataEncryption) O. CONNECTION_ SECURITY
14 عملیات رمزنگاری/تولید و تأیید امضا (FCS_COP.1/SigGen) O. CONNECTION_ SECURITY
15 عملیات رمزنگاری/الگوریتم درهمساز (FCS_COP.1/Hash) O. CONNECTION_ SECURITY
16 عملیات رمزنگاری/الگوریتم درهم‌ساز مبتنی بر کلید (FCS_COP.1/KeyedHash) O. CONNECTION_ SECURITY
17 عملیات رمزنگاری/سرویس صحت داده روی لینک هوایی (FCS_COP_EXT.2.1/Data Integrity on air interface) O. CONNECTION_ SECURITY
18 عملیات رمزنگاری/تولید بیت تصادفی 1 (FCS_RBG_EXT.1) O. CONNECTION_ SECURITY
19 عملیات رمزنگاری/تولید بیت تصادفی 2 (FCS_RBG_EXT.2) O. CONNECTION_ SECURITY
20 مدیریت احراز هویت ناموفق 1 (FIA_AFL.1.1) O. CREDENTIALS_SECURITY
21 مدیریت احراز هویت ناموفق 2 (FIA_AFL1..2) O. CREDENTIALS_SECURITY
22 مدیریت رمز ورود 1 (FIA_PMG_EXT.1) O. CREDENTIALS_SECURITY
23 شناسایی و احراز هویت کاربر 1 (FIA_UIA_EXT.1.1) O. DEVICE_ ACCESS_CONTROL
24 شناسایی و احراز هویت کاربر 2 (FIA_UIA_EXT.1.2) O. DEVICE_ ACCESS_CONTROL
25 سازوکار احراز هویت بر اساس رمز عبور 2(FIA_UAU_EXT.2.1) O. DEVICE_ ACCESS_CONTROL
26 سازوکار اتصال و احراز هویت روی لینک هوایی/احراز هویت (FIA_UAU_EXT.3.1) O. CONNECTION_ SECURITY
27 سازوکار اتصال و احراز هویت روی لینک هوایی/مقابله با تهدید منع سرویس (FIA_UAU_EXT.3.2) O. CONNECTION_REJECTION_PREVENTION
28 سازوکار اتصال و احراز هویت روی لینک هوایی/مقابله با تهدید تقلیل به تکنولوژی GSM (FIA_UAU_EXT.3.3) O. DOWNGRADE _ATTACK_PREVENTION
29 سازوکار اتصال و احراز هویت روی لینک هوایی/استفاده از شناسه موقتی (FIA_UAU_EXT.3.4) O. DEVICE _IDENTITY _TRACKING_PREVENTION
30 سازوکار اتصال و احراز هویت روی لینک هوایی/استفاده از شناسه هویتی Code PIN روی سیم‌کارت (FIA_UAU_EXT.3.5) O. DEVICE _IDENTITY _TRACKING_PREVENTION
31 بازخورد امن در مکانیزم احراز هویت (FIA_UAU.7) O. CREDENTIALS_SECURITY
32 مدیریت کارکرد امنیتی 1/ به‌روزرسانی دستی (FMT_MOF.1/ManualUpdate) O. UPDATE_SECURITY
33 مدیریت دسترسی به داده‌ها 1 (FMT_MTD.1/CoreData) O. DEVICE_ ACCESS_CONTROL
34 تعریف کارکردهای امنیتی 1 (FMT_SMF.1) O. DEVICE_ ACCESS_CONTROL O. CONNECTION_ SECURITY O. CREDENTIALS_SECURITY O. UPDATE_SECURITY
35 مدیریت نقش‌های امنیتی 1 (FMT_SMR.2.1) O. DEVICE_ ACCESS_CONTROL
36 مدیریت نقش‌های امنیتی 2 (FMT_SMR.2.2) O. DEVICE_ ACCESS_CONTROL
37 مدیریت نقش‌های امنیتی 3 (FMT_SMR.2.3) O. DEVICE_ ACCESS_CONTROL
38 محافظت از کلیدهای رمزنگاری 1 (FPT_SKP_EXT.1.1) O. CREDENTIALS_SECURITY
39 محافظت از گذرواژه سرپرست 1 (FPT_APW_EXT.1.1) O. CREDENTIALS_SECURITY
40 محافظت از گذرواژه سرپرست 2 (FPT_APW_EXT.1.2) O. CREDENTIALS_SECURITY
41 خودآزمایی خودکار 1 (FPT_TST_EXT.1) O. DEVICE_FUNTIONALITY_ ASSURANCE
42 به‌روزرسانی امن 1 (FPT_TUD_EXT.1.1) O. UPDATE_SECURITY
43 به‌روزرسانی امن 2 (FPT_TUD_EXT.1.2) O. UPDATE_SECURITY
44 به‌روزرسانی امن 3(FPT_TUD_EXT.1.3) O. UPDATE_SECURITY
45 مهر زمانی امن 1 (FPT_STM_EXT.1.1) O. ACTION_MONITORING
46 مهر زمانی امن 2 (FPT_STM_EXT.1.2) O. ACTION_MONITORING
47 قفلکردن و خاتمهدادن به نشست‌ها 1 (FTA_SSL_EXT.1.1) O. DEVICE_ ACCESS_CONTROL
48 قفل‌کردن و خاتمه‌دادن به نشست‌ها 2 (FTA_SSL.3.1) O. DEVICE_ ACCESS_CONTROL
49 قفل‌کردن و خاتمه‌دادن به نشست‌ها 3 (FTA_SSL.4.1) O. DEVICE_ ACCESS_CONTROL
50 بنر هشدار (FTA_TAB.1.1) O. DEVICE_ ACCESS_CONTROL
51 کانال امن/مودم با موجودیت دیگر 1 (FTP_ITC.1.1) O. CONNECTION_ SECURITY
52 کانال امن/مودم با موجودیت دیگر 2 (FTP_ITC.1.2) O. CONNECTION_ SECURITY
53 کانال امن/مودم با موجودیت دیگر 3 (FTP_ITC.1.3) O. CONNECTION_ SECURITY
54 کانال امن/مودم با سرپرست 1 (FTP_TRP.1.1/Admin) O. CONNECTION_ SECURITY
55 کانال امن/مودم با سرپرست 2 (FTP_TRP.1.2/Admin) O. CONNECTION_ SECURITY
56 کانال امن/مودم با سرپرست 3 (FTP_TRP.1.3/Admin) O. CONNECTION_ SECURITY

  1. کلاس ثبت رکوردهای ممیزی از رویدادهای امنیتی

این کلاس شامل مجموعه‌ای از کارکردهای مورد نیاز با هدف ثبت رکورد ممیزی برای هرگونه فعالیت امنیتی دارای اهمیت است که مودم در آن دخیل بوده است. هدف از این کار فراهمکردن اطلاعات لازم برای سرپرست مودم جهت شناسایی مشکلات عمدی و غیرعمدی رخ داده در زمینه پیکربندی و/یا در هر یک از کارکردهای سیستم است. مودم باید این قابلیت را داشته باشد که داده‌های ممیزی مورد نیاز برای تشخیص چنین فعالیت‌هایی را تولید کند.

ثبت این رکوردها از جهات مختلفی مفید و تأثیرگذار خواهد بود، به طور مثال ثبت رکورد ممیزی از فعالیت‌های مدیریتی منجر به تولید اطلاعاتی می‌شود که در صورت نیاز به تغییر پیکربندی مودم، می‌توان از تحلیل آن‌ها برای طراحی اقدامات اصلاحی و بازنگری در روش مدیریت آن استفاده کرد. همچنین ممیزی رویدادهای مرتبط با رمزنگاری نشان می‌دهد که آیا کارکردهای مربوطه به درستی اجرا می‌شوند یا سیستم در معرض شنود قرار دارد. از سویی دیگر این رکوردها به شناسایی فعالیت‌های غیرمعمول مانند ایجاد یک نشست کاربری در زمان مشکوک، شکست مکرر نشست‌ها یا احراز هویت ناموفق به سیستم کمک می‌کنند.

در برخی موارد، ممکن است حجم اطلاعات ممیزی تولیدشده به‌ اندازه‌ای زیاد شود که مدیر مودم را سردرگم‌ کند. از این رو مودم LTE باید بتواند اطلاعات ممیزی را به یک موجودیت مورد اعتماد خارجی ارسال کند. این اطلاعات باید دارای مهرهای زمانی قابل اعتماد باشند. این امر امکان مرتبکردن رکوردهای مربوطه بعد از ارسال به دستگاه‌ خارجی را فراهم می‌کند. همچنین ارتباط با این سرور ممیزی خارجی می‎بایست از طریق برقراری یک کانال امن صورت پذیرد و در صورت قطع اتصال، باید از ارسال داده‌های ممیزی روی مسیر عادی و رمز نشده جلوگیری شود.

از مودم انتظار نمی‌رود که این رکوردهای ممیزی را همواره در خود ذخیره داشته باشد. هرچند که لازم است داده‌ها به‌صورت محلی در زمان تولید ذخیره شوند ولی در صورت تجاوز از ظرفیت ذخیره‌سازی، رونویسی رکوردهای قدیمی مجاز است.

نام الزام شماره الزام
تولید داده ممیزی 1.1 (FAU_GEN.1.1) 1
مودم باید قادر به تولید رکورد ممیزی از رویدادهای قابل ممیزی زیر باشد: آغاز و خاتمه‌ اجرای ]انتخاب: توابع ممیزی، تمامی توابع کارکردی[ در هر بار اجرا تمامی رویدادهای ذکر شده به تفکیک الزام در جدول لیست رویدادهای قابل ممیزی تمامی اقدامات مدیریتی شامل موارد زیر: ورود و خروج مدیریتی به سیستم (در صورتی که مدیران سیستم دارای حساب کاربری شخصی باشند، نام حساب کاربری آنها نیز باید ثبت شود( هرگونه تغییر در پیکربندی توابع امنیتی (علاوه بر گزارش اینکه تغییر رخ داده، نوع تغییر انجام شده نیز باید مشخص شود.) تولید/واردکردن 20 ، تغییر، یا پاک کردن کلیدهای رمزنگاری (علاوه بر گزارش رخداد مربوطه، نام کلید یا مرجع مشخص‌کننده آن باید تعیین شود) تغییر گذرواژه (نام حساب کاربری مربوطه نیز باید ثبت شود( انتخاب: ]هیچ اقدام دیگر، اختصاص: ]لیستی از دیگر اقدامات مدیریتی دارای اهمیت که قابل رکورد کردن باشد[[ تمامی دیگر رویدادهای قابل ممیزی و دارای اهمیت که جزء موارد تأکید شده فوق نباشد. نکات کاربردی: در صورتی که لیست ارائه‌شده برای ثبت ممیزی از اقدامات مدیریتی کافی نبوده و نویسنده‌ سند هدف امنیتی تشخیص به لزوم ثبت اقدامات و فعالیت‌های مدیریتی بیشتری دهد، می‌تواند با استفاده از قسمت <<اختصاص>> که در <<انتخاب>> قرارگرفته است، اقدامات مدیریتی دیگری را به لیست اضافه کند. درخصوص مورد اول برای ثبت رکورد ممیزی در مورد آغاز و خاتمه اجرای توابع کارکردی، مودم می‌تواند تنها برای اجرای توابع ممیزی چنین رکوردی ثبت کند، ولی بهتر است برای دیگر توابع کارکردی امنیتی نیز چنین رکوردی ثبت شود، هرچند که این سند آن را اجبار نمی‌کند. ثبت رکورد ممیزی از کلیدهای رمزنگاری تنها اشاره به کلیدهای غیر موقتی دارد که برای بیش از یک نشست استفاده می‌شوند.
تولید داده ممیزی 2.1 (FAU_GEN.1.2) 2
در هر رکورد ممیزی دست کم اطلاعات زیر باید ذخیره شود: تاریخ و زمان رویداد، نوع رویداد، هویت موجودیت انجام‌دهنده رویداد و نتیجه رویداد (موفقیت یا شکست) اطلاعات اضافی اختصاصی برای هر رویداد قابل ممیزی مطابق با ستون سوم از جدول زیر با نام لیست رویدادهای قابل ممیزی. (همچنین برای موارد انتخابی و اختیاری می‌بایست به همین ترتیب و مطابق با جدول مربوطه با نام "لیست رویدادهای قابل ممیزی برای کارکردهای انتخابی" اطلاعات مورد نیاز ثبت شود.) لیست رویدادهای قابل ممیزی به تفکیک کارکردهای امنیتی مورد نیاز کارکرد امنیتی مورد نیاز رویداد قابل ممیزی اطلاعات اضافی مورد نیاز FAU_GEN.1 × × FAU_GEN.2 × × FAU_STG_EXT.1 × × FCS_CKM.1 × × FCS_CKM.2 × × FCS_CKM.4 × × FCS_CKM_EXT.1 × × FCS_COP.1/DataEncryption × × FCS_COP_EXT.1.1/DataEncryption × × FCS_COP_EXT.1.2/DataEncryption × × FCS_COP.1/SigGen × × FCS_COP.1/Hash × × FCS_COP.1/KeyedHash × × FCS_COP_EXT.2.1/Data Integrity on air interface × × FCS_RBG_EXT.1 × × FIA_AFL.1 ثبت لاگین ناموفق در مودم زمانی که تعداد آن به تعداد آستانه تعیین شده برسد. در اتصال راه دور: مبدا تلاش کننده برای لاگین (مانند آدرس IP آن) FIA_PMG_EXT.1 × × FIA_UIA_EXT.1 هر نوع استفاده از سرویس‌های بدون نیاز به احراز هویت در اتصال راه دور: مبدا تلاشکننده (مانند آدرس IP آن) FIA_UAU_EXT.2 انجام فرایند احراز هویت و ورود به سیستم در اتصال راه دور: مبدا تلاشکننده (مانند آدرس IP آن) FIA_UAU_EXT.3 × × FIA_UAU.7 × × FMT_MOF.1/ManualUpdate هر نوع تلاش برای شروع به‌روزرسانی دستی × FMT_MTD.1/CoreData × × FMT_SMF.1 انجام هر نوع فعالیت و پیکربندی توسط سرپرست × FMT_SMR.2 × × FPT_SKP_EXT.1 × × FPT_APW_EXT.1 × × FPT_TST_EXT.1 × × FPT_TUD_EXT.1 شروع به‌روزرسانی نتیجه به‌روزرسانی (موفقیت یا شکست) × FPT_STM_EXT.1 هر نوع ایجاد تغییر و پیکربندی مجدد زمان (چه به صورت دستی توسط مدیر و چه به صورت اتوماتیک توسط سرور NTP) زمان قبلی و جدید مبدا انجامدهنده تغییر (مانند آدرس IP آن) FTA_SSL_EXT.1 (در صورتی که گزینه قفل‌کردن برای نشست‌های محلی غیرفعال پیاده‌سازی شده است.) هر نوع تلاش برای بازگشایی مجدد یک نشست قفلشده که به خاطر عدم فعالیت برای مدت زمان معین قفل شده است. × FTA_SSL_EXT.1 (در صورتی که گزینه خاتمه‌دادن برای نشست‌های محلی غیرفعال پیاده‌سازی شده است.) ثبت رویداد خاتمه‌دادن به یک نشست غیرفعال محلی × FTA_SSL.3 ثبت رویداد خاتمه‌دادن به یک نشست راه دور غیرفعال × FTA_SSL.4 ثبت رویداد خاتمه‌دادن به نشست راه دور مربوطه توسط خود سرپرست راه دور × FTA_TAB.1 × × FTP_ITC.1 آغاز برقراری یک کانال امن خاتمهیافتن کانال امن وقوع مشکل در کارکرد کانال امن هویت شروعکننده و مقصد کانال امن به مشکلخورده FTP_TRP.1/Admin آغاز برقراری یک کانال امن با یک سرپرست راه دور خاتمهیافتن کانال امن وقوع مشکل در کارکرد کانال امن ×
تولید داده ممیزی 2(FAU_GEN.2) 3
در مورد آن دسته از اقداماتی که توسط کاربران احراز هویت شده انجام می‌شوند، مودم باید بتواند رویداد قابل ممیزی را با درج هویت کاربر انجامدهنده آن ثبت کند.
محل ذخیره‌سازی داده‌های ممیزی 1 (FAU_ STG_EXT21 .1.1) 4
همچنان که پیشتر گفته شد، مودم باید قادر به ذخیره رکوردهای ممیزی روی هارد خود باشد و در صورت پر شدن فضای ذخیره‌سازی آن اقدام مناسب برای رونویسی را مطابق با الزام 6 انجام دهد. اما در عین حال باید قادر به ارسال داده‌های ممیزی تولید شده به یک موجودیت IT خارجی با استفاده از یک کانال امن مطابق با الزام FTP_ITC.1 باشد. شایان ذکر است که در صورت استفاده از هر یک از پروتکل‌های HTTPS، TLS، DTLS، SSH یا IPsec به عنوان پروتکل ارتباطی امن، تمامی الزامات مربوط به آن پروتکل نیز باید تکمیل و به سند هدف امنیتی اضافه گردد. همچنین در صورت قطع شدن کانال ارتباطی امن، مکانیزم مناسب برای جلوگیری از ارسال داده‌های ممیزی تا زمان اتصال مجدد کانال باید اتخاذ شود. نکته کاربردی: از آنجایی که سرور ممیزی خارجی قسمتی از مودم نیست، به جز الزام برقراری کانال امن FTP_ITC.1 الزام دیگری برای آن تعریف نمی‌شود. همچنین پس از پیکربندی، مودم باید توانایی ارسال اتوماتیک داده‌های ممیزی را بدون مداخله سرپرست داشته باشد. به عبارتی دیگر، انتقال دستی نمی‌تواند الزامات را برآورده کند. ارسال می‌تواند به صورت بلادرنگ یا دوره‌ای انجام شود. اگر ارسال به صورت بلادرنگ انجام نمی‌شود، باید مشخص شود در چه زمانی و با چه تناوبی این ارسال‌ها انجام می‌گیرند. این تناوب باید قابل قبول باشد.
محل ذخیره‌سازی داده‌های ممیزی 2 (FAU_ STG_EXT.1.2) 5
مودم باید بتواند داده‌های ممیزی تولیدشده را در خود ذخیره کند.
محل ذخیره‌سازی داده‌های ممیزی 3(FAU_ STG_EXT.1.3) 6
با پرشدن حافظه محلی برای ذخیره‌سازی رکوردهای ممیزی، مودم باید ]انتخاب: 1) داده‌های ممیزی جدید را ابتدا روی یک سرور خارج از مودم یا مکان مناسبی ثبت نماید و سپس آن‌ها را دور بریزد، 2) داده‌های ممیزی قدیمی را با داده‌های جدید بازنویسی کند و 3) از این رویکرد استفاده کند: ]اختصاص: قوانین بازنویسی رکوردهای قدیمی[، ]اختصاص: اقدامات دیگر[ [ الزام فوق امکان سه انتخاب را برای رونویسی رکوردهای قدیمی فراهم می‌کند: 1. دور ریختن رکوردهای جدید که این حالت توصیه نمی‌شود، ولی در هر صورت سرور خارجی باید رکوردهای جدید را داشته باشد. 2. رکوردهای قدیمی رونویسی شود. بدین منظور قسمت اختصاص امکان تعریف قاعده رونویسی را به خود سرپرست مودم می‌سپارد. 3. سرپرست خود می‌تواند در مورد رکوردهای جدید تصمیم‌گیری کند. به عنوان مثال می‌تواند ارسال رکوردهای جدید به یک سرور خارجی را انتخاب کند.

  1. کلاس پشتیبانی از رمزنگاری

در این بخش الزامات مرتبط با رمزنگاری شرح داده خواهند شد. این الزامات شامل تولید کلید و بیت تصادفی، روش‌های استقرار کلید22 ، از بین بردن کلید، روش‌های مختلف رمزنگاری برای پیاده‌سازی رمزنگاری/رمزگشایی AES، تأیید و تصدیق امضای دیجیتال و نیز متدهای ساده یا مبتنی بر کلید برای درهم‌سازی است.

در میان الزامات این بخش، موارد مختلفی از گزینه ]انتخاب[ را خواهید دید که بالطبع بر اساس انتخاب انجام شده نیازمند پیاده‌سازی الزامات مربوطه از بخش الزامات انتخابی است.

شماره الزام نام الزام
7 مدیریت کلید رمزنگاری 1 (FCS_CKM.1)
مودم می‌بایست تولید کلیدهای رمزنگاری نامتقارن را با انتخاب یکی از متدهای مقابل برای تولید کلید انجام دهد: ]انتخاب: روش RSA با طول کلید 2048 بیت یا بزرگتر که الزامات ذکر شده در پیوست B.3 از سند FIPS PUB 186-4 با عنوان استاندارد امضای دیجیتال DSS را رعایت کند. روش ECC بر مبنای منحنی ] NIST Curvesانتخاب: [P-256, P-384, P-521 که الزامات ذکر شده در پیوست B.4 از سند FIPS PUB 186-4 با عنوان استاندارد امضای دیجیتال DSS را رعایت کند. روش FFC با طول کلید 2048 بیت یا بزرگتر که الزامات ذکر شده در پیوست B.1 از سند FIPS PUB 186-4 با عنوان استاندارد امضای دیجیتال DSS را رعایت کند. روش FFC با استفاده از گروه‌های “safe-prime” که الزامات ذکر شده در سند زیر “NIST Special Publication 800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” و ]انتخاب: [RFC 3526, RFC 7919 را رعایت کند. [ نکات کاربردی: این الزام چهار نوع الگوی تولید کلید برای استفاده در راستای استقرار کلید و نیز احراز هویت دستگاه‌ها فراهم می‌کند که می‌توان از میان آن‌ها یک مورد را انتخاب کرد. در صورتی که هدف از انتخاب انجام‌شده در این الزام برای استقرار کلید باشد، انتخاب انجام‌شده می‌بایست با انتخابی که در الزام "مدیریت کلید رمزنگاری 2" و نیز پروتکل‌های رمزنگاری انجام می‌شود، مطابقت داشته باشد. همچنین در صورتی که هدف برای احراز هویت دستگاه‌ها باشد، باید علاوه بر ssh-rsa، ecdsa-sha2-nistp256، ecdsa-sha2-nistp384 و ecdsa-sha2-nistp521، کلید عمومی نیز مرتبط با گواهینامه X.509v3 باشد. اگر مودم به‌عنوان یک دریافت‌کننده در الگوهای استقرار کلید عمل کند و برای پشتیبانی از احراز هویت دوطرفه پیکربندی نشده باشد، مودم نیاز به پیاده‌سازی تولید کلید ندارد.
8 مدیریت کلید رمزنگاری 2 (FCS_CKM.2.1)
مودم باید استقرار کلید23 رمزنگاری را بر اساس یک روش استاندارد استقرار کلید رمزنگاری انجام دهد: ]انتخاب: الگوهای استقرار کلید RSA که ویژگی‌های مشخص‌شده در بخش 7.2 از RFC3447 با نام RSAES-PKCS1-v1_5 را رعایت کنند. الگوهای استقرار کلید مبتنی بر روش Elliptic curve که ویژگی‌های مشخص‌شده در نسخه بازبینی شده 2 از سند NIST SP 800-56A با عنوان " Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography" را رعایت کند. الگوهای استقرار کلید مبتنی بر روش Finite field که ویژگی‌های مشخص شده در نسخه بازبینی شده 2 از سند NIST SP 800-56A با عنوان " Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography" را رعایت کند. الگوهای استقرار کلید FFC با استفاده از گروه‌های “safe-prime” که ویژگی‌های مشخص شده در نسخه بازبینی شده 3 از سند NIST SP 800-56A با عنوان " Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography" و ]انتخاب: RFC 3526، [RFC 7919 را رعایت کند. [
9 نابودسازی کلید رمزنگاری (FCS_CKM.4.1)
مودم می‌بایست قابلیت نابودسازی کلیدهای تولید شده را داشته باشد: ]اختصاص: برای کلیدهای متن-ساده (رمز نشده) که در حافظه گذرا قراردارند، نابودسازی باید از طریق ]انتخاب: بازنویسی ساده از طریق ]انتخاب: تولید عبارت شبه تصادفی با استفاده از تابع تولید بیت تصادفی، یک عبارت تماماً صفر، یک عبارت تماماً یک، یک مقدار جدید از کلید، ]اختصاص: یک مقدار ثابت یا پویا که شامل هیچ CSP24 نباشد[[، یا نابودسازی مرجع کلید (مستقیماً با درخواست زباله‌روبی) باشد[ برای کلیدهای متن-ساده (رمز نشده) که در حافظه پایدار قراردارند، نابودسازی باید از طریق یک واسط فراهمشده توسط خود مودم انجام شود که ]انتخاب: به ‌صورت منطقی مکان ذخیره‌سازی کلید را آدرس می‌دهد و بازنویسی را برای ]انتخاب: یکبار، ]اختصاص: لیست دفعات[[ 25 انجام می‌دهد که شامل ]انتخاب: تولید عبارت شبه تصادفی با استفاده از تابع تولید بیت تصادفی، عبارت تماماً صفر، عبارت تماماً یک، یک مقدار جدید از کلید، ]اختصاص: یک مقدار ثابت یا پویا که شامل هیچ CSP نباشد[[ است. به یک ماژول دستور دهد تا اشارهکننده معرف کلید را پاک کند. نکات کاربردی: برای عبارت "واسط فراهمشده توسط خود مودم"، سند خلاصه مشخصات مودم باید این "بخش" و واسط مرتبط با آن را مشخص و معرفی کند. واسط اشارهشده می‌تواند در مودم‌های مختلف، اشکال متفاوتی داشته باشد. شاید مشهودترین شکل آن یک برنامه کاربردی روی یک سیستم‌عامل باشد. زمانی که از روش‌های تخریب یا نابودسازی مختلفی برای کلیدهای مختلف و/یا موقعیت‌های تخریب مختلف استفاده می‌شود، این روش‌ها و کلیدها/موقعیت‌های متفاوت بکار گرفته شده باید در سند خلاصه مشخصات مودم توصیف شوند. سند خلاصه مشخصات مودم باید همه کلیدهای مرتبط استفاده شده در پیاده‌سازی الزامات کارکرد امنیتی را توصیف کند، همچنین مواردی که محل ذخیره شدن کلیدها به‌صورت متن آشکار است را شامل می‌شود. در بعضی از اختصاص‌های ذکر شده، از عبارت "شامل هیچ CSP نباشد" استفاده شده است. این جمله به این معنی است که مودم از برخی داده‌های خاص استفاده ‌کند که شامل هیچکدام از مقادیر تولیدشده توسط تولیدکننده بیت تصادفی موجود در الزام FCS_RBG_EXT یا مقادیر مشخص لیست‌ شده در این الزام، به طور مثال موارد لیست شده در اولین انتخاب از اولین اختصاص این الزام، نیست. در واقع وجود عبارت "شامل هیچ CSP نباشد" برای مطمئن شدن از این موضوع است که حتماً بازنویسی داده با دقت انجام شده و مقدار مورد استفاده برای بازنویسی احیاناً یک کلید یا داده حساس را شامل نشود. مهم: الزام به ذکر است که کلیدهای رمزنگاری در این الزام، شامل کلیدهای نشست نیز می‌شود. همچنین قابل ذکر است که الزام نابود سازی کلید برای کلیدهای عمومی در جفت کلید نامتقارن، اعمال نمی‌شود.
10 انشعاب کلیدهای رمزنگاری برای اتصالات مبتنی بر لینک هوایی (FCS_CKM_EXT.1)
مودم باید قابلیت انشعاب کلیدهای رمزنگاری UPenc، RRCenc، RRCint، NASenc و NASint را از کلید مستر K بر اساس استاندارد و الگوهای تعریف شده در ضمیمه A از سند TS 33.401 داشته باشد. نکات کاربردی: همچنان که در بخش معرفی معماری شبکه‌های LTE بیان شد، برای جلوگیری از بروز مشکلات امنیتی، از ارسال کلیدهای رمزنگاری میان مودم و شبکه EPC پرهیز شده و هر یک از مؤلفه‌‌های مذکور باید قادر به انشعاب یا استخراج کلیدهای مورد نیاز از کلید مستر K باشند. کلید مستر K نیز روی سیم‌کارت و نیز پایگاه داده HSS در شبکه LTE موجود بوده و لذا هم مودم و هم شبکه EPC از آن مطلع هستند. برای انشعاب کلیدهای مربوطه از کلید K نیز استاندارد و توابع مشخصی تعریف شده است که در سند TS 33.401 جزئیات آن تشریح شده است. سند TS 33.401 مرجع اصلی در تعریف معماری امنیتی شبکه‌های LTE به‌حساب می‌آید. این سند ضمن بیان نیازمندی‌ها و استانداردهای امنیتی مورد نظر برای بخش‌های مختلف یک شبکه LTE، چگونگی انشعاب یا استخراج کلیدهای مورد نیاز را نیز در ضمیمه A بیان می‌کند.
11 عملیات رمزنگاری/رمزنگاری داده‌ها (FCS_COP.1/DataEncryption)
مودم باید رمزگذاری و رمزگشایی را بر اساس الگوریتم AES در حالت ]انتخاب: CBC، GCM، [CTR و در اندازه کلید ]انتخاب: 128 بیتی، 192 بیتی، 256 بیتی[ و با توجه به استاندارد AES که در 3-18033 ISO تعریف شده است و استاندارد] انتخاب: CBC که در 10116 ISO تعریف شده است، GCM که در 19772 ISO تعریف شده است، CTR که در 10116 ISO تعریف شده است[ انجام دهد. نکات کاربردی: نخست حالت یا مد کاری الگوریتم AES و سپس اندازه کلید آن و استانداردهای مربوطه باید انتخاب شوند. مد و اندازه کلید انتخاب شده در این مرحله متناظر با انتخاب مجموعه رمز برای الزام کانال امن است.
12 عملیات رمزنگاری/ترافیک مدیریتی روی لینک هوایی 1 (FCS_COP_EXT.1.1/DataEncryption)
مودم باید از الگوریتم ]انتخاب: EEA1، EEA2، [EEA3 با اندازه کلید ]انتخاب: 128، 256[ بیتی برای رمزنگاری/رمزگشایی پیام‌های NAS و RRC بر اساس ضمیمه B از سند TS 33.401 استفاده کند. نکات کاربردی: برای تأمین محرمانگی برای پیام‌های مدیریتی NAS و RRC سه نوع الگوریتم رمزنگاری EEA در شبکه‌های LTE پیشنهاد شده است که مودم باید یکی از آن‌ها را انتخاب و پیاده‌سازی کند. EEA1 مبتنی بر الگوریتم SNOW 3G بوده و بسیار مشابه با الگوریتم مورد استفاده در شبکه‌های UMTS است. EEA2 مبتنی بر رمزنگاری AES در مد CTR است. EEA3 نیز مبتنی بر رمزنگاری چینی ZUC است.
13 عملیات رمزنگاری/ترافیک داده روی لینک هوایی 2 (FCS_COP_EXT.1.2/DataEncryption)
مودم باید از الگوریتم ]انتخاب: EEA1، EEA2، EEA3، هیچ الگوریتمی[ با اندازه کلید ]انتخاب: 128، 256[ بیتی برای رمزنگاری/رمزگشایی ترافیک داده بر اساس سند TS 33.401 استفاده کند. نکات کاربردی: همچنان که در قسمت انتخاب مشخص شده، بر اساس استانداردهای LTE رمزنگاری ترافیک داده یا صفحه کاربر اختیاری است و مودم می‌تواند گزینه "هیچ الگوریتمی" را انتخاب کند، هر چند که توصیه در استفاده از یکی از سه الگوریتم رمزنگاری EEA است. عدم رمزنگاری ترافیک کاربر امکان شنود ترافیک را فراهم می‌کند. دلیل اصلی در اختیاری بودن این الزام، مصرف بالای باتری در گوشی‌های موبایل است. با توجه به این که مودم چنین محدودیتی ندارد، توصیه می‌شود تا با فراهمکردن یک گزینه در بخش تنظیمات، امکان انتخاب برای رمزنگاری ترافیک کاربر فراهم شود.
14 عملیات رمزنگاری/تولید و تأیید امضا (FCS_COP.1/SigGen)
مودم باید سرویس امضای دیجیتال (تولید و تأیید) را بر اساس الگوریتم‌های رمزنگاری زیر ارائه کند: ] انتخاب: الگوریتم امضای دیجیتال RSA و کلید رمزنگاری با اندازههای ]اختصاص: 2048 بیتی یا بزرگتر[ الگوریتم امضای دیجیتال Elliptic Curve و کلید رمزنگاری با اندازه‌های ]اختصاص: 256 بیتی یا بزرگتر[ [ و با رعایت موارد زیر: ]انتخاب: برای الگوریتم RSA: قسمت 5.5 از سند FIPS PUB 186-4 با عنوان "استاندارد امضای دیجیتال DSS"، برای الگوریتم Elliptic Curve: قسمت 6 و پیوست D از سند FIPS PUB 186-4 با عنوان "استاندارد امضای دیجیتال DSS" [ نکات کاربردی: نویسنده هدف امنیتی باید الگوریتم مورد استفاده برای اجرای امضای دیجیتال را انتخاب ‌کند. نویسنده هدف امنیتی باید سازگار بودن انتخاب‌ انجام شده در این قسمت با دیگر الزامات رمزنگاری را بررسی‌کند، خصوصاً زمانی که از Elliptic Curve استفاده شود.
15 عملیات رمزنگاری/الگوریتم درهمساز (FCS_COP.1/Hash)
مودم باید عملیات درهم‌سازی مبتنی بر رمزنگاری را بر اساس الگوریتم رمزنگاری ]انتخاب: SHA-1، SHA-256، SHA-384، [SHA-512 و اندازه خلاصه پیام ]انتخاب:160، 256، 384، 512[ بیتی و با رعایت استاندارد ISO/IEC 10118-3:2004 انجام دهد. نکات کاربردی: اکیداً توصیه می‌شود که از پروتکل‌های به‌روزرسانی شده که از خانواده SHA-2 پشتیبانی می‌کنند، استفاده شود. تا زمانی که پروتکل‌های بروز شده پشتیبانی شوند، این پروفایل حفاظتی اجازه پشتیبانی از پیاده‌سازی SHA-1 را منطبق بر SP 800-131A فراهم می‌کند. توجه: براساس نقشه راه SP 800-131A، استفاده از الگوریتم SHA-1 فقط می‌تواند برای عملیاتی غیر از امضای دیجیتال همچون درهم‌سازی رمز عبور و غیره استفاده شود. در نسخه‌های آتی از پروفایل حفاظتی مرجع برای محصولات شبکه، SHA-256 کمینه الزام خواهد بود. انتخاب الگوریتم درهم‌ساز باید با توجه به قدرت الگوریتم مورد استفاده برای الزام "عملیات رمزنگاری1/رمزنگاری داده‌ها" و الزام "عملیات رمزنگاری1/تولید و تأیید امضا" انجام شود (مثلاًSHA-256 برای کلیدهای 128 بیتی).
16 عملیات رمزنگاری/الگوریتم درهم‌ساز مبتنی بر کلید (FCS_COP.1/KeyedHash)
مودم باید احراز هویت پیام مبتنی بر کلید درهم‌سازی شده را بر اساس الگوریتم رمزنگاری ]انتخاب: HMAC-SHA-1، HMAC-SHA256، HMAC-SHA-384، [HMAC-SHA-512 و سایز کلید رمزنگاری ]اختصاص: اندازه کلید به بیت که در HMAC استفاده شده[ و اندازه خلاصه پیام ]انتخاب: 160، 256، 384، 512[ بیتی و با رعایت نکات ذکر شده در بخش 7 از سند ISO/IEC 9797-2:2011 انجام دهد. نکات کاربردی: اندازه کلید k در عبارت "اختصاص" بین L1 و L2 خواهد بود (تعریف شده در 10118 IEC/ISO مربوط به توابع درهم‌ساز). به طور مثال در مورد SHA-256 داریم: L2<=k<=L1 که L1=512, L2=256
17 عملیات رمزنگاری/سرویس صحت داده روی لینک هوایی (FCS_COP_EXT.2.1/Data Integrity on air interface)
مودم باید سرویس صحت داده برای پیام‌های RRC و NAS را با استفاده از الگوریتم ]انتخاب: EIA1، EIA2، [EIA3 با اندازه کلید ]انتخاب: 128، 256[ بیتی بر اساس ضمیمه C از سند TS 33.401 پیاده‌سازی کند. نکات کاربردی: همچنان که پیشتر در تشریح تهدید "رمزنگاری ضعیف" شرح داده شد، تأمین صحت داده برای پیام‌های RRC و NAS اجباری است و کلیدهای RRCint و NASint نیز بدین منظور در نظر گرفته شده است. برای تأمین صحت داده برای پیام‌های مدیریتی NAS و RRC سه نوع الگوریتم EIA در شبکه‌های LTE پیشنهاد شده است که مودم باید یکی از آن‌ها را انتخاب و پیاده‌سازی کند. EIA1 مبتنی بر الگوریتم SNOW 3G بوده و بسیار مشابه با الگوریتم مورد استفاده در شبکه‌های UMTS است. EIA2 مبتنی بر رمزنگاری AES در مد CTR است. EIA3 نیز مبتنی بر رمزنگاری چینی ZUC است.
18 عملیات رمزنگاری/تولید بیت تصادفی 1 (FCS_RBG_EXT.1)
��ودم باید سرویس تولید بیت تصادفی را بر اساس استاندارد ISO/IEC 18031:2011 و با استفاده از ]انتخاب: Hash_DRBG (any)، HMAC_DRBG (any)، [CTR_DRBG (AES) فراهم کند. نکات کاربردی: برای Hash_DRBG و HMAC_DRBG از هر یک از SHA-1، SHA-256، SHA-384، SHA-512 می‌توان استفاده کرد، ولی برای CTR_DRBG پیاده‌سازی‌های مبتنی بر AES باید استفاده شود.
19 عملیات رمزنگاری/تولید بیت تصادفی 2 (FCS_RBG_EXT.2)
تابع تولید بیت تصادفی برای تولید رشته‌های تصادفی، خود نیازمند تغذیه شدن با رشته‌های نویزی یا تصادفی است که توسط منابع نرم‌افزاری و سخت‌افزاری دیگر تولید می‌شوند. از این رو، تابع تولیدکننده بیت تصادفی RBG باید حداقل توسط یک منبع آنتروپی تغذیه شود؛ و این منبع باید آنتروپی‌ها را از ]انتخاب: ]اختصاص: تعداد[ منبع نرم‌افزاری برای تولید آنتروپی، ]اختصاص: تعداد[ منبع سخت‌افزاری برای تولید آنتروپی[ با حداقل سایز آنتروپی ]انتخاب: 128، 192، 256[ بیتی گردآوری کند. همچنین سایز آنتروپی باید معادل یا بزرگتر از طولانی‌ترین یا قوی‌ترین کلیدی باشد که در مودم تولید و استفاده خواهد شد. نکات کاربردی: منظور از منبع تولید آنتروپی یک یا چند منبع سخت‌افزاری یا نرم‌افزاری است که قادر به تولید رشته‌های تصادفی هستند که توسط تابع RBG یا Deterministic RBG برای تولید رشته‌های نهایی مورد نیاز برای تولید کلید استفاده خواهند شد. در قسمت اختصاص، منظور از عبارت "تعداد"، تعداد منابع مورد استفاده است. مثلاً [2] منبع نرم‌افزاری برای تولید آنتروپی.

  1. کلاس شناسایی و احراز هویت

به عنوان ابزاری امن برای ورود، مودم باید یک سازوکار ورود مبتنی بر گذرواژه را در اختیار مدیر یا سرپرست مودم قرار دهد. مودم باید سرپرست را ملزم به انتخاب یک گذرواژه قدرتمند کرده و نیز او را ملزم به تغییر مرتب این گذرواژه کند. همچنین برای جلوگیری از حملاتی که در آن‌ها فرد مهاجم نوشتن گذرواژه یا فرایند ورود سرپرست به مودم را می‌بیند، گذرواژه باید در هنگام ورود به مودم به حالت محو و ناخوانا دیده شود. قفل‌کردن و یا خاتمه‌دادن اتوماتیک به هر نشست غیرفعال بعد از یک مدت زمان معین را نیز می‌توان برای جلوگیری از ورود غیرمجاز به مودم به وسیله دزدیدن نشست‌های قبلی قرار داد. همچنین گذرواژه‌ها باید به شکل محو و ناخوانا در حافظه ذخیره شوند، بهگونه‌ای که هیچ واسطی برای خواندن آن به شکل متن ساده وجود نداشته باشد.

شماره الزام نام الزام
20 مدیریت احراز هویت ناموفق 1 (FIA_AFL.1)
مودم باید قادر به تشخیص مواقعی باشد که در آن تعداد دفعات تلاش یک موجودیت برای احراز هویت و لاگین کردن به عنوان سرپرست مودم به صورت راه دور از تعداد معینی ]اختصاص: تعداد دفعات[ فراتر می‌رود. همانطور که در اختصاص مشخص شده است، این تعداد معین باید توسط سرپرست مودم قابل تنظیم باشد.
21 مدیریت احراز هویت ناموفق 2 (FIA_AFL.2)
با رسیدن به تعداد دفعات ناموفق تعیین‌شده در لاگین کردن، مودم باید ]انتخاب: اکانت راه دور مذکور را تا زمانی که یک ]اختصاص: اقدام[ توسط یک مدیر محلی انجام شود در حالت قفل نگه دارد؛ اکانت تخطیکننده را قفل کند تا وقتی که یک دوره زمانی تعریف شده توسط سرپرست سپری شود[ نکات کاربردی: منظور از قفل‌کردن در الزام فوق، اجازه ندادن برای احراز هویت و ورود به سیستم است. این الزام تنها به سرپرستان راه دور اعمال می‌شود و نه سرپرستان محلی که به طور مثال با کابل قصد اتصال به مودم را دارند. رسیدن به این مهم نیازمند وجود اکانت‌های سرپرستی محلی و راه دور جداگانه یا داشتن سازوکار احراز هویتی است که بتواند انواع ورود محلی و راه دور را به ‌صورت متمایز تشخیص دهد. در خصوص قسمت اختصاص و تعیین یک اقدام مناسب برای آن به طور مثال می‌توان به ریسِت کردن پسورد و یا خارج کردن اکانت مذکور از حالت قفل اشاره کرد. سند خلاصه مشخصات مودم باید بیان کند که مودم چگونه این اطمینان را ایجاد می‌کند که مسدود شدن موقت یا دائم یک سرپرست راه دور به دلیل شکست‌های مداوم در احراز هویت، باعث به وجود آمدن عدم دسترس‌پذیری محلی سرپرست نمی‌شود (به طور مثال با تعریفکردن یک اکانت محلی که مسدودسازی برای آن اعمال نمی‌شود(.
22 مدیریت رمز ورود 1 (FIA_PMG_EXT.1)
مودم باید امکانات زیر را برای تعریف گذرواژه یا پسوردهای مدیریتی فراهم کند: گذرواژه را باید بتوان با هر ترکیبی از حروف کوچک و بزرگ، اعداد و کاراکترهای ویژه مطرح شده در این بخش ساخت: ]انتخاب: "("، ")"، "*"، "&"، "^"، "%"، "$"، "#"، "@"، "!"، ]اختصاص: سایر کاراکترها[[ حداقل طول گذرواژه باید قابل پیکربندی به یک عدد مابین ]اختصاص: کمترین تعداد کاراکترهای قابل پشتیبانی توسط مودم[ و ]اختصاص: تعداد کاراکترهای بزرگتر مساوی با 15[ باشد. نکات کاربردی: نویسنده هدف امنیتی کاراکترهای ویژه قابل استفاده در گذرواژه را انتخاب می‌کند. وی می‌تواند با استفاده از عبارت اختصاص در بند 1، کاراکترهای دیگری را به لیست اضافه کند. منظور از واژه "گذرواژه مدیریتی" گذرواژه‌هایی هستند که توسط مدیران سیستم در کنسول محلی یا برای پروتکل‌هایی که از گذرواژه پشتیبانی می‌کنند مانند SSH و HTTPS مورد استفاده قرار می‌گیرند. این گذرواژه‌ها گاهی نیز برای ارائه آن دسته از داده‌های پیکربندی که از دیگر الزامات کارکرد امنیتی در مودم پشتیبانی می‌کنند، مورد استفاده قرار می‌گیرند. اختصاص دوم از بند 2، باید به بزرگترین مقداری که می‌تواند برای کمینه طول رمز عبور توسط سرپرست پیکربندی شود، تنظیم گردد.
23 شناسایی و احراز هویت کاربر 1 (FIA_UIA_EXT.1.1)
به هنگام اتصال یک موجودیت خارجی مانند یک سرپرست انسانی به مودم، پیش از انجام فرایند احراز هویت، مودم باید اجازه انجام فعالیت‌های زیر را بدهد: نمایش بنر هشدار با توجه به الزام FTA_TAB.1 (این بنر در مورد دسترسی غیرمجار به مودم هشدار می‌دهد.) ]انتخاب: هیچ اقدامی، ]اختصاص: لیستی از سرویس‌ها و اقداماتی که مودم می‌تواند بدون نیاز به احراز هویت برای کاربر فراهم کند.[[ نکات کاربردی: ممکن است در مواردی امکان ارائه برخی از سرویس‌ها بدون نیاز به احراز هویت در مودم به کاربران فراهم شود. به طور مثال کاربر بتواند پیش از احراز هویت و اتصال به مودم با انجام سرویس ping از اتصال آن به اینترنت مطمئن شود. این گونه سرویس‌ها را می‌توان در قسمت اختصاص از مورد 2 گنجاند.
24 شناسایی و احراز هویت کاربر 2 (FIA_UIA_EXT.1.2)
پیش از آن که مودم امکان انجام اقدامات مدیریتی در خود را فراهم آورد، باید هر مدیر سیستم را ملزم کند که به صورت موفق شناسایی و احراز هویت شود. احراز هویت می‌تواند مبتنی بر گذرواژه و از طریق کنسول محلی و یا از طریق پروتکلی صورت گیرد که از گذرواژه‌ها پشتیبانی می‌کند (مانند SSH) و یا بر اساس گواهینامه انجام شود (مانند SSH و TLS)
25 سازوکار احراز هویت بر اساس رمز عبور 2(FIA_UAU_EXT.2.1)
مودم باید یک سازوکار احراز هویت محلی مبتنی بر ]انتخاب: گذرواژه، کلید عمومی 26 SSH، گواهینامه27 ، ]اختصاص: مکانیزم‌های احراز هویت دیگر[[ برای احراز هویت سرپرستان محلی فراهم کند. نکات: عبارت اختصاص برای مشخصکردن دیگر سازوکارهای محلی احراز هویت پشتیبانی شده است. سازوکارهای احراز هویت محلی در واقع آن‌هایی هستند که از طریق کنسول محلی انجام می‌شوند. نشست‌های مدیریتی راه دور و سازوکارهای احراز هویت مربوط به آن‌ها در الزام FTP_TRP.1/Admin مشخص شده‌اند.
26 سازوکار اتصال و احراز هویت روی لینک هوایی/احراز هویت (FIA_UAU_EXT.3.1)
مودم باید مکانیزم احراز هویت در فرایند اتصال مودم به شبکه LTE را مطابق با پروتکل AKA و سازوکار تعریف شده در سند TS 33.401 پیاده‌سازی کند. نکات کاربردی: همچنان که در زیربخش مربوط به تهدید "ضعف در احراز هویت سیستم‌های دیگر" بیان شد، مکانیزم AKA روندی استاندارد برای احراز هویت دو طرفه میان مودم و شبکه LTE فراهم می‌کند که مبتنی بر کلید مستر K است. این مکانیزم ضمن اینکه به طرفین کمک می‌کند تا از هویت یکدیگر مطمئن شوند، در پایان اجرای آن منتهی به تولید کلید KASME از کلید K می‌شود که مختص اتصال مربوطه بوده و کلیدهای بعدی نیز از آن استخراج خواهند شد.
27 سازوکار اتصال و احراز هویت روی لینک هوایی/مقابله با تهدید منع سرویس (FIA_UAU_EXT.3.2)
در صورت دریافت پیام ATTACH REJECT و TRACKING AREA UPDATE REJECT در فرایند اتصال مودم به شبکه LTE، مودم باید به تلاش مجدد برای اتصال به شبکه با جستجو کردن ایستگاه‌های باند پایه دیگر ادامه دهد. نکات کاربردی: این الزام از وقوع منع سرویس با ارسال پیام‌های مذکور از جانب یک ایستگاه پایه تقلبی جلوگیری می‌کند. علت وقوع تهدید مربوطه از آنجایی است که پیام ATTACH REJECT پیش از انجام احراز هویت دوطرفه می‌تواند ارسال شود و از این رو، مودم نمی‌تواند تشخیص دهد که این پیام از جانب یک ایستگاه پایه معتبر و یا تقلبی ارسال شده است. از سوی دیگر با دریافت این پیام معمولاً سیم‌کارت تلاش مجددی برای اتصال به شبکه انجام نمی‌دهد و گاهاً نیاز به ریستارت آن است. لذا برای رفع این مشکل باید مکانیزمی لحاظ شود تا در صورت دریافت پیام ذکر شده، مودم به تلاش برای اتصال به دیگر ایستگاه‌های پایه ادامه دهد.
28 سازوکار اتصال و احراز هویت روی لینک هوایی/مقابله با تهدید تقلیل به تکنولوژی GSM (FIA_UAU_EXT.3.3)
مودم باید امکان انتخاب نوع شبکه سلولار را به مدیر بدهد. نکات کاربردی: منظور از نوع شبکه، انواع LTE، UMTS و GSM است. الزام فوق بیان می‌کند که به طور مثال سرپرست بتواند با انتخاب LTE و UMTS از اتصال به شبکه GSM جلوگیری کند. ضرورت الزام فوق از آنجایی است که به علت نبود احراز هویت دوطرفه در تکنولوژی GSM، یک ایستگاه پایه تقلبی می‌تواند با استفاده از این امکان، مودم را مجبور به استفاده از تکنولوژی GSM کند، بدون اینکه مودم قادر به تشخیص این باشد که به ایستگاه تقلبی متصل شده است. مزیت این اتصال برای ایستگاه تقلبی این خواهد بود که الگوریتم‌های رمزنگاری مورد استفاده در GSM دارای ایرادات اساسی بوده و ترافیک قابل شنود خواهد بود. (تذکر: در صورتی که پردازنده باند پایه و سیم‌کارت از چنین امکانی پشتیبانی نمی‌کنند، پیاده‌سازی این الزام در نسخه فعلی از این پروفایل حفاظتی اجباری نخواهد بود.)
29 سازوکار اتصال و احراز هویت روی لینک هوایی / استفاده از شناسه موقتی (FIA_UAU_EXT.3.4)
مودم باید امکان استفاده از شناسه موقتی GUTI به جای IMSI را در فرایند اتصال به شبکه LTE داشته باشد. نکات کاربردی: همانطور که تشریح فرایند اتصال مودم به شبکه LTE بیان شد، ارسال شناسه IMSI به صورت متن-ساده انجام شده و لذا به سادگی قابل شنود است. این مسأله امکان شناسایی کاربران موجود در یک ناحیه را نیز برای یک ایستگاه پایه تقلبی فراهم می‌کند. تخصیص شناسه‌های موقتی و مختص به نشست به مودم مانند GUTI توسط شبکه LTE می‌تواند از مشکل ذکرشده جلوگیری کند. برای رسیدن به این هدف مودم نیز باید قادر به پشتیبانی و استفاده از این شناسه‌های موقتی باشد.
30 سازوکار اتصال و احراز هویت روی لینک هوایی/استفاده از شناسه هویتی Code PIN روی سیم‌کارت (FIA_UAU_EXT.3.5)
سیم‌کارت مورد استفاده در مودم باید از شناسه هویتی Code PIN پشتیبانی کند. نکات کاربردی: اهمیت پشتیبانی از این شناسه برای استفاده از سیم‌کارت این است که در صورت دزدیده شدن آن توسط افراد غیر، بدون احراز هویت با این کد قابل استفاده نباشد.
31 بازخورد امن در مکانیزم احراز هویت (FIA_UAU.7)
هنگامی که فرایند احراز هویت روی کنسول محلی در حال جریان است، مودم تنها باید بازخورد مبهم28 را در اختیار سرپرست مودم قرار دهد. نکات کاربردی: "بازخورد مبهم" به معنی بازخوردی است که در آن مودم داده‌های احراز هویت واردشده توسط کاربر را به صورت واضح و قابل خواندن نشان نمی‌دهد؛ البته ممکن است روند پیشرفت به شکل مبهم نشان داده شود (مانند یک ستاره برای هر کاراکتر). بازخورد مبهم همچنین نشان می‌دهد که مودم در جریان احراز هویت هیچ اطلاعاتی را که ممکن است نشان‌دهنده داده‌های احراز هویت باشد، نمایش نمی‌دهد.

  1. کلاس مدیریت امنیت

این کلاس شامل چهار دسته الزام برای مدیریت کارکردهای امنیتی در مودم است:

  • FMT_MOF: مدیریت فرایند به‌روزرسانی
  • FMT_MTD: مدیریت دسترسی به داده‌های پیکربندی
  • FMT_SMR: تعریف نقش‌های امنیتی
  • FMT_SMF: تعریف حداقل قابلیت‌های امنیتی که در اختیار سرپرستان خواهد بود.

در کنار این الزامات مدیریتی اصلی، برخی الزامات اختیاری نیز در فصل 6 و تعدادی الزامات انتخابی نیز در فصل 7 ذکر شده‌اند.

شماره الزام نام الزام
32 مدیریت کارکرد امنیتی 1/ به‌روزرسانی دستی (FMT_MOF.1/ManualUpdate)
مودم باید امکان استفاده از توابع به‌روزرسانی دستی را به سرپرست‌های امنیتی محدود کند. نکات کاربردی: این الزام امکان آغاز به‌روزرسانی دستی را به سرپرست مودم محدود می‌کند.
33 مدیریت دسترسی به داده‌ها 1 (FMT_MTD.1/CoreData)
مودم باید امکان "مدیریت" داده‌های امنیتی، مانند اطلاعات پیکربندی مودم، را به سرپرست‌های امنیتی محدود کند. نکات کاربردی: منظور از "مدیریت" می‌تواند هر یک از اقدامات مقابل و حتی موارد دیگری از این دست باشد: مشاهده، تولید، مقداردهی اولیه، تغییر مقدار پیشفرض، تغییر مقدار داده، پاک کردن و اضافه کردن مقدار جدید. الزام حاضر همچنین شامل بازگرداندن29 گذرواژه کاربر به حالت پیش‌فرض توسط سرپرست مودم است. عبارت "CoreData"در نام این الزام برای جداسازی آن با الزام ذکر شده در قسمت الزامات اختیاری با نام FMT_MTD.1/CryptoKeys است.
34 تعریف کارکردهای امنیتی 1 (FMT_SMF.1)
مودم باید امکانات و توابع مدیریتی زیر را ارائه کند: امکان مدیریتکردن مودم به صورت محلی و راه دور پیکربندی بنر هشدار (اشاره شده در الزام FTA_TAB.1) پیکربندی مدت زمان ممکن برای غیرفعال بودن یک نشست پیش از قفل‌کردن یا خاتمه‌دادن به آن (برای الزامات FTA_SSL_EXT.1 و FTA_SSL.3) امکان به‌روزرسانی مودم و امکان تأیید به‌روزرسانی‌ها با استفاده از [انتخاب: امضای دیجیتال، مقایسه مقدار درهم‌سازی] پیش از نصبشدن به‌روزرسانی‌های مربوطه (مرتبط با الزامات FMT_MOF.1/ManualUpdate و FPT_TUD_EXT.1.) پیکربندی پارامترهای مرتبط با شکست احراز هویت برای الزام FIA_AFL.1 ] انتخاب: امکان شروعکردن یا خاتمه‌دادن به هر سرویس پیکربندی نحوه ذخیره‌سازی رکوردهای ممیزی (مثلاً تغییر محل ذخیره‌سازی به یک سرور خارجی syslog) مطابق با FIA_UIA_EXT.1 امکان فراهمکردن لیستی از سرویس‌ها که بدون نیاز به احراز هویت در مودم قابل ارائه خواهد بود. مدیریت کلیدهای رمزنگاری مدیریت توابع رمزنگاری پیکربندی حد آستانه برای ایجاد مجدد کلید در پروتکل SSH پیکربندی طول عمر برای IPSec SAs30 پیکربندی تعامل بین مؤلفه‌های مودم فعالسازی مجدد حساب سرپرست تنظیم زمان برای مهرهای زمانی امکان انجام پیکربندی‌های مرتبط با پروتکل NTP امکان تعیین trust store31 برای گواهینامه‌های X509.v3 و همچنین تعیین گواهینامه‌های مورد نظر به عنوان trust anchor امکان اضافهکردن گواهینامه‌های X509.v3 به trust store هیچ قابلیت دیگر [ نکات کاربردی: دقت شود که مورد آخر از موارد ذکر شده، انتخاب است. همانطور که واضح است هر یک از امکانات فوق دست کم مرتبط با یکی از الزامات ذکر شده در بخش‌های دیگر این سند است و همانطور که مشخص است در برخی موارد صریحاً به الزام یا الزامات مربوطه اشاره کرده‌ایم. مودم باید برای هر مورد، قابلیت(های) تعریف شده در الزام مربوطه را پیاده‌سازی کند. در مورد قابلیت‌های مربوط به x509 و IPsec تنها در صورتی که الزام مربوطه انتخاب شده است باید قابلیت ذکر شده پیاده‌سازی شود.
35 مدیریت نقش‌های امنیتی 1 (FMT_SMR.2.1)
مودم باید حداقل نقش امنیتی‌ زیر را فراهم کند: سرپرست امنیتی نکات کاربردی: مودم باید با امکان تعریف سرپرستان محلی و راه دور، امکان مدیریت مودم را فراهم کند. توجه شود که می‌توان انواع نقش سرپرست با دسترسی‌ها و قابلیت‌های مختلف تعریف کرد و لزوماً نیاز نیست یک نقش قادر به انجام تمام قابلیت‌های تعریف شده در FMT_SMF.1 باشد و یا قادر به مدیریت راه دور یا محلی باشد. برای مدیریت راه دور باید با رعایت الزامات FTP_ITC.1، FPT_ITT.1 و/یا FTP_TRP.1/Admin برقراری اتصال امن تضمین شود.
36 مدیریت نقش‌های امنیتی 2 (FMT_SMR.2.2)
مودم باید بتواند برای کاربران تعریف‌شده نقش تعیین کند.
37 مدیریت نقش‌های امنیتی 3 (FMT_SMR.2.3)
مودم باید از فراهم بودن نقش‌های زیر اطمینان حاصل کند: نقش سرپرست امنیتی برای اداره مودم به صورت محلی نقش سرپرست امنیتی برای مدیریت مودم از راه دور

  1. کلاس محافظت از محصول

این کلاس شامل چهار دسته الزام به ترتیب برای محافظت از داده‌های امنیتی ذخیره‌شده در مودم مانند کلیدهای رمزنگاری و پسوردها، انجام خودآزمایی خودکار برای کسب اطمینان از کارکرد صحیح توابع امنیتی، فراهمکردن رویه‌های قابل اعتماد برای انجام به‌روزرسانی و نیز تضمین درستی مهرهای زمانی برای ثبت رکوردهای ممیزی است.

  1. محافظت از داده‌های امنیتی

شماره الزام نام الزام
38 محافظت از کلیدهای رمزنگاری 1 (FPT_SKP_EXT.1.1)
مودم به هیچ وجه نباید اجازه خواندهشدن مقادیر کلیدهای از پیش به اشتراک گذاشته شده، کلیدهای متقارن و کلیدهای خصوصی را بدهد. نکات کاربردی: این داده‌ها باید تنها برای کارکردهای امنیتی مربوطه قابل دسترسی باشند و نیازی به دسترسی و نمایش آن‌ها در هر زمان دیگر نیست.
39 محافظت از گذرواژه سرپرست 1 (FPT_APW_EXT.1.1)
مودم نباید گذرواژه‌ها را به شکل متن ساده ذخیره کند.
40 محافظت از گذرواژه سرپرست 2 (FPT_APW_EXT.1.2)
مودم باید از خوانده شدن گذرواژه‌ها جلوگیری کند. نکات کاربردی: هدف از دو الزام اخیر این است که داده‌های خام مربوط به احراز هویت از طریق گذرواژه، به شکل واضح ذخیره نشوند و هیچ کاربر و سرپرست مودم نیز نتواند این گذرواژه‌ها را به صورت متن ساده از طریق واسط "عادی" بخواند. البته سرپرست مودم که تمام دسترسی‌ها را داشته باشد، می‌تواند گذرواژه‌ها را بخواند؛ اما به وی اعتماد می‌شود و فرض می‌گردد که وی این کار را نخواهد کرد.

  1. خودآزمایی خودکار عملکرهای امنیتی

برای شناسایی وقوع مشکل در سازوکارهای امنیتی، مودم باید از طریق خودآزمایی از صحت کارکرد آن‌ها اطمینان حاصل کند. میزان و حجم این خودآزمایی‌ها به تصمیم تولیدکننده مودم بستگی دارد؛ اما هر چه خودآزمایی‌های جامع‌تری انجام شوند، پلتفرم قابل اعتمادتری پدید خواهد آمد. همچنین شایان ذکر است که تعدادی الزام مبتنی بر انتخاب برای این مؤلفه در پیوست دو ارائه شده‌اند.

41 خودآزمایی خودکار 1 (FPT_TST_EXT.1)
مودم باید مجموعه‌ای از خودآزمایی‌های ]اختصاص: لیستی از خودآزمایی‌ها[ را در مواقع ]انتخاب: در مرحله راه‌اندازی اولیه (روشن شدن دستگاه)، به طور دوره‌ای در حین کارکرد دستگاه، در صورت درخواست کاربر مجاز، در شرایط ]اختصاص: شرایطی که باید در آن خودآمایی انجام شود[[ انجام دهد.

  1. به‌روزرسانی امن محصول

عدم موفقیت سرپرست مودم در تأیید به‌روزرسانی‌های سیستم ممکن است کل سیستم را در معرض خطر قرار دهد. برای اعتماد به منبع به‌روزرسانی، سیستم می‌تواند مجموعه‌ای از فرایندها و سازوکارهای مبتنی بر رمزنگاری را مورد استفاده قرار دهد. به طور مثال از طریق سازوکار امضای دیجیتال از هویت منبع به‌روزرسانی اطمینان حاصل کند. لازم به ذکر است که تعدادی الزام مبتنی بر انتخاب برای این خانواده در فصل 7 ارائه شده است.

42 به‌روزرسانی امن 1 (FPT_TUD_EXT.1.1)
مودم باید این امکان را به سرپرستان امنیتی خود بدهد که به نسخه فعلی (در حال استفاده) نرم‌افزار/میان‌افزار مودم و [انتخاب: جدیدترین نسخه نصبشده از نرم‌افزار/میان‌افزار روی مودم، هیچ نسخه دیگری از نرم‌افزار/میان‌افزار مودم] دسترسی داشته باشد. نکات کاربردی: منظور از الزام فوق این است که اگر امکان نصب ولی فعال‌سازی در یک زمان دیگر برای یک نسخه جدید از نرم‌افزار/میان‌افزار مودم وجود دارد، آنگاه باید هر دو گزینه‌ نسخه در حال استفاده و نیز جدیدترین نسخه نصب‌شده از نرم‌افزار/میان‌افزار برای سرپرست نمایش داده شود. در غیر این صورت تنها نسخه در حال استفاده نمایش داده شود.
43 به‌روزرسانی امن 2 (FPT_TUD_EXT.1.2)
مودم باید این امکان را برای سرپرستان امنیتی خود فراهم کند که به‌روزرسانی نرم‌افزار/میان‌افزار مودم را به صورت دستی انجام دهد و ]انتخاب: از جستجوی خودکار به‌روزرسانی‌ها پشتیبانی کند، از به‌روزرسانی خودکار پشتیبانی کند، از هیچ ساز وکار به‌روزرسانی دیگری پشتیبانی نکند[.
44 به‌روزرسانی امن 3(FPT_TUD_EXT.1.3)
مودم باید پیش از نصب به‌روزرسانی‌های نرم‌افزاری و میان‌افزاری، با استفاده از یک سازوکار مبتنی بر ]انتخاب: امضای دیجیتال، گواهینامه x509، درهم‌سازی[ ابزاری را برای احراز هویت به‌روزرسانی‌ها فراهم کند. نکات کاربردی: در صورت انتخاب سازوکار مبتنی بر گواهینامه‌های x509 الزام‌های FIA_X509_EXT.1/Rev و FIA_X509_EXT.2.1 نیز باید در خصوص بررسی و احراز هویت گواهینامه‌ها پیاده‌سازی شوند. الگوریتم امضای دیجیتال باید مطابق با مورد انتخاب‌شده در الزام FCS_COP.1/SigGen باشد. الگوریتم امضای دیجیتال علاوه بر حالتی که در سازوکار مبتنی بر گواهینامه‌های x509 استفاده می‌شود، به صورت یک مکانیزم واحد و همراه با الگوریتم GPG و یا با کلیدهای عمومی خام نیز می‌تواند استفاده شود. برای مکانیزم مبتنی بر درهم‌سازی، الگوریتم انتخاب‌شده باید مبتنی بر الزام FCS_COP.1/Hash باشد. در صورت استفاده از سازوکار مبتنی بر درهم‌سازی، به یک مکانیزم "مجوز‌دهی فعال" توسط سرپرست امنیتی مودم نیز نیاز خواهد بود. منظور از این مکانیزم مجوزدهی، تولید مقدار چکیده فایل به‌روزرسانی و مقایسه آن با مقدار چکیده ارسال شده است. مودم می‌تواند به هر نحوی که مناسب آن باشد این فرایند را به صورت دستی یا خودکار پیاده‌سازی کند. قابل ذکر است که فرایند ارسال مقدار چکیده به مودم نیز باید به طور کامل شرح داده شده و قابل اطمینان بودن این فرایند انتقال باید تضمین شود.

  1. مهرهای زمانی قابل اعتماد

45 مهر زمانی امن 1 (FPT_STM_EXT.1.1)
مودم باید قابلیت ارائه مهرهای زمانی قابل اطمینان برای استفاده خودش را داشته باشد.
46 مهر زمانی امن 2 (FPT_STM_EXT.1.2)
مودم باید [انتخاب: به سرپرست امنیتی اجازه دهد که زمان را تنظیم کند، زمان را با منابع خارجی NTP همگام سازد]. نکات کاربردی: مهرهای زمانی قابل اطمینان جهت استفاده در دیگر توابع امنیتی مودم، مورد نظر هستند؛ به عنوان مثال، برای ثبت زمان وقوع رخداد در رکوردهای ممیزی. این زمان می‌تواند به صورت دستی توسط سرپرست امنیتی تنظیم شود و یا با استفاده از یک یا چند منبع خارجی مانند سرور NTP تنظیم گردد. درصورت استفاده از سرور خارجی NTP الزام FCS_NTP_EXT.1 هم باید رعایت و اضافه شود.

  1. کلاس دسترسی به محصول

این کلاس به الزامات مرتبط با چگونگی مدیریت نشست‌های محلی و راه دور برقرار شده میان سرپرستان و مودم اختصاص دارد. مواردی چون بستن یک نشست بعد از یک مدت زمان معین از عدم فعالیت و نیز نمایش بنر هشدار در ابتدای هر نشست در این کلاس قرار می‌گیرند.

شماره الزام نام الزام
47 قفل‌کردن و خاتمه‌دادن به نشست‌ها 1 (FTA_SSL_EXT.1.1)
در مورد نشست‌های محلی، مودم باید پس از اتمام زمان غیرفعال بودن که توسط سرپرست مودم تعیین شده است، ]انتخاب: نشست را قفل کند: یعنی امکان دسترسی سرپرست به منوهای مختلف را قفل کرده و تنها گزینه "بازگشایی از حالت قفل" را به او نشان دهد. برای بازگشایی نیز سرپرست را مجبور به احراز هویت مجدد کند. نشست را به طور کامل خاتمه دهد. [
48 قفل‌کردن و خاتمه‌دادن به نشست‌ها 2 (FTA_SSL.3.1)
در مورد نشست‌های راه دور، در صورتی که نشست تعاملی برای مدت معینی غیرفعال باشد، مودم باید نشست تعاملی را خاتمه دهد. مدت زمان مجاز برای غیرفعال بودن توسط سرپرست مودم تعیین می‌شود.
49 قفل‌کردن و خاتمه‌دادن به نشست‌ها 3 (FTA_SSL.4.1)
مودم باید به سرپرست مودم اجازه دهد که نشست تعاملی خود را خاتمه دهد.
50 بنر هشدار (FTA_TAB.1.1)
قبل از برقراری نشست میان سرپرست اجرایی و مودم، مودم باید توصیه‌های مشخص‌شده توسط سرپرست امنیتی و همچنین تأییدیه استفاده از مودم را نشان دهد. نکات کاربردی: این الزام تنها در مورد نشست‌های تعاملی بین یک کاربر انسانی و مودم اعمال می‌شود. برای دیگر موجودیت‌های IT مانند اتصال اتوماتیک سرور خارجی syslog ازطریق IPSec نیازی به رعایت این الزام نیست.

  1. کلاس کانال‌ها/مسیرهای مورد اعتماد {#کلاس-کانال‌ها/مسیرهای-مورد-اعتماد}

الزامات این کلاس اختصاص به چگونگی برقراری یک کانال امن میان مودم و یک موجودیت خارجی مانند یک سرور خارجی syslog برای ارسال رکوردهای ممیزی دارد. این کانال امن هم باید داده‌های ارسالی را از شنود و تغییر حفظ کند و هم با فراهم کردن احراز هویت دوطرفه از حملاتی چون مرد-در-میانه جلوگیری کند. رسیدن به این هدف با استفاده از یکی از پنج پروتکل IPsec، SSH، TLS، DTLS و HTTPS فراهم می‌شود.

شماره الزام نام الزام
51 کانال امن/مودم با موجودیت دیگر 1 (FTP_ITC.1.1)
مودم باید بتواند کانال ارتباطی امنی را با استفاده از پروتکل(های) ]انتخاب: IPsec، SSH، TLS، DTLS، [HTTPS میان خود و دیگر موجودیت‌های IT معتبر شامل: سرور ممیزی، ]انتخاب: سرور احراز هویت، ]اختصاص: لیستی از سرورهای دیگر که نیاز به امنکردن کانال دارند[، هیچ سرور دیگر[ برقرار کند تا ضمن فراهم کردن احراز هویت دوطرفه، از داده‌های مورد تبادل در برابر تغییر و افشاء محافظت نموده و تغییرات را تشخیص دهد. تذکر: در صورت استفاده از هر یک از پروتکل‌های مذکور به عنوان پروتکل ارتباطی امن، لازم است از پیوست دو تمامی الزامات مربوط به آن پروتکل نیز تکمیل و به سند هدف امنیتی اضافه گردد. نکات کاربردی: این الزام تضمین می‌دهد که اطلاعات مورد تبادل میان تجهیز مربوطه و مودم در یک ارتباط راه دور در معرض افشا و تغییر قرار نخواهد گرفت. بسیار مهم است که چگونگی مدیریت کردن شرایطی که کانال مربوطه قطع می‌شود نیز شرح داده شود. باید تضمین داده شود که در صورت قطعشدن کانال تا برقراری مجدد کانال، هیچ داده‌ای تحت هیچ شرایطی روی مسیر عادی ارسال نخواهد شد.
52 کانال امن/مودم با موجودیت دیگر 2 (FTP_ITC.1.2)
مودم باید اجازه داشته باشد یا به دیگر موجودیت معتبر IT اجازه دهد تا پس از برقرای کانال امن میان آن‌ها، ارتباط را از طریق این کانال آغاز کنند.
53 کانال امن/مودم با موجودیت دیگر 3 (FTP_ITC.1.3)
مودم باید ارتباطات را از طریق کانال امن برای ]اختصاص: لیست سرویس‌هایی که مودم می‌تواند برای آن‌ها ارتباطات را آغاز کند[ شروع کند.
54 کانال امن/مودم با سرپرست 1 (FTP_TRP.1.1/Admin)
مودم باید بتواند کانال ارتباطی امنی را با استفاده از پروتکل(های) ]انتخاب: IPsec، SSH، TLS، DTLS، [HTTPS میان خود و یک سرپرست راه دور برقرار کند تا ضمن فراهمکردن احراز هویت دوطرفه، از داده‌های مورد تبادل در برابر تغییر و افشاء محافظت نموده و تغییرات را تشخیص دهد. نکات کاربردی: این الزام تضمین می‌دهد که اطلاعات حساس میان سرپرست و مودم در یک ارتباط راه دور در معرض افشا و تغییر قرار نخواهند گرفت.
55 کانال امن/مودم با سرپرست 2 (FTP_TRP.1.2/Admin)
مودم باید به سرپرست‌ راه دور مودم اجازه دهد تا ارتباطات را از طریق کانال امن ایجاد شده آغاز کند.
56 کانال امن/مودم با سرپرست 3 (FTP_TRP.1.3/Admin)
مودم باید استفاده از کانال امن را برای احراز هویت اولیه سرپرست و تمامی فعالیت‌های مدیریتی راه دور الزامی کند.

  1. الزامات تضمین امنیت (ASE_REQ_SAR) {#الزامات-تضمین-امنیت-(ase_req_sar)}

در قسمت اول این فصل با تشریح مفاهیم اولیه و مجموعه الزامات کارکردی امنیتی چگونگی التزام به این سند را بیان کردیم. به عبارتی دیگر هر مودمی که مدعی پیروی از این پروفایل حفاظتی است باید تضمین دهد که الزامات کارکردی امنیتی ذکرشده را رعایت و پیاده‌سازی کرده است. بدین منظور می‎‌بایست همراه با دستگاه مودم اسناد مربوط به چگونگی پیاده‌سازی این الزامات و راهنمای محصول نیز به ارزیاب ارائه شود. از این رو، ادامه این فصل، 6 کلاس از الزامات تضمین امنیت را بیان می‌کند که در قالب سند "هدف امنیتی" و مستند(ات) "راهنمای محصول" باید برآورده و ارائه شود. ارزیاب محترم با دریافت این اسناد راهنما، ارزیابی محصول و التزام آن به الزامات ذکر شده را بررسی می‌کند. به طور دقیق‌تر، الزامات این بخش از فراهم بودن مستندات مورد نیاز برای ارزیابی محصول اطمینان حاصل می‌کنند. لازم به ذکر است که در هر قسمت به اقدامات مورد نیازی که ارزیاب محترم باید انجام دهد نیز اشاره شده است.

جدول زیر کلاس‌های مربوطه و الزامات موجود در هر یک را به صورت تیتروار نشان می‌دهد. در ادامه این بخش هر کلاس به طور مختصر شرح داده شده است.

عنوان کلاس الزام توضیح
کلاس هدف امنیتی (محصول امنیتی مورد ارزیابی) Security Target (ASE) Conformance claims (ASE_CCL.1) ادعای التزام به پروفایل‌(های) حفاظتی
Extended components definition (ASE_ECD.1) تعریف مؤلفه‌‌های توسعه یافته
ST introduction (ASE_INT.1) معرفی محصول مورد ارزیابی
Security objectives for the operational environment (ASE_OBJ.1) اهداف امنیتی برای محیط عملیاتی
Security Problem Definition (ASE_SPD.1) تعریف مشکلات و تهدیدات امنیتی
Stated security requirements (ASE_REQ.1) الزامات امنیتی تبیین‌شده
TOE summary specification (ASE_TSS.1) خلاصه مشخصات محصول
کلاس توسعه Development (ADV) Basic functional specification (ADV_FSP.1) شرح پایه‌ای از مشخصات کارکردی محصول
کلاس اسناد راهنما Guidance Documents (AGD) Operational user guidance (AGD_OPE.1) راهنمای کاربر عملیاتی
Preparative procedures (AGD_PRE.1) راهنمای آماده‌سازی
کلاس پشتیبانی از چرخه حیات Life Cycle Support (ALC) Labelling of the TOE (ALC_CMC.1) برچسب‌گذاری محصول
TOE CM coverage (ALC_CMS.1) پوشش پیکربندی محصول
کلاس آزمون Tests (ATE) Independent testing – conformance (ATE_IND.1) آزمون مستقل-انطباق
کلاس ارزیابی آسیب‌پذیری Vulnerability Assessment (AVA) Vulnerability survey (AVA_VAN.1) تحلیل آسیب‌پذیری

  1. کلاس هدف امنیتی

الزامات موجود در این بخش عملاً فصل‌ها و بخش‌های مورد نیاز در سند "هدف امنیتی" را شرح می‌دهند. همچنان که پیش‌تر نیز گفته شده است، یکی از اسناد مهم همراه با مودم، سند "هدف امنیتی" است که به شرح محصول و چگونگی پیاده‌سازی الزامات ذکرشده در این پروفایل حفاظتی می‌پردازد و باید دست کم شامل فصل‌هایی مطابق با الزامات زیر باشد.

شماره الزام الزام شرح الزام
(1) ادعای التزام به پروفایل‌(های) حفاظتی (ASE_CCL.1) مطابق با این الزام می‌بایست لیست و ورژن پروفایل‌ یا پروفایل‌های حفاظتی که مودم ادعای التزام و پیاده‌سازی آن‌ها را دارد، ذکر شود.
(2) تعریف مؤلفه‌های توسعه یافته (ASE_ECD.1) در صورتی که علاوه بر الزامات ذکر شده در این پروفایل حفاظتی، الزامات بیشتری نیز بنا به قابلیت‌های مودم قابل بیان بوده و در مودم نیز پیاده‌سازی شده باشد، می‌توان آن‌ها را به صورت الزامات توسعهیافته در بخش "الزامات امنیتی تبیین شده" بیان کرد. اما باید در نظر داشت که این الزامات باید با خانواده مربوطه که توسعه داده می‌شود همخوانی داشته و مطابق با استانداردهای معیار مشترک در تعریف الزامات کارکردی-امنیتی باشند. مؤلفه‌های توسعه‌یافته باید شامل المان‌های هدفمند و قابل‌اندازه‌گیری باشد، طوری که انطباق و عدم انطباق با این المان‌ها، قابل‌ اثبات باشد (این بخش اختیاری بوده و جهت جلوگیری از مشکلات احتمالی در تعریف این الزامات، پیاده‌سازی آن توصیه نمی‌شود).
(3) معرفی مودم (ASE_INT.1) مطابق با این الزام می‌بایست مودم معرفی و مؤلفه‌‌ها و اجزای مختلف آن به همراه ویژگی‌ها، قابلیت‌ها و محدودیت‌هایش شرح داده شوند. معرفی مودم باید نحوه استفاده و ویژگی‌های اصلی مودم را بیان کند. این معرفی باید هر سخت‌افزار/نرم‌افزار/ ... غیر از مودم را که به وسیله مودم استفاده می‌شود، معرفی کند. این معرفی باید حوزه فیزیکی و منطقی کارکرد مودم را توصیف کند.
(4) اهداف امنیتی برای محیط عملیاتی (ASE_OBJ.1) مطابق با این الزام، اهداف امنیتی در نظر گرفته شده برای محیط عملیاتی بیان شوند (به اهداف امنیتی ذکر شده در این سند رجوع شود).
(5) تعریف مشکلات و تهدیدات امنیتی (ASE_SPD.1) مطابق با این الزام، تهدیدات امنیتی موجود باید بیان شوند (به تهدیدات امنیتی ذکر شده در این سند رجوع شود).
(6) الزامات امنیتی تبیین شده (ASE_REQ.1) مطابق با این سند مجموعه‌ای از الزامات برای مودم LTE ذکر شده است که برخی اجباری، برخی اختیاری و برخی وابسته به انتخاب انجام گرفته در الزامات دیگر بودند. لازم است تا در سند "هدف امنیتی" کلیه الزامات رعایت شده، مطابق با این سند شرح داده شوند.
(7) خلاصه مشخصات محصول (ASE_TSS.1) لازم است تا مودم با جزئیات کامل به تشریح چگونگی پیاده‌سازی الزامات ذکر شده بپردازد.
اقدامات ارزیاب
مؤلفه: (ASE_CCL.1E) شرح مؤلفه: ارزیاب باید تأیید کند که توضیحات ارائه شده کامل بوده و مشخصات پروفایل‌های حفاظتی ذکر شده کامل بوده و پروفایل‌ها وجود خارجی دارند. هدف امنیتی (ASE)
مؤلفه: (ASE_ECD.1E) شرح مؤلفه: ارزیاب باید تأیید کند که هیچ مؤلفه توسعه‌‌یافته‌ای به وسیله مؤلفه‌های موجود به صورت شفاف قابل بیان نیست و تعریف مؤلفه‌ توسعهیافته صحیح انجام شده است.
مؤلفه: (ASE_INT.1E) شرح مؤلفه: ارزیاب باید تأیید کند که اطلاعات مورد نیاز برای بخش معرفی محصول کامل بوده و زیربخش‌های آن با یکدیگر سازگار هستند.
مؤلفه: (ASE_OBJ.1E) شرح مؤلفه: ارزیاب باید تأیید کند که اطلاعات ارائه شده برای اهداف امنیتی کامل است.
مؤلفه: (ASE_SPD.1E) شرح مؤلفه: ارزیاب باید تأیید کند که لیست و شرح ارائه شده برای تهدیدات امنیتی کامل است.
مؤلفه: (ASE_REQ.1E) شرح مؤلفه: ارزیاب باید تأیید کند که لیست و شرح ارائه شده برای الزامات کامل است و هیچ الزام اجباری یا انتخابی مربوطه‌ای نادیده گرفته نشده است.
مؤلفه: (ASE_TSS.1E) شرح مؤلفه: ارزیاب باید تأیید کند اطلاعات ارائه شده برای خلاصه مشخصات مودم تمامی الزامات ذکر شده را پیاده‌سازی کرده و از جامعیت و شفافیت کامل در شرح مکانیزم برخوردار است.

  1. کلاس توسعه

شماره الزام الزام شرح الزام
(8) شرح پایه‌ای از مشخصات کارکردی محصول (ADV_FSP.1) مطابق با این الزام می‌بایست واسط‌ها و اینترفیس‌های تعریف‌شده برای پیاده‌سازی توابع و کارکردهای امنیتی مورد نیاز به طور مختصر تشریح شوند. پارامترهای مرتبط با هر اینترفیس باید بیان شود. ارتباط هر اینترفیس با کارکرد(های) امنیتی مربوطه باید بیان شود. نیاز به تشریح جامعی از این اینترفیس‌ها نبوده و بیشتر منظور اینترفیس‌هایی است که کاربر با آن‌ها سر و کار دارد و برای باقی اینترفیس‌ها (مانند اینترفیس‌های متصل به محیط عملیاتی) یک شرح مختصر کافی است. نیاز به سند جداگانه‌ای برای این الزام نبوده و توضیحات مورد نیاز را می‌توان در مستندات راهنما و بخش خلاصه مشخصات مودم از سند هدف امنیتی گنجاند.
اقدامات ارزیاب
مؤلفه: (ADV_FSP.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که اطلاعات ارائه شده تمام موارد خواسته شده را برآورده می‌کند. شرح پایه‌ای از مشخصات کارکردی محصول (ADV_FSP)
مؤلفه: (ADV_FSP.1.2E) شرح مؤلفه: ارزیاب باید مشخص کند که اینترفیس‌های تعریفشده نمونه کامل و دقیقی از کارکردهای امنیتی مورد نیاز را فراهم می‌کنند.

  1. کلاس اسناد راهنما

مستند(ات) راهنما همراه با سند هدف امنیتی ارائه خواهند شد. این اسناد باید مشخص کنند که هر نوع کاربر در مودم چگونه می‌تواند از مودم استفاده کرده و وظایف خود را انجام دهد. به عبارت دیگر چگونه می‌تواند از امکانات امنیتی مربوط به نقش خود استفاده کند. اگر محصول قابلیت پشتیبانی از محیط‌های عملیاتی مختلف با ویژگی‌های متفاوت را دارد، برای هر محیط عملیاتی باید یک راهنمای جداگانه ارائه شود.

هر سند راهنما باید شامل موارد زیر باشد:

  • دستورالعمل نصب موفقیت‌آمیز مودم در محیط عملیاتی
  • دستورالعمل‌های لازم برای مدیریت امنیت مودم به عنوان یک مودم تنها یا به عنوان بخشی از یک محیط عملیاتی بزرگتر
  • دستورالعمل‌ها و توصیه‌های مفید در اتخاذ استراتژی‌های امنیتی در شرایط مختلف با توجه به امکانات مودم
  • دستورالعمل‌های مربوطه برای استفاده از هر یک از توابع و کارکردهای امنیتی
شماره الزام الزام شرح الزام
(9) راهنمای کاربر عملیاتی (AGD_OPE.1) این سند باید همراه با مودم ارائه شود و یا محتوای مورد نیاز آن در اسناد دیگر گنجانده شود و یا به صورت آنلاین در اینترنت در دسترس باشد. این سند باید برای هر نقش کاربری، کارکردها و واسط‌های در دسترس، به خصوص تمام پارامترهای امنیتی تحت کنترل را توصیف نموده و مقادیر امن را توصیه کند. باید برای هر نقش کاربری، رویدادهای امنیتی به کارکردهای در دسترس و قابل انجام توسط کاربر مرتبط شوند. سند راهنمای کاربرد عملیاتی باید تمام مدهای عملیاتی مودم (مدهایی شامل شکست عملیات یا خطای عملیات)، آثار آن‌ها و مستلزم بودنشان برای حفظ عملیات در حالت امن را مشخص نماید. این سند باید برای هر نقش کاربری، معیارهای امنیتی را که توسط کاربر باید تبعیت شوند توصیف کند تا اهداف امنیتی محیط عملیاتی که در سند هدف امنیتی شرح داده شده‌اند، کاملاً اجرا گردند.
(10) راهنمای آمادهسازی (AGD_PRE.1) این سند باید همراه با مودم ارائه شود. مستندات آماده‌سازی باید تمام مراحل لازم برای نصب امن مودم و آماده‌سازی امن محیط عملیاتی را مطابق با اهداف امنیتی در نظر گرفته شده برای محیط عملیاتی که در سند هدف امنیتی ذکر شده‌اند، شرح دهند.
اقدامات ارزیاب
مؤلفه: (AGD_OPE.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که اطلاعات ارائه شده در سند راهنمای کاربرد عملیاتی تمام محتوای مورد نیاز و ذکر شده در الزام را برآورده می‌کند. اسناد راهنما (AGD)
مؤلفه: (AGD_PRE.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که اطلاعات ارائه شده در سند راهنمای آماده‌سازی تمام محتوای مورد نیاز و ذکر شده در الزام را برآورده می‌کند.
مؤلفه: (AGD_PRE.1.2E) شرح مؤلفه: ارزیاب باید رویه‌های آماده‌سازی شرح داده شده در سند را بکار ببرد تا تأیید کند که مودم می‌تواند به صورت امن برای عمل نمودن آماده شود.

  1. کلاس پشتیبانی از چرخه حیات

در سطح اطمینانی که در این پروفایل حفاظتی ارائه شده است (EAL1)، کلاس پشتیبانی از چرخه حیات به ویژگی‌هایی از چرخه حیات محدود می‌گردد که توسط کاربر نهایی قابل مشاهده باشد. این به آن معنی نیست که نحوه عمل توسعه‌دهنده نقش کمرنگی در قابل اعتماد بودن مودم دارد، بلکه در این سطح اطمینان تنها به این اطلاعات نیاز است.

شماره الزام الزام شرح الزام
(11) برچسب گذاری محصول ALC_CMC.1 توسعه‌دهنده باید مودم و مرجع مودم را ارائه کند. به عبارتی دیگر مودم باید با یک مرجع یکتا برچسب زده شود. این برچسب می‌تواند یک برچسب کاغذی، نرم‌افزاری و یا حک‌شده روی مودم باشد که آن را به صورت یک مودم یکتا در میان محصولات شرکت مربوطه معرفی می‌کند.
(12) پوشش پیکربندی محصول ALC_CMS.1 توسعه‌دهنده باید لیست موارد قابل پیکربندی مودم را در اسناد راهنما ارائه کند. لیست پیکربندی باید موارد قابل پیکربندی را به صورت یکتا معرفی کند.
اقدامات ارزیاب
مؤلفه: (ALC_CMC.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که مودم برچسب یکتا دارد. پشتیبانی از چرخه حیات (ALC)
مؤلفه: (ALC_CMS.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که اطلاعات ارائه‌شده تمام محتوای مورد نیاز را برآورده می‌کند.

  1. کلاس آزمون

آزمون مودم توسط ارزیاب و برای بررسی و تست کارکردهای سیستم و همچنین تست وجود حفره‌های امنیتی که در محصولات مشابه شناسایی شده است، در نظر گرفته شده است. آزمون کارکردهای سیستم از طریق خانواده ATE_IND و آزمون نوع دوم از طریق خانواده AVA_VAN صورت می‌گیرد که این مورد در زیربخش بعد شرح داده شده است. در این سطح از ارزیابی (سطح EAL1) آزمون بر اساس کارکردهایی که برای مودم در نظر گرفته شده و واسط‌هایی که بر اساس اطلاعات طراحی در اختیار ارزیاب قرار می‌گیرد، انجام می‌شود. نتایج آزمون و تحلیل آسیب‌پذیری باید توسط ارزیاب در گزارش آزمون لحاظ شوند.

آزمون مستقل-انطباق: "آزمون مستقل-انطباق" برای تأیید کارکردهای مودم که در بخش "خلاصه مشخصات محصول" از سند هدف امنیتی و مستندات "راهنما" ارائه شده، صورت می‌گیرد. هدف اصلی از انجام آزمون اطمینان از برآورده شدن الزامات کارکردی مشخص شده در سند هدف امنیتی است. ارزیاب باید در سند "گزارش آزمون"، طرح آزمون و نتایج آن را مستند کند.

شماره الزام الزام شرح الزام
(13) ATE_IND.1 توسعه‌دهنده باید مودم را برای آزمودن ارائه کند و محصول باید مناسب برای آزمون باشد.
اقدامات ارزیاب
مؤلفه: (ATE_IND.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که با توجه به اسناد و محتوای ارائه شده، محصول مناسب برای ارزیابی می‌باشد یا خیر. آزمون مستقل (ATE_IND)
مؤلفه: (ATE_IND.1.2E) شرح مؤلفه: ارزیاب باید زیرمجموعه‌ای از توابع امنیتی مودم را تست کند تا تأیید شود که توابع امنیتی مودم به صورت مشخص‌شده عمل می‌کنند.

  1. کلاس ارزیابی آسیب پذیری

این کلاس به شناسایی آسیب‌پذیری‌های قابل بهره‌برداری که در مودم ممکن است وجود داشته باشد، می‌پردازد.

شماره الزام الزام شرح الزام
(14) AVA_VAN.1 توسعه‌دهنده باید مودم را برای ارزیابی آسیب‌پذیری ارائه کند و مودم باید مناسب برای آزمون باشد.
اقدامات ارزیاب
آسیب‌پذیری (AVA_VAN) مؤلفه: (AVA_VAN.1.1E) شرح مؤلفه: ارزیاب باید تأیید کند که با توجه به اسناد و محتوای ارائه‌شده، مودم مناسب برای ارزیابی آسیب‌پذیری است یا خیر.
مؤلفه: (AVA_VAN.1.2E) شرح مؤلفه: ارزیاب باید برای شناسایی آسیب‌پذیری‌های بالقوه و شناخته‌شده در مودم LTE، در منابع عمومی جستجو انجام دهد.
شماره مؤلفه: (AVA_VAN.1.3E) شرح مؤلفه: ارزیاب باید بر اساس آسیب‌پذیری‌های بالقوه شناساییشده، آزمون نفوذ انجام دهد تا مقاومت مودم را در برابر حملات با توان پایه که توسط مهاجمان صورت می‌گیرند، مشخص کند.

  1. پیوست یک: الزامات اختیاری

این پیوست از الزاماتی تشکیل شده است که می‌توان آن‌ها را در هدف امنیتی گنجاند، اما برای انطباق با این پروفایل حفاظتی ضروری نیستند. اگر مودم هر کدام از این الزامات اختیاری را پشتیبانی می‌کند، توصیه می‌شود که قابلیت‌های کارکردی مرتبط به سند هدف امنیتی اضافه شود. نویسندگان سند هدف امنیتی آزاد هستند که هیچ، برخی یا تمامی الزامات مطرح شده در این بخش را انتخاب کنند.

  1. کلاس ثبت رکوردهای ممیزی از الزامات اختیاری

مشابه با بخش الزامات اجباری در فصل 5، جدول زیر لیست رویدادهای قابل ممیزی برای الزامات اختیاری را به تفکیک الزام و نیز اطلاعات اضافی مورد نیاز برای هر رویداد را نشان می‌دهد. برای هر کدام از الزامات اختیاری که پیاده‌سازی شود باید حداقل اطلاعات ذکر شده در جدول ‏6-1 برای آن الزام به صورت رکورد ممیزی ثبت شود.

جدول ‏6-1 لیست رویدادهای قابل ممیزی به تفکیک کارکردهای امنیتی اختیاری

اطلاعات اضافی مورد نیاز رویداد قابل ممیزی کارکرد امنیتی مورد نیاز
× × FAU_STG.1
× × FAU_STG_EXT.2/LocSpace
× اخطار کم بودن فضای ذخیره‌سازی برای رویدادهای قابل ممیزی FAU_STG.3/LocSpace
دلیل شکست شکست در ایجاد یک نشست DTLS FCS_DTLSC_EXT.2 ( با احراز هویتDTLS Client)
هویت منبع حملهکننده (مثال: آدرس (IP تشخیص حملات replay attack
دلیل شکست شکست در ایجاد یک نشست DTLS FCS_DTLSS_EXT.2 ( با احراز هویتDTLS Server)
هویت منبع حمله‌کننده (مثال: آدرس (IP تشخیص حملات replay attack
× × FCS_TLSC_EXT.2
دلیل شکست شکست در احراز هویت کاربر FCS_TLSS_EXT.2
× شروع و توقف هر سرویس FMT_MOF.1/Services
× رویداد مدیریت کلیدهای رمزنگاری FMT_MTD.1/CryptoKeys

در ادامه الزامات اختیاری مختص به کلاس ثبت رکوردهای ممیزی بیان شده است.

نام الزام شماره الزام
محافظت از داده‌های ممیزی ذخیره شده 1 (FAU_STG.1.1) 1
مودم باید از پاک شدن غیرمجاز داده‌های ممیزی جلوگیری کند.
محافظت از داده‌های ممیزی ذخیره شده 2 (FAU_STG.1.2) 2
مودم باید از دستکاری غیرمجاز داده‌های ممیزی جلوگیری کند.
شمارش رکوردهای از دسترفته در فضای ذخیره‌سازی محلی (FAU_STG_EXT.2/LocSpace) 3
مودم در صورت پر شدن حافظه محلی، باید اطلاعات مربوط به تعداد رکوردهای ممیزی ]نتخاب: از دست رفته، بازنویسی شده، ]اختصاص: سایر اطلاعات[[ را ارائه کند.
اقدام در صورت از دسترفتن رکوردهای ممیزی روی حافظه محلی (FAU_STG_EXT.3.1/LocSpace) 4
در صورتی که حجم داده‌های ممیزی از ظرفیت ذخیره‌سازی محلی داده‌های ممیزی فراتر رود/سرریز کند، مودم باید با تولید اخطار، سرپرست را آگاه کند.

  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 موجود در گواهینامه با شناسه‌های مورد انتظار برای کاربر تطابق ندارند، سرور نباید با کاربر کانال امن تشکیل دهد.

  1. کلاس مدیریت امنیت

شماره الزام نام الزام
15 مدیریت کارکرد امنیتی 1/سرویس‌ها (FMT_MOF.1/Services)
مودم باید امکان فعال/غیرفعال کردن توابع و سرویس‌ها را به مدیران امنیتی محدود کند.
16 مدیریت دسترسی به دادهها 1/کلیدهای رمزنگاری ( FMT_MTD.1/CryptoKeys)
مودم باید توانایی مدیریت کردن کلیدهای رمزنگاری را به سرپرست امنیتی محدود کند. نکته کاربردی: این گزینه زمانی باید انتخاب گردد که سرپرست امنیتی امکان مدیریت کلیدهای رمزنگاری (برای مثال؛ اصلاح، حذف، تولید/واردکردن) را داشته باشد. این الزام مدیریت کلیدهای رمزنگاری را به سرپرست‌های امنیتی محدود می‌کند.

  1. پیوست دو: الزامات انتخابی

این پیوست به بیان الزامات مبتنی بر انتخاب می‌پردازد. پیاده‌سازی الزامات این بخش بسته به انتخاب‌های انجام شده در فصل 5 است. به طور مثال در صورت انتخاب پروتکل IPSEC برای امن کردن کانال ارتباطی میان مودم و موجودیت‌های خارجی مانند سرور خارجی ذخیره رکوردهای ممیزی، باید الزامات مربوط به IPSEC از این بخش پیاده‌سازی شود.

  1. کلاس ثبت رکوردهای ممیزی از الزامات اختیاری

مشابه با بخش الزامات اجباری در فصل 5، جدول زیر لیست رویدادهای قابل ممیزی برای الزامات انتخابی را به تفکیک الزام و نیز اطلاعات اضافی مورد نیاز برای هر رویداد را نشان می‌دهد. برای هر کدام از الزامات انتخابی که پیاده‌سازی شود باید حداقل اطلاعات ذکر شده در جدول ‏7-1 برای آن الزام به صورت رکورد ممیزی ثبت شود.

جدول ‏7-1 لیست رویدادهای قابل ممیزی به تفکیک کارکردهای امنیتی انتخابی

اطلاعات اضافی مورد نیاز رویداد قابل ممیزی کارکرد امنیتی
دلیل شکست شکست در ایجاد یک نشست DTLS FCS_DTLSC_EXT.1
دلیل شکست شکست در ایجاد یک نشست DTLS FCS_DTLSS_EXT.1
هویت منبع حملهکننده )مثال؛ آدرس IP آن( تشخیص حملات replay attack
دلیل شکست شکست در ایجاد یک نشست HTTPS FCS_HTTPS_EXT.1
دلیل شکست شکست در ایجاد یک نشست HTTPS FCS_IPSEC_EXT.1
دلیل شکست شکست در ایجاد یک نشست SSH FCS_SSHC_EXT.1
دلیل شکست شکست در ایجاد یک نشست SSH FCS_SSHS_EXT.1
دلیل شکست شکست در ایجاد یک نشست TLS FCS_TLSC_EXT.1
دلیل شکست شکست در ایجاد یک نشست TLS FCS_TLSS_EXT.1
دلیل شکست تلاش‌های ناموفق برای اعتبارسنجی یک گواهینامه FIA_X509_EXT.1/Rev
× × FIA_X509_EXT.2
× × FIA_X509_EXT.3
دلیل شکست (شامل شناسه گواهینامه نامعتبر) شکست در خودآزمایی FPT_TST_EXT.2
دلیل شکست (شامل شناسه گواهینامه نامعتبر) شکست در به‌روزرسانی FPT_TUD_EXT.2
× فعال‌سازی و غیر فعال‌سازی جستجوی خودکار به‌روزرسانی‌ها یا به‌روزرسانی‌های خودکار FMT_MOF.1/AutoUpdate
× اصلاح یا تغییر رفتار؛ انتقال داده‌های ممیزی به یک موجودیت IT خارجی، کنترل داده ممیزی، کارکرد مورد نظر وقتی که فضای محلی ذخیره‌سازی ممیزی پر می‌شود. FMT_MOF.1/Functions

نکات کاربردی: رویداد ممیزی " FIA_X509_EXT.1/Rev" در صورتی رخ می‌دهد که مودم نتواند از موارد زیر اطمینان حاصل کند و گواهینامه‌ها را تأیید کند:

  • وجود افزونه basicConstraints و تأیید اینکه پرچم CA برای تمام گواهینامه‌های CA به حالت TRUE تنظیم شده است.
  • تأیید امضای دیجیتال CA سلسله مراتبی مورد اعتماد
  • خواندن و دسترسی به CRL یا دسترسی به سرور OCSP

اگر هر یک از این موارد وجود نداشته باشند، باید یک رویداد ممیزی با نتیجه شکست را در سوابق ممیزی ثبت کرد.

  1. کلاس پشتیبانی از رمزنگاری

    1. الزامات پروتکل DTLS

پیش از بیان الزامات DTLS برای جلوگیری از تکرار لازم است به لیست مجموعه‌های رمزنگاری قابل استفاده برای TLS و DTLS اشاره کنیم. این لیست در جدول ‏7-2 آورده شده و در خلال الزامات TLS و DTLS به آن مراجعه خواهیم کرد.

جدول ‏7-2 لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS

TLS_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268 TLS_RSA_WITH_AES_256_CBC_SHA مطابق باRFC 3268 TLS_DHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268 TLS_DHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492 TLS_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246 TLS_RSA_WITH_AES_256_CBC_ SHA256 مطابق با RFC 5246 TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 مطابق با RFC 5246 TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 مطابق با RFC 5246 TLS_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5288 TLS_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5288 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5288 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5288 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 مطابق با RFC 5289 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 مطابق با RFC 5289

در ادامه الزامات پروتکل DTLS بیان شده است. قابل ذکر است که در نسخه جدید از پروفایل حفاظتی برای محصولات شبکه، پیاده‌سازی قابلیت احراز هویت دوطرفه در DTLS و TLS به عنوان یک الزام اختیاری در نظر گرفته شده است. لذا این روند در این پروفایل حفاظتی نیز رعایت شده و در این قسمت الزامات این پروتکل‌ها بدون احراز هویت دوطرفه را بیان کرده‌ایم و در صورت تمایل به پیاده‌سازی احراز هویت دوطرفه باید الزامات اختیاری ذکر شده در آن بخش نیز علاوه بر الزامات این بخش رعایت شود.

قابل ذکر است که با توجه به کارکرد این پروتکل‌ها به فرم client/server، الزامات مربوطه نیز برای هر یک از کاربر (client) یا سرور (server) جداگانه بیان شده است که هریک از دو طرف مودم و موجودیت دوم مانند سرور خارجی رکوردهای ممیزی می‌توانند نقش کاربر DTLS یا سرورDTLS را بگیرند.

نام الزام شماره الزام
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (1) (FCS_DTLSC_EXT.1.1) 1
مودم باید ]انتخاب: 6347) (RFC 1.2 DTLS، 4347) (RFC 1.0 [DTLS را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی کند: ]انتخاب: یکی از مجموعه‌های رمزنگاری لیست‌شده در لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS [
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (2) (FCS_DTLSC_EXT.1.2) 2
مودم باید مطابقت شناسه32 ارائه شده با شناسه مرجع را با توجه به بخش 6 از 6125 RFC، تأیید کند. نکات کاربردی: قوانین مربوط به تأیید شناسه در بخش 6 از RFC 6125 توضیح داده شده‌اند.
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (3) (FCS_DTLSC_EXT.1.3) 3
مودم کلاینت باید کانال امن را فقط در صورت معتبر بودن گواهینامه سرور برقرار سازد. اگر گواهینامه سرور نامعتبر به نظر رسید، مودم باید ]انتخاب: ارتباط را برقرار نسازد، برای برقراری ارتباط درخواست مجوز بدهد، ]اختصاص: دیگر اقدامات.[[.
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (4) (FCS_DTLSC_EXT.1.4) 4
مودم باید ]انتخاب: Extension Curves Elliptic Supported را ارائه نکند، Extension Curves Elliptic Supported را به همراه curve NIST‌های ]نتخابsecp521r1: secp384r1, secp256r1, [ و هیچ منحنی دیگری[ در پیام Client Hello ارائه دهد. نکات کاربردی: اگر در الزام "الزامات پروتکل Client DTLS بدون احراز هویت (1)" مجموعه‌های رمز دارای منحنی‌های بیضوی انتخاب گردند، در این الزام باید یک یا چند مورد از منحنی‌ها انتخاب شود. اگر در الزام مربوطه هیچکدام از مجموعه‌های رمز دارای منحنی‌های بیضوی انتخاب نگردد، عبارت Extension” Curves Elliptic Supported را ارائه نکند" باید انتخاب شود. این الزام مجموعه‌های رمز بیضوی مجاز برای احراز هویت و توافق کلید را به منحنی‌های NIST از الزام‌های FCS_COP.1/SigGen و FCS_CKM.1 و FCS_CKM.2 محدود می‌سازد. این افزونه برای کلاینت‌هایی که از مجموعه‌های رمز بیضوی پشتیبانی می‌کنند، الزامی است.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (1) (FCS_DTLSS_EXT.1.1) 5
مودم باید ]انتخاب: 6347) (RFC 1.2 DTLS، 4347) (RFC 1.0 [DTLS را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی کند: ]انتخاب: یکی از مجموعه‌های رمزنگاری لیست‌شده در لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS [
الزامات پروتکل DTLS Server بدون احراز هویت دوطرفه (2) (FCS_DTLSS_EXT.1.2) 6
مودم نباید برای کلاینت‌هایی که درخواست هیچ دارند، ارتباطات را ایجاد کند.
الزامات پروتکل DTLS Server بدون احراز هویت دوطرفه (3) (FCS_DTLSS_EXT.1.3) 7
مودم نباید در صورت شکست خوردن اعتبارسنجی Client DTLS، تلاش دست‌تکانی ارتباط را پیش ببرد. نکته کاربردی: فرآیند اعتبارسنجی کردن Client DTLS در بخش 4.2.1 از 6347) (RFC v1.2 DTLS و 4347) (RFC v1.0 DTLS تشریح شده است. مودم با نقش سرور، DTLS Client را در طول فرایند برقراری اتصال (Handshaking) و پیش از ارسال پیام ServerHello اعتبارسنجی می‌کند. سرور بعد از دریافت پیام ClientHello، یک پیام HelloVerifyRequest را همراه با یک کوکی به کلاینت ارسال می‌کند. این کوکی درواقع یک پیام امضاء شده با استفاده از توابع چکیده‌ساز معرفی شده در الزام FCS_COP.1/KeyedHash است. در ادامه کلاینت دوباره یک پیام ClientHello دیگر را به همراه کوکی امضاء‌شده‌ ذکر‌شده ارسال می‌کند. سرور در صورت تأیید کردن این کوکی ارسالی از جانب کلاینت، مطمئن می‌شود که کلاینت از آدرس IP جعلی استفاده نکرده است.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (4) (FCS_DTLSS_EXT.1.4) 8
مودم باید استقرار کلید را با استفاده از ]انتخاب: RSA با اندازه کلید ]انتخاب: 2048 بیت، 3072 بیت، 4096 بیت[، دیفی-هلمن با پارامترهایی با سایز ]2048 بیت، 3072 بیت، 4096 بیت، 6144 بیت، 8192 بیت[، دیفی-هلمن با گروه‌های ]انتخاب: ffdhe2048، ffdhe3072، ffdhe4096، ffdhe6144، ffdhe8192، هیچ گروه دیگر[، منحنی‌های ECDHE ]انتخاب: secp521r1، secp384r1، secp256r1 [ و هیچ منحنی دیگری[ انجام دهد.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (5) (FCS_DTLSS_EXT.1.5) 9
مودم باید هنگامی که یک پیام حاوی MAC نامعتبر دریافت می‌کند، ]انتخاب: به نشست DTLS خاتمه دهد، بیصدا رکورد را دور بریزد.[ نکته کاربردی: کد MAC در طی فاز دستتکانی DTLS و برای حفاظت از جامعیت پیام‌ها استفاده می‌شود. اگر تأیید MAC شکست بخورد، نشست باید خاتمه یابد یا رکورد دریافت‌شده، بی‌صدا دور انداخته شود.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (6) (FCS_DTLSS_EXT.1.6) 10
مودم با نقش سرور باید پیام‌های بازارسال شده (مربوط به replay attack) برای: رکوردهای DTLS که قبلا دریافت شده‌اند (یعنی شماره ترتیب آن تکراری است). رکوردهای DTLS بسیار قدیمی که شماره ترتیب آن‌ها در sliding receive window قرار نمی‌گیرد. را به صورت خاموش نادیده بگیرد. نکات کاربردی: حمله replay attack در RFC 6347 برای DTLS 1.2 و RFC 4347 برای DTLS 1.0 شرح داده شده است.

  1. الزامات پروتکل HTTPS

شماره الزام نام الزام
11 الزامات پروتکل HTTPS (1) (FCS_HTTPS_EXT.1)
مودم باید پروتکل HTTPS را مطابق با 2818 RFC اجرا کند. نکته کاربردی: نویسنده سند هدف امنیتی باید اطلاعات کافی را فراهم آورد و مشخص کند که پیاده‌سازی این پروتکل مطابق استانداردهای تعریف شده است.
12 الزامات پروتکل HTTPS (2) (FCS_HTTPS_EXT.2)
مودم باید پروتکل HTTPS را با استفاده از TLS اجرا کند.
13 الزامات پروتکل HTTPS (3) (FCS_HTTPS_EXT.3)
درصورتیکه گواهینامه همتا ارائه شده باشد و نامعتبر باشد، مودم باید ]انتخاب: اتصال را برقرار نکند، برای برقراری اتصال درخواست مجوز کند، هیچ اقدام دیگری انجام ندهد.[ نکته کاربردی: اگر در الزام FTP_ITC.1 یا FTP_TRP.1/Admin پروتکل HTTPS انتخاب گردد، آنگاه اعتبارسنجی گواهینامه از طریق بررسی و تأیید فیلدهای شناسه گواهینامه، مسیر گواهینامه33 ، تاریخ انقضاء و وضعیت ابطال34 آن مطابق با 5280 RFC تعیین می‌گردد. همچنین نحوه اعتبارسنجی گواهینامه بر اساس قواعد تعریف شده در الزام FIA_X509_EXT.1/Rev انجام می‌شود.

  1. الزامات پروتکل IPSEC

شماره الزام نام الزام
14 الزامات پروتکل IPSEC (1) (FCS_IPSEC_EXT.1.1)
مودم باید پروتکل IPSEC را بر اساس آنچه در 4301 RFC مشخص شده است، پیاده‌سازی کند. نکات کاربردی: بر اساس 4301 RFC برای پیاده‌سازی IPSEC جهت محافظت از ترافیک IP از یک پایگاه داده امنیتی با نام SPD (Security Policy Database) استفاده می‌شود. با استفاده از SPD می‌توان تعیین کرد که بسته‌های IP چگونه باید مدیریت شوند. در این زمینه به سه قاعده زیر اشاره شده است: PROTECT: محافظت از بسته‌ها با استفاده از رمزنگاری BYPASS: عدم استفاده از سرویس‌های IPSEC (عدم استفاده از رمزنگاری) DISCARD: دور ریختن بسته‌ها پایگاه داده مذکور را می‌توان به روش‌های مختلفی پیاده‌سازی کرد که از آن جمله می‌توان به پیاده‌سازی لیست‌های کنترل دسترسی35 در مسیریاب‌ها، مجموعه قوانین فیلترینگ بسته (packet filtering rule set) در فایروال‌ها و مواردی از این دست اشاره کرد. صرف نظر از روش پیاده‌سازی این پایگاه داده باید توجه داشت که مشابه با مثال‌های ذکر شده، قواعد (ruleها) باید ترتیب اعمال داشته و بسته‌های IP قابل تفکیک باشند. حتی می‌توان یک پایگاه داده برای هر واسط شبکه داشت اما الزامی در این زمینه وجود ندارد.
15 الزامات پروتکل IPSEC (2) (FCS_IPSEC_EXT.1.2)
مودم باید یک قاعده پیش‌فرض (default rule) در SPD داشته باشد که با بسته‌های تطابق نیافته (match نشده) با قواعد دیگر تطابق یافته و کارکرد این قاعده نیز دور ریختن بسته‌های مذکور باشد.
16 الزامات پروتکل IPSEC (3) (FCS_IPSEC_EXT.1.3)
مودم باید ]انتخاب: مد انتقال (Transport)، مد تونل [(Tunnel) را پیاده‌سازی کند. نکته کاربردی: نویسنده سند هدف امنیتی باید مدهای عملیاتی پشتیبانی‌شده برای IPSEC را مشخص کند. به عبارتی دیگر حداقل یک یا هر دو مد ذکر شده را پیاده‌سازی کند.
17 الزامات پروتکل IPSEC (4) (FCS_IPSEC_EXT.1.4)
مودم باید بر اساس آنچه در 4303 RFC گفته شده است، فریمورک ESP از پروتکل IPSEC را با استفاده از الگوریتم‌های رمزنگاری ]انتخاب: AES-CBC-128، AES-CBC-192، AES-CBC-256 )تشریح شده در 3602 (RFC، هیچ الگوریتم دیگری[ به همراه یک HMAC مبتنی بر الگوریتم درهم‌سازی امن (SHA) ]انتخاب: HMAC-SHA-1، HMAC-SHA-256، HMAC-SHA-384، HMAC-SHA-512، هیچ الگوریتم دیگری[ و ]انتخاب: AES-GCM-128، AES-GCM-192، AES-GCM-256 )تشریح شده در 4106 (RFC، هیچ الگوریتم دیگری[ پیاده‌سازی کند. نکته کاربردی: وقتی که الگوریتم AES-CBC انتخاب گردد، حداقل یک HMAC مبتنی بر SHA نیز باید انتخاب شود. اگر یک AES-GCM انتخاب گردد، نیاز نیست که HMAC انتخاب شود، زیرا AES-GCM محرمانگی و جامعیت را فراهم می‌کند. در صورتی که برای IPSEC با توجه به خروجی مورد انتظار، نوع خاصی از HMAC مبتنی بر SHA )مثال: a truncated version of HMAC) انتخاب گردد، در خلاصه مشخصات مودم باید معرفی گردد.
18 الزامات پروتکل IPSEC (5) (FCS_IPSEC_EXT.1.5)
مودم باید یکی از این پروتکل‌ها را به کار گیرد: ]انتخاب: IKEv1، با استفاده از مد اصلی برای انجام تبادلات فاز اول، طبق RFCهای 4109، 2409، 2408، 2407، ]انتخاب: هیچ RFC دیگری برای شماره توالی‌های بسطیافته36 ، RFC4304 برای شماره توالی‌های بسطیافته[ و ]انتخاب: هیچ RFC دیگری برای توابع درهم‌ساز، 4868 RFC برای توابع درهم‌ساز[ IKEv2، مطابق با تعریف 5996 RFC و ]انتخاب: بدون پشتیبانی از NAT Traversal، با پشتیبانی اجباری از Traversal NAT چنان که در بخش 2.23 از 5996 RFC تشریح شده است[ و ]انتخاب: هیچ RFC دیگر برای توابع درهم‌ساز، 4868 RFC برای توابع درهم‌ساز[ نکات کاربردی: اگر مودم برای دو پروتکل IKEv1 یا IKEv2 از الگوریتم درهم‌ساز SHA-2 استفاده کند، نویسنده سند هدف امنیتی باید 4868 RFC را انتخاب کند. اگر مودم از HMAC‌های مبتنی بر SHA، کوتاه ‌شده مطابق با 4868 RFC استفاده کند، باید در خلاصه مشخصات مودم، مشخص گردد.
19 الزامات پروتکل IPSEC (6) (FCS_IPSEC_EXT.1.6)
مودم باید اطمینان حاصل کند که برای پیلود37 رمز شده در پروتکل ]انتخاب: IKEv1،[IKEv2 از الگوریتم‌های رمزنگاری ]انتخاب: AES-CBC-128، AES-CBC-192، AES-CBC-256 (تشریح شده در 3602 RFC)، AES-GCM-128، AES-GCM-192، AES-GCM-256 (تشریح شده در 5282 RFC [( استفاده می‌شود. نکته کاربردی: از آنجایی که هیچ RFC وجود ندارد که AES-GCM را برای IKEv1 تعریف کرده باشد، AES-GCM-128، AES-GCM-192 و AES-GCM-256 تنها در صورتی انتخاب می‌شوند که IKEv2 نیز انتخاب شده باشد.
20 الزامات پروتکل IPSEC (7) (FCS_IPSEC_EXT.1.7)
مودم باید اطمینان حاصل کند که ]انتخاب: سرپرست مودم می‌تواند طول عمر SA38 فاز اول IKEv1 را بر اساس ]انتخاب: تعداد بایت منتقل شده؛ مدت زمان سپری شده از زمان برقراری آن که این طول عمر آستانه را می‌توان در بازه ]اختصاص: اعداد صحیح شامل [24 ساعت قرار داد[ پیکربندی کند. سرپرست مودم می‌تواند طول عمر SA IKEv2 را بر اساس ]انتخاب: تعداد بایت منتقل شده؛ مدت زمان سپری شده از زمان برقراری آن که این طول عمر آستانه را می‌توان در بازه ]اختصاص: اعداد صحیح شامل [24 ساعت قرار داد[ پیکربندی کند. [ نکات کاربردی: تعیین طول عمر برای SAهای فاز اول به مدیر مودم محول شده و باید قابل پیکربندی باشد. این مقدار به طور پیش‌فرض معمولاً 24 ساعت است. هر چه این مقدار کمتر باشد به لحاظ امنیتی بهتر است.
21 الزامات پروتکل IPSEC (8) (FCS_IPSEC_EXT.1.8)
مودم باید اطمینان حاصل کند که ]انتخاب: سرپرست مودم می‌تواند طول عمر SA فاز دوم IKEv1 را بر اساس ]انتخاب: تعداد بایت منتقل شده؛ مدت زمان برقراری نشست که مقدار طول عمر آن را می‌توان در بازه ] اختصاص: بازه اعداد صحیح شامل 8[ ساعت قرار داد[ پیکربندی کند. ، سرپرست مودم می‌تواند طول عمر SA IKEv2 Child را بر اساس ]انتخاب: تعداد بایت منتقل شده؛ مدت زمان برقراری نشست که مقدار طول عمر آن را می‌توان در بازه ]اختصاص: بازه اعداد صحیح شامل 8[ ساعت قرار داد[ پیکربندی کند. [ نکات کاربردی: تعیین طول عمر برای SAهای فاز اول به مدیر مودم محول شده و باید قابل پیکربندی باشد. این مقدار به طور پیش‌فرض معمولاً 8 ساعت است. هر چه این مقدار کمتر باشد، به لحاظ امنیتی بهتر است.
22 الزامات پروتکل IPSEC (9) (FCS_IPSEC_EXT.1.9)
مودم باید مقدار x را که در تبادل کلید DiffieHellman IKE استفاده می‌شود (g ^ x mod p)، با استفاده از تولیدکننده بیت تصادفی که در الزام "تولید بیت تصادفی 1" مشخص شده است تولید کند و اندازه آن نیز دست کم ]اختصاص: تعداد بیتی که حداقل دو برابر قدرت امنیتی گروه Diffie-Hellman مذاکره شده باشد[ بیت باشد. نکات کاربردی: برای مشاهده قدرت امنیتی گروه‌های مختلف دیفی-هلمن به جدول 2 از سند NIST SP 800-57 با عنوان “Recommendation for Key Management –Part 1: General” مراجعه کنید.
23 الزامات پروتکل IPSEC (10) (FCS_IPSEC_EXT.1.10)
مودم باید تک‌شمارهای مورد استفاده در تبادلات ]انتخاب: IKEv1، [IKEv2 را با طول ]انتخاب: ]اختصاص: قدرت امنیتی مربوط به گروه Diffie-Hellman مذاکره شده[، حداقل 128 بیت و نیز حداقل نصف اندازه خروجی تابع درهم‌سازی شبه ‌تصادفی39 مذاکره شده [ تولید کند. نکته کاربردی: اگر IKEv2 انتخاب شده باشد )همان‌طور که در RFC5996 اجباری شده است(، نویسنده سند هدف امنیتی باید دومین گزینه را برای طول تک‌شمار انتخاب کند. نویسنده سند هدف امنیتی مجاز است هر یک از گزینه‌ها را برای IKEv1 انتخاب کند.
24 الزامات پروتکل IPSEC (11) (FCS_IPSEC_EXT.1.11)
مودم باید اطمینان حاصل کند که پروتکل‌های IKE، گروه‌های دیفی-هلمن ]انتخاب: 14 MODP) (2048-bit و 19 (256-bit Random ECP)، 20 (384-bit Random ECP)، 24 (2048-bit MODP with 256-bit POS) را پیاده‌سازی می‌کنند. نکته کاربردی: قسمت "انتخاب" در این الزام جهت مشخص کردن این موضوع که گروه‌های DH اضافه پشتیبانی شده است، بکار می‌رود. این الزام برای هر دو IKEv1 و IKEv2 اعمال می‌گردد.
25 الزامات پروتکل IPSEC (12) (FCS_IPSEC_EXT.1.12)
مودم باید به صورت پیش‌فرض بتواند اطمینان حاصل کند که قدرت الگوریتم متقارنی (از نظر تعداد بیت‌های کلید) که برای حفاظت از اتصال ]انتخاب: فاز 1 IKEv1، IKE_SA [IKEv2 مذاکره شده است، بیشتر یا مساوی قدرت الگوریتم متقارنی (از نظر تعداد بیت‌های کلید) که برای حفاظت از اتصال ]انتخاب: فاز 2 IKEv1، CHILD_SA [IKEv2 مذاکره شده است، باشد.
26 الزامات پروتکل IPSEC (13) (FCS_IPSEC_EXT.1.13)
مودم باید اطمینان حاصل کند که همه پروتکل‌های IKE احراز هویت همتا را با استفاده از ]انتخاب: RSA، [ECDSA که از گواهینامه‌های X.509v3 مطابق با RFC4945 و ]انتخاب: کلیدهای پیش اشتراکی، هیچ روش دیگری[ استفاده می‌کند، انجام می‌دهند. نکات کاربردی: برای انطباق با این پروفایل حفاظتی، استفاده از حداقل یک روش احراز هویت همتا مبتنی بر کلید عمومی الزامی است. خلاصه مشخصات مودم باید تشریح کند که چگونه الگوریتم‌ها مورد استفاده قرار می‌گیرند. برای مثال 2409 RFC سه روش احراز هویت با استفاده از کلید عمومی را مشخص می‌کند، هر کدام که استفاده می‌شود، باید در خلاصه مشخصات مودم ذکر گردد.
27 الزامات پروتکل IPSEC (14) (FCS_IPSEC_EXT.1.14)
مودم باید کانال امن را فقط در صورتی که شناسه موجود در گواهینامه دریافتی با شناسه مرجع پیکربندی شده انطباق داشته باشد، برقرار کند. شناسه مرجع و ارائه شده از انواع زیر می‌توانند باشند: ]انتخاب: آدرس IP، FQDN، FQDN کاربر، [DN (Distinguished Name) و ]انتخاب: هیچ نوع شناسه مرجع دیگری، ]انتخاب: دیگر انواع شناسه مرجع پشتیبانی شده[[. 
  4. ### **الزامات پروتکل SSH** {#الزامات-پروتکل-ssh}
شماره الزام نام الزام
28 الزامات پروتکل Client SSH (1) (FCS_SSHC_EXT.1.1)
مودم باید پروتکل SSH را مطابق با RFC‌های 4251، 4252، 4253، 4254، ]انتخاب: 4256، 4344، 5647، 5656، 6187، 6668، 8268، 8308 section 3.1، [8332 پیاده‌سازی کند. برای راهنمایی نویسنده محترم سند "هدف امنیتی" لیست زیر برای بخش انتخاب از این الزام ارائه شده است. RFC 4256 در صورت فراهم بودن keyboard-interactive authentication RFC 4344 در صورت فراهم بودن مد AES-128-CTR یا AES-256-CTR RFC 5647 در صورت فراهم بودن AEAD_AES_128_GCM یا AEAD_AES_256_GCM RFC 5656 در صورت فراهم بودن رمزنگاری elliptical curve RFC 6187 در صورت فراهم بودن گواهینامه X.509 برای الگوریتم‌های مبتنی بر کلید عمومی RFC 6668 در صورت فراهم بودن الگوریتم‌های HMAC-SHA-2 RFC 8268 در صورت فراهم بودن گروه‌های FFC DH به همراه SHA-2 RFC 8308 Section 3.1 در صورت انتخاب RFC 8332 RFC 8332 در صورت فراهم بودن SHA-2 به همراه ssh-rsa برای الگوریتم‌های کلید عمومی
29 الزامات پروتکل SSH Client (2) (FCS_SSHC_EXT.1.2)
مودم باید اطمینان حاصل کند که در پیاده‌سازی پروتکل SSH، روش‌های احراز هویت مقابل مطابق با آنچه در 4252 RFC توضیح داده ‌شده است، پشتیبانی می‌شوند: احراز هویت مبتنی بر کلید عمومی، ]انتخاب: احراز هویت مبتنی بر گذرواژه، هیچ روش دیگری[.
30 الزامات پروتکل SSH Client (3) (FCS_SSHC_EXT.1.3)
همان‌طور که در 4253 RFC توضیح داده ‌شده است، مودم باید اطمینان حاصل کند که بسته‌های دارای بایت‌های بیشتر از ]اختصاص: تعداد بایت‌ها[ در یک اتصال SSH، کنار گذاشته شوند. نکات کاربردی: 4253 RFC امکان پذیرش "بسته‌های بزرگ" را فراهم می‌کند، با این اخطار که بسته‌ها باید "طول معقولی" داشته باشند یا اینکه کنار گذاشته می‌شوند. توصیه می‌شود این اختصاص توسط نویسنده هدف امنیتی با در نظر گرفتن بیشترین اندازۀ بستۀ قابل پذیرش پر شود تا به این وسیله "طول معقول" برای مودم تعریف شود.
31 الزامات پروتکل SSH Client (4) (FCS_SSHC_EXT.1.4)
مودم باید اطمینان حاصل کند که در پیاده‌سازی پروتکل انتقال SSH، از الگوریتم‌های رمزنگاری ]انتخاب: AES128-CBC، AES-256-CBC، AES128-CTR، AES256-CTR، AEAD_AES_128_GCM، [AEAD_AES_256_GCM استفاده می‌شود و سایر الگوریتم‌های رمزنگاری رد می‌شوند. نکات کاربردی: 5647 RFC استفاده از الگوریتم‌های AEAD_AES_128_GCM و AEAD_AES_256_GCM را در SSH مشخص می‌کند. چنان که در این RFC مطرح شده است، در صورتی می‌توان از دو الگوریتم مذکور استفاده کرد که همین الگوریتم‌های برای MAC نیز انتخاب گردند.
32 الزامات پروتکل SSH Client (5) (FCS_SSHC_EXT.1.5)
مودم باید اطمینان حاصل کند که در پیاده‌سازی مکانیزم احراز هویت مبتنی بر کلید عمومی از ]انتخاب: ecdsa-sha2-nistp256، [ssh-rsa و ]انتخاب: ecdsa-sha2-nistp384، ecdsa-sha2-nistp521، x509v3-ecdsa-sha2-nistp256، x509v3-ecdsa-sha2-nistp384، x509v3-ecdsa- sha2-nistp521، هیچ الگوریتم کلید عمومی دیگری[ به عنوان الگوریتم)های( کلید عمومی خود استفاده کند و همه الگوریتم‌های دیگر را رد کند (استفاده نکند).
33 الزامات پروتکل SSH Client (6) (FCS_SSHC_EXT.1.6)
مودم باید اطمینان حاصل کند که در پیاده‌سازی پروتکل انتقال SSH از ]انتخاب: hmac-sha1، hmac-sha1-96، hmac-sha2-256، hmac-sha2-512 [ و ]انتخاب: AEAD_AES_128_GCM، AEAD_AES_256_GCM، هیچ الگوریتم MAC دیگری[ به عنوان الگوریتم‌(های) MAC برای تأمین صحت داده استفاده می‌شود و سایر الگوریتم‌های MAC استفاده نمی‌شوند. نکات کاربردی: 5647 RFC استفاده از الگوریتم‌های AEAD_AES_128_GCM و AEAD_AES_256_GCM را در SSH مشخص می‌کند. چنانکه در این RFC مطرح شده است، در صورتی می‌توان از دو الگوریتم مذکور استفاده کرد که همین الگوریتم‌های برای MAC نیز انتخاب گردند. 6668 RFC استفاده از sha2 را در SSH مشخص می‌کند.
34 الزامات پروتکل SSH Client (7) (FCS_SSHC_EXT.1.7)
مودم باید اطمینان حاصل کند که ]انتخاب: .diffie-hellman-group14-sha1 [ecdh-sha2- nistp256 و ]انتخاب: ecdh-sha2-nistp384، ecdh-sha2-nistp521، هیچ روش دیگری[ تنها روش‌های مجاز تبادل کلید هستند که برای پروتکل SSH به کار می‌روند.
35 الزامات پروتکل SSH Client (8) (FCS_SSHC_EXT.1.8)
مودم باید اطمینان پیدا کند که در یک ارتباط SSH، کلیدهای نشست یکسانی برای حد آستانه (منظور از حد آستانه یعنی طول نشست بیشتر از یک ساعت نباشد و حجم داده مخابره شده بیشتر از 1 گیگابایت نباشد) استفاده می‌گردد. در صورت پر شدن حد آستانه، تولید مجدد کلید باید صورت بگیرد. نکات کاربردی: این الزام حد آستانه‌هایی را برای حداکثر زمانی که کلید(های) نشست می‌تواند استفاده گردد و حداکثر مقدار دادهای که می‌تواند با یک سری کلید نشست انتقال یابد، مشخص می‌کند. هر دو حد آستانه باید پیاده‌سازی گردد و یک مجددسازی کلید نیز وقتی هر کدام از دو مورد مذکور سر برسد باید بکار گرفته شود. برای محاسبه حداکثر داده انتقالی، داده‌هایی که به مودم وارد و از مودم خارج می‌شوند باید محاسبه گردد. مجددسازی کلید باید روی تمام کلیدهای نشست (رمزنگاری، حفاظت از جامعیت) برای ترافیک ورودی و خروجی اعمال گردد. مودم همچنین می‌تواند مقادیری کمتر از مقادیر حد آستانه ذکر شده در این الزام را پیاده‌سازی کند. سند راهنمای مودم یا بخش خلاصه مشخصات مودم، باید نحوه پیکربندی این مقادیر و نحوه سر رسیدن آن‌ها و همچنین چگونگی امکان تعریف مقادیر کمتر از حد آستانه را تشریح کند.
36 الزامات پروتکل SSH Client (9) (FCS_SSHC_EXT.1.9)
مودم باید اطمینان حاصل کند که کلاینت SSH، سرور SSH را با استفاده از یک پایگاه داده محلی که نام هر میزبان را با کلید عمومی متناظر آن مرتبط می‌کند و یا ]انتخاب: فهرستی از مراجع صدور گواهی مطمئن، هیچ روش دیگری[ )تشریح شده در RFC 4251 بخش (4.1 احراز هویت می‌کند. نکات کاربردی: تنها در صورتی می‌توان گزینه "فهرستی از مراجع صدور گواهی مطمئن" را انتخاب کرد که x509v3-ecdsa-sha2-nistp256، x509v3-ecdsa-sha2-nistp384 یا x509v3-ecdsa-sha2-nistp521 در FCS_SSHC_EXT.1.5 انتخاب شده باشد.
37 الزامات پروتکل Server SSH (1) (FCS_SSHS_EXT.1.1)
مودم باید پروتکل SSH را مطابق با RFC‌های 4251، 4252، 4253، 4254، ]انتخاب:4256، 4344، 5647، 5656، 6187، 6668، 8268، 8308 section 3.1، [8332 پیاده‌سازی کند. برای راهنمایی نویسنده محترم سند "هدف امنیتی" لیست زیر برای بخش انتخاب از این الزام ارائه شده است. RFC 4256 در صورت فراهم بودن keyboard-interactive authentication RFC 4344 در صورت فراهم بودن مدAES-128-CTR یا AES-256-CTR RFC 5647 در صورت فراهم بودن AEAD_AES_128_GCM یا AEAD_AES_256_GCM RFC 5656 در صورت فراهم بودن رمزنگاریelliptical curve RFC 6187 در صورت فراهم بودن گواهینامه X.509 برای الگوریتم‌های مبتنی بر کلید عمومی RFC 6668 در صورت فراهم بودن الگوریتم‌های HMAC-SHA-2 RFC 8268 در صورت فراهم بودن گروه‌هایFFC DH به همراه SHA-2 RFC 8308 Section 3.1 در صورت انتخاب RFC 8332 RFC 8332 در صورت فراهم بودن SHA-2 به همراه SSH-RSA برای الگوریتم‌های کلید عمومی
38 الزامات پروتکل Server SSH (2) (FCS_SSHS_EXT.1.2)
مودم باید اطمینان حاصل کند که در پیاده‌سازی پروتکل SSH، همان‌طور که در 4252 RFC توضیح داده ‌شده است، روش‌های احراز هویت مقابل پشتیبانی می‌شوند: احراز هویت مبتنی بر کلید عمومی، احراز هویت مبتنی بر گذرواژه.
39 الزامات پروتکل Server SSH (3) (FCS_SSHS_EXT.1.3)
همان‌طور که در 4253 RFC توضیح داده ‌شده است، مودم باید اطمینان حاصل کند که بسته‌های دارای بایت‌های بیشتر از ]اختصاص: تعداد بایت‌ها[ در یک اتصال SSH، کنار گذاشته شوند. نکات کاربردی: 4253 RFC امکان پذیرش "بسته‌های بزرگ" را فراهم می‌کند، با این اخطار که بسته‌ها باید "طول معقولی" داشته باشند یا اینکه کنار گذاشته می‌شوند. توصیه می‌شود این اختصاص توسط نویسنده هدف امنیتی با در نظر گرفتن بیشترین اندازۀ بستۀ قابل پذیرش پر شود تا به این وسیله "طول معقول" برای مودم تعریف شود.
40 الزامات پروتکل Server SSH (4) (FCS_SSHS_EXT.1.4)
مودم باید اطمینان حاصل کند که در پیاده‌سازی پروتکل انتقال SSH، از الگوریتم‌های رمزنگاری ]انتخاب: AES128-CBC، AES-256-CBC، AES128-CTR، AES256-CTR، AEAD_AES_128_GCM، [AEAD_AES_256_GCM استفاده می‌شود و سایر الگوریتم‌های رمزنگاری رد می‌شوند. نکات کاربردی: 5647 RFC استفاده از الگوریتم‌های AEAD_AES_128_GCM و AEAD_AES_256_GCM را در SSH مشخص می‌کند. چنانکه در این RFC مطرح شده است، در صورتی می‌توان از دو الگوریتم مذکور استفاده کرد که همین الگوریتم‌ها برای MAC نیز انتخاب گردند.
41 الزامات پروتکل Server SSH (5) (FCS_SSHS_EXT.1.5)
مودم باید اطمینان حاصل کند که در پیاده‌سازی مکانیزم احراز هویت مبتنی بر کلید عمومی از ]انتخاب: ecdsa-sha2-nistp256، [ssh-rsa و ]انتخاب: ecdsa-sha2-nistp384، ecdsa-sha2-nistp521، x509v3-ecdsa-sha2-nistp256، x509v3-ecdsa-sha2-nistp384، x509v3-ecdsa- sha2-nistp521، هیچ الگوریتم کلید عمومی دیگری[ به عنوان الگوریتم)های( کلید عمومی خود استفاده کند و همه الگوریتم‌های دیگر را رد کند (استفاده نکند).
42 الزامات پروتکل Server SSH (6) (FCS_SSHS_EXT.1.6)
مودم باید اطمینان حاصل کند که در پیاده‌سازی پروتکل انتقال SSH از ]انتخاب: hmac-sha1، hmac-sha1-96، hmac-sha2-256، hmac-sha2-512 [ و ]انتخاب: AEAD_AES_128_GCM، AEAD_AES_256_GCM، هیچ الگوریتم MAC دیگری[ به عنوان الگوریتم‌(های) MAC برای تأمین صحت داده استفاده می‌شود و سایر الگوریتم‌های MAC استفاده نمی‌شوند. نکات کاربردی: 5647 RFC استفاده از الگوریتم‌های AEAD_AES_128_GCM و AEAD_AES_256_GCM را در SSH مشخص می‌کند. چنانکه در این RFC مطرح شده است، در صورتی می‌توان از دو الگوریتم مذکور استفاده کرد که همین الگوریتم‌ها برای MAC نیز انتخاب گردند. 6668 RFC استفاده از sha2 را در SSH مشخص می‌کند.
43 الزامات پروتکل Server SSH (7) (FCS_SSHS_EXT.1.7)
مودم باید اطمینان حاصل کند که ]انتخاب: diffie-hellman-group14-sha1، [ecdh-sha2- nistp256 و ]انتخاب: ecdh-sha2-nistp384، ecdh-sha2-nistp521، هیچ روش دیگری[ تنها روش‌های مجاز تبادل کلید هستند که برای پروتکل SSH به کار می‌روند.
44 الزامات پروتکلServer SSH (8) (FCS_SSHS_EXT.1.8)
مودم باید اطمینان پیدا کند که در یک ارتباط SSH، کلیدهای نشست یکسانی برای حد آستانه (منظور از حد آستانه یعنی طول نشست بیشتر از یک ساعت نباشد و حجم داده مخابره شده بیشتر از 1 گیگابایت نباشد) استفاده می‌گردد. در صورت پر شدن حد آستانه، تولید مجدد کلید باید صورت بگیرد. نکات کاربردی: این الزام حد آستانه‌هایی را برای حداکثر زمانی که کلید(های) نشست می‌تواند استفاده گردد و حداکثر مقدار دادهایی که می‌تواند با یک سری کلید نشست انتقال یابد مشخص می‌کند. هر دو حد آستانه باید پیاده‌سازی گردد و یک مجددسازی کلید نیز وقتی هر کدام از دو مورد مذکور سر برسد باید بکار گرفته شود. برای محاسبه حداکثر داده انتقالی، داده‌هایی که به مودم وارد و از مودم خارج می‌شوند باید محاسبه گردد. مجددسازی کلید باید روی تمام کلیدهای نشست (رمزنگاری، حفاظت از جامعیت) برای ترافیک ورودی و خروجی اعمال گردد. مودم همچنین می‌تواند مقادیری کمتر از مقادیر حد آستانه ذکر شده در این الزام را پیاده‌سازی کند. سند راهنمای مودم یا بخش خلاصه مشخصات مودم، باید نحوه پیکربندی این مقادیر و نحوه سر رسیدن آن‌ها و همچنین چگونگی امکان تعریف مقادیر کمتر از حد آستانه را تشریح کند. 
  5. ### **الزامات پروتکل TLS** {#الزامات-پروتکل-tls}

شایان ذکر است که در نسخه جدید از پروفایل حفاظتی برای محصولات شبکه، پیاده‌سازی قابلیت احراز هویت دوطرفه در TLS به عنوان یک الزام اختیاری در نظر گرفته شده است. لذا این روند در این پروفایل حفاظتی نیز رعایت شده و در این قسمت الزامات این پروتکل‌ بدون احراز هویت دوطرفه را بیان کرده‌ایم و در صورت تمایل به پیاده‌سازی احراز هویت دوطرفه باید الزامات اختیاری ذکرشده در آن بخش نیز علاوه بر الزامات این بخش رعایت شود.

قابل ذکر است که با توجه به کارکرد این پروتکل به فرم client/server، الزامات مربوطه نیز برای هر یک از کاربر (client) یا سرور (server) جداگانه بیان شده است که هر یک از دو طرف مودم و موجودیت دوم مانند سرور خارجی رکوردهای ممیزی می‌توانند نقش کاربر TLS یا سرور TLS را بگیرند.

شماره الزام نام الزام
45 الزامات پروتکل TLS Client بدون احراز هویت دوطرفه (1) (FCS_TLSC_EXT.1.1)
مودم باید ]انتخاب: 5246) (RFC 1.2 TLS، 4346) (RFC 1.1 [TLS را پیاده‌سازی کند و از دیگر نسخه‌های TLS و SSL استفاده نکند. همچنین TLS را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی کند: ]انتخاب: یکی از مجموعه‌های رمزنگاری لیست شده در "لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS" [
46 الزامات پروتکل TLS Client بدون احراز هویت دوطرفه (2) (FCS_TLSC_EXT.1.2)
مودم باید مطابقت شناسه40 ارائه شده با شناسه مرجع را با توجه به بخش 6 از 6125 RFC، تأیید کند. نکات کاربردی: قوانین مربوط به تأیید شناسه در بخش 6 از RFC 6125 توضیح داده شده‌اند.
47 الزامات پروتکل TLS Client بدون احراز هویت دوطرفه (3) (FCS_TLSC_EXT.1.3)
مودم باید کانال امن را فقط در صورت معتبر بودن گواهینامه سرور برقرار سازد. اگر گواهینامه سرور نامعتبر به نظر رسید، مودم باید ]انتخاب: ارتباط را برقرار نسازد، برای برقراری ارتباط درخواست مجوز بدهد، ]اختصاص: دیگر اقدامات.[[.
48 الزامات پروتکل TLS Client بدون احراز هویت دوطرفه (4) (FCS_TLSC_EXT.1.4)
مودم باید ]انتخاب: Extension Curves Elliptic Supported را ارائه نکند، Extension Curves Elliptic Supported را به همراه curve NIST‌های ]انتخاب: secp521r1 secp384r1, secp256r1, [ و هیچ منحنی دیگری[ در پیام Client Hello ارائه دهد. نکات کاربردی: اگر در الزام "الزامات پروتکل Client TLS بدون احراز هویت (1)" مجموعه‌های رمز دارای منحنی‌های بیضوی انتخاب گردند، در این الزام باید یک یا چند مورد از منحنی‌ها انتخاب شود. اگر در الزام مربوطه هیچکدام از مجموعه‌های رمز دارای منحنی‌های بیضوی انتخاب نگردد، عبارت Extension” Curves Elliptic Supported را ارائه نکند" باید انتخاب شود. این الزام مجموعه‌های رمز بیضوی مجاز برای احراز هویت و توافق کلید را به منحنی‌های NIST از الزام‌های FCS_COP.1/SigGen و FCS_CKM.1 و FCS_CKM.2 محدود می‌سازد. این افزونه برای کلاینت‌هایی که از مجموعه‌های رمز بیضوی پشتیبانی می‌کنند الزامی است.
49 الزامات پروتکل TLS Server بدون احراز هویت دوطرفه (1) (FCS_TLSS_EXT.1.1)
مودم باید ]انتخاب: 5246) (RFC 1.2 TLS، 4346) (RFC 1.1 [TLS را پیاده‌سازی کند و از دیگر نسخه‌های TLS و SSL استفاده نکند. همچنین TLS را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی کند: ]انتخاب: یکی از مجموعه‌های رمزنگاری لیست شده در "لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS" [
50 الزامات پروتکل TLS Server بدون احراز هویت دوطرفه (2) (FCS_TLSS_EXT.1.2)
مودم باید برای کلاینت‌های دارای درخواست 2.0 SSL، 3.0 SSL، 1.0 TLS و ]انتخاب: 1.1 TLS، 1.2 TLS، هیچ موردی[، اتصال را ایجاد نکند. نکات کاربردی: تمامی نسخه‌های SSL و v1.0 TLS رد می‌شوند. هر نسخه‌ای از TLS که در الزام "الزامات پروتکل Server TLS بدون احراز هویت دوطرفه (1) انتخاب نگردد، باید در بخش انتخاب فوق، انتخاب شود.
51 الزامات پروتکل TLS Server بدون احراز هویت دوطرفه (3) (FCS_TLSS_EXT.1.3)
مودم باید استقرار کلید را با استفاده از ]انتخاب: RSA با اندازه کلید ]انتخاب: 2048 بیت، 3072 بیت، 4096 بیت[، دیفی-هلمن با پارامترهایی با سایز ]2048 بیت، 3072 بیت، 4096 بیت، 6144 بیت، 8192 بیت[، دیفی-هلمن با گروه‌های ]انتخاب: ffdhe2048، ffdhe3072، ffdhe4096، ffdhe6144، ffdhe8192، هیچ گروه دیگر[، منحنی‌های ECDHE ]انتخابsecp521r1: secp384r1, secp256r1, [ و هیچ منحنی دیگری[ انجام دهد.

  1. کلاس شناسایی و احراز هویت

شماره الزام نام الزام
52 الزامات گواهینامه‌های X.509/ تأیید گواهینامه (1) (FIA_X509_EXT.1.1/Rev)
مودم باید گواهینامه‌ها را بر اساس قوانین زیر تأیید کند: بر اساس 5280 RFC برای تأیید گواهینامه و مسیر آن که از حداقل طول مسیر سه گواهینامه پشتیبانی می‌کند. مسیر گواهینامه باید به یک گواهینامه CA امن ختم شود. مودم باید برای تأیید مسیر گواهینامه اطمینان حاصل کند که افزونه basicConstraints وجود دارد و پرچم CA برای تمام گواهینامه‌های CA به حالت “True” تنظیم شده است. مودم باید وضعیت فسخ گواهینامه را با استفاده از ]انتخاب: پروتکل OCSP مشخص شده در 6960 RFC، لیست فسخ گواهینامه (CRL) مشخص شده در 5280 RFC بخش 6.3، لیست فسخ گواهینامه (CRL) مشخص شده در 5759 RFC بخش 5، هیچ روش فسخ[ تأیید کند. مودم باید فیلد extendedKeyUsage را بر اساس قوانین زیر تأیید کند: گواهینامه‌های مورد استفاده برای تأیید به‌روزرسانی‌های امن و اعتبارسنجی صحت کدهای اجرایی، باید دارای هدف "Signing Purpose Code" (id-kp3 باOID 1.3.6.1.5.5.7.3.3) در فیلد extendedKeyUsage باشند. گواهینامه‌‌های سرور ارائه شده برای TLS باید هدف Authentication” “Server id-kp1) با 1.3.6.1.5.5.7.3.1 (OID در فیلد extendedKeyUsage خود داشته باشند. گواهینامه‌های کلاینت ارائه شده برای TLS باید هدف Authentication” “Client id-kp1) با 1.3.6.1.5.5.7.3.2 (OID در فیلد extendedKeyUsage خود داشته باشند. گواهینامه‌های OCSP مورد استفاده برای پاسخ‌های OCSP باید هدف Signing” “OCSP id-kp9) با (OID1.3.6.1.5.5.7.3.9 در فیلد extendedKeyUsage خود داشته باشند.
53 الزامات گواهینامه‌های X.509/ تأیید گواهینامه (2) (FIA_X509_EXT.1.2/Rev)
مودم تنها در صورتی که افزونه مربوط به basicConstraints از پیش تنظیم شده باشد و پرچم CA به حالت “TRUE” تنظیم شده باشد یک گواهینامه را به عنوان گواهینامه CA می‌پذیرد.
54 الزامات گواهینامه‌های X.509/ احراز هویت (1) (FIA_X509_EXT.2.1)
مودم باید جهت پشتیبانی از احراز هویت در ]انتخاب: SSH، HTTPS، TLS، DTLS، [IPsec و ]انتخاب: امضای کد41 برای به‌روزرسانی‌های نرم‌افزاری سیستم، امضای کد برای تأیید یکپارچگی، ]اختصاص: سایر کاربردها[، هیچ کاربرد دیگر[ از گواهینامه‌های X.509v3 مطایق با 5280 RFC استفاده کند.
55 الزامات گواهینامه‌های X.509/ احراز هویت (2) (FIA_X509_EXT.2.2)
زمانی که مودم نمی‌تواند اتصال مورد نیاز برای تأیید اعتبار یک گواهینامه را برقرار کند، باید ]انتخاب: به سرپرست مودم اجازه دهد که در این مورد تصمیمگیری کند، گواهینامه را بپذیرد، گواهینامه را نپذیرد.[
56 الزامات گواهینامه‌های X.509/ درخواست گواهینامه (1) (FIA_X509_EXT.3.1)
مودم باید مطابق با آنچه در 2986 RFC تشریح شده است، یک پیام Request Certificate تولید کند و بتواند اطلاعاتی شامل کلید عمومی و ]انتخاب: اطلاعات مخصوص به مودم، Name Common، Organization، Unit Organization، [Country را در درخواست فراهم کند. نکات کاربردی: منظور از کلید عمومی در واقع بخش کلید عمومی از جفت کلیدهای عمومی-خصوصی است که در الزام FCS_CKM.1 شرح داده شده است و توسط مودم تولید می‌شود.
57 الزامات گواهینامه‌های X.509/ درخواست گواهینامه (2) (FIA_X509_EXT.3.2)
با دریافت پاسخ CA Certificate Response، مودم باید زنجیره گواهینامهها را با شروع از CA Root اعتبارسنجی کند.

  1. کلاس محافظت از محصول

    1. خودآزمایی خودکار عملکرهای امنیتی

شماره الزام نام الزام
58 خودآمایی بر اساس گواهینامه (1) (FPT_TST_EXT.2.1)
اگر برای انجام آزمون‌های خودآزمایی از یک گواهینامه استفاده شود و آن گواهینامه نامعتبر باشد، محصول باید در آزمون خودآزمایی ناموفق اعلام شود. نکات کاربردی: میتوان به صورت اختیاری از گواهینامه‌ها برای آزمون‌های خودآزمایی استفاده کرد. در این صورت باید سند هدف امنیتی آن را صریحاً بیان کرده و این الزام را اعمال کند.

  1. به‌روزرسانی امن محصول

شماره الزام نام الزام
59 به‌روزرسانی امن بر اساس گواهینامه (1) (FPT_TUD_EXT.2.1)
در صورتی که کد امضای گواهینامه یک به‌روزرسانی نامعتبر باشد مودم نباید آن را نصب کند.
60 به‌روزرسانی امن بر اساس گواهینامه (2) (FPT_TUD_EXT.2.2)
هنگامی که گواهینامه به علت انقضای آن، غیر معتبر اعلام شده است، مودم باید ]انتخاب: اجازه بدهد که در این موارد سرپرست مودم در مورد پذیرش گواهی تصمی گیری کند، گواهی را بپذیرد، گواهی را نپذیرد.[

  1. کلاس مدیریت امنیت

شماره الزام نام الزام
61 مدیریت کارکرد امنیتی 1/توابع (FMT_MOF.1/Funtions)
مودم باید قابلیت ]انتخاب: تعیین نحوه کارکرد، تغییر نحوه کارکرد [ در خصوص ]انتخاب: ارسال داده‌های ممیزی به یک موجودیت IT خارجی (سرور سیسلاگ)، کنترل داده ممیزی، نحوه عمل در زمان پر بودن فضای محلی ذخیره‌سازی[ را به سرپرست امنیتی مودم محدود کند. نکات کاربردی: این الزام در صورتی انتخاب می‌گردد که یک یا چند مورد از سناریوهای زیر اعمال شوند: اگر پروتکل انتقال برای ارسال داده ممیزی به موجودیت IT خارجی که در الزام FAU_STG_EXT.1 تعریف شده است، قابل پیکربندی باشد و ارسال داده ممیزی به موجودیت IT خارجی انتخاب شده باشد. اگر کنترل داده ممیزی قابل پیکربندی باشد، "کنترل داده ممیزی" باید انتخاب گردد. عبارت "کنترل داده ممیزی" به گزینه‌های مختلفی برای انتخاب و اختصاص در الزامات FAU_STG_EXT.1.2، FAU_STG_EXT.1.3 و FAU_STG_EXT.2/LocSpace اشاره دارد.
62 مدیریت کارکرد امنیتی 1/به‌روزرسانی خودکار ( FMT_MOF.1/AutoUpdate)
مودم باید قابلیت ]انتخاب: فعال کردن و غیرفعال کردن[ توابع ]انتخاب: جستجو برای به‌روزرسانی‌های خودکار، به‌روزرسانی خودکار[ را به سرپرست امنیتی مودم محدود کند. نکات کاربردی: این الزام تنها زمانی قابل پیاده‌سازی است که مودم امکان پشتیبانی از جستجو برای به‌روزرسانی‌های خودکار و/یا به‌روزرسانی خودکار را فراهم کند و اجازه فعال و غیرفعال کردن این قابلیت‌ها را بدهد. گزینه "به‌روزرسانی خودکار" ممکن است فقط وقتی انتخاب شود که از امضاء دیجیتال برای تأیید به‌روزرسانی امن استفاده گردد.

  1. پیوست سه: الزامات امنیتی مربوط به Wi-Fi

با توجه به اینکه امروزه اکثر کارکردهای مختلف برای دستگاه مودم مثل ارتباط با شبکه سلولار، نقطه دسترسی شبکه Wi-Fi و مسیریابی در یک دستگاه قرار می‌گیرند و با همان نام مودم شبکه سلولار (به عنوان مثال مودم 4G یا مودم 5G) شناخته می‌شوند، در این فصل الزامات امنیتی مربوط به پیاده‌سازی Wi-Fi در مودم 4G بررسی و بیان میگردد. برای این منظور، دارایی‌ها، تهدیدات و اهداف امنیتی بیان شده در فصلهای 3 و 4 پروفایل حفاظتی حاضر تغییری نمی‌کند، اما ممکن است تعاریف آن برای قسمت Wi-Fi تغییراتی داشته باشد. در این راستا، ابتدا توضیحات مختصری در مورد Wi-Fi و مسأله امنیت آن بیان شده و سپس الزامات امنیتی آن ارائه می‌شود.

  1. مقدمه‌ای بر Wi-Fi

شبکه محلی بی‌سیم (WLAN42 ) قابلیت پیاده‌سازی بر اساس استانداردهای IEEE 802.11 را دارد که به صورت عامیانه به عنوان Wi-Fi شناخته می‌شوند. این استانداردها، صرفاً در دو لایه فیزیکی و MAC43 وارد می‌شوند و به کمک تنظیم این دو لایه، اطلاعات مربوطه در لایه‌های بالاتر را به مقصد منتقل می‌کنند. معمولاً یک شبکه Wi-Fi دارای یک نقطه دسترسی44 و تعدادی کاربر در فاصله نزدیک (حداکثر چند ده متر) است که به این نقطه دسترسی از طریق پروتکل Wi-Fi متصل می‌گردند و پس از آن می‌توانند در لایه‌های بالاتر با یکدیگر ارتباط برقرار کنند. در این میان، ارتباطات بین نقطه دسترسی و کاربران ابتدا با برقراری یک اتصال45 شکل می‌گیرد و در ادامه از طریق آن تبادل اطلاعات صورت می‌گیرد. با توجه به اینکه نقطه تمرکز ما در قسمت Wi-Fi قسمت نقطه دسترسی است، عملکرد نقطه دسترسی در رابطه با پروتکل Wi-Fi در شکل 8-1 نشان داده شده است. برای برقراری اتصال در نقطه دسترسی، نیازمند احراز هویت کاربران هستیم و به این منظور پروتکل‌های متعددی شامل WEP46 ، WPA47 ، WPA2 و WPA3 مطرح شده است که در این میان پروتکل WEP شکسته شده و دیگر توصیه نمی‌شود و همچنین، ضعف‌هایی نیز برای WPA پیدا شده است. همچنین راهکار دیگری برای اتصال به نقطه دسترسی به نام WPS وجود دارد که از طریق فشردن یک دکمه در نقطه دسترسی و همزمان تنظیم این حالت در دستگاه کاربر، قابل استفاده است. این روش نیز به لحاظ امنیتی کاملاً مردود اعلام شده است، اما با این حال این قابلیت در اختیار کاربران قرار می‌گیرد تا در شرایط ضرور بتوانند از آن برای دسترسی به خدمات استفاده نمایند. در کنار این موارد، امکان پیاده‌سازی احراز هویت مبتنی بر سرور RADIUS و پروتکل احراز هویت IEEE 802.1x نیز وجود دارد که بعضاً در شرایطی که شبکه‌ای از Wi-Fiها بخواهند در سطح سازمانی خدمات‌رسانی کنند، به کار گرفته می‌شود.

شکل. ‏8-1 پشته پروتکل پیاده‌سازی‌شده در نقطه دسترسی (قسمت Wi-Fi یک مودم شبکه سلولار)

با انجام پروتکل احراز هویت در Wi-Fi یک کلید نشست تشکیل می‌شود که وظیفه رمزنگاری اطلاعات در پیلود48 لایه MAC را بین نقطه دسترسی و کاربران بر عهده خواهده داشت. حال با توجه به موارد فوق و اینکه محصول مورد نظر یک مودم شبکه سلولار است، در ادامه مسأله امنیت و الزامات کارکرد امنیتی برای Wi-Fi شرح داده میشود. همچنین در ادامه منظور از مودم، نقطه دسترسی وایفای و منظور از کاربر/کلاینت، کاربران متصل‌شده به شبکه Wi-Fi هستند.

  1. مسأله امنیت برای Wi-Fi

در تعریف مسأله امنیت برای قسمت Wi-Fi مودم، قسمت دارایی‌ها و سیاست‌های امنیتی سازمان هیچگونه تفاوتی با دارایی‌ها و سیاست‌های امنیتی سازمان تعریف‌شده برای خود مودم شبکه سلولار ندارند. همچنین قسمت فرضیات Wi-Fi نیز عیناً مشابه فرضیات بیان شده برای خود مودم است، با این تفاوت که به فرض سوم با عنوان A.LIMITED_FUNCTIONALITY، کارکرد Wi-Fi نیز اضافه می‌گردد. برای قسمت تهدیدات نیز هنگام در نظر گرفتن Wi-Fi، همان تهدیدات مودم به جز دو مورد T.DOWNGARDE_ATTACK و T.DEVICE_AND_IDENTITY_TRACKING برقرار است. با این اوصاف، اهداف امنیتی نیز به تناسب تهدیدات بر اساس جدول ‏4-1 باقی خواهند ماند.

بنابراین می‌توان دید که به دلیل قرارگیری Wi-Fi و قابلیت اتصال به شبکه سلولار در یک تجهیز به نام مودم، مسأله امنیت برای کارکرد مودم با کارکرد Wi-Fi تقریباً مشابه است. لذا با توجه به اینکه الزامات برای کارکرد مودم در بخش ‏5-1- به دو صورت کلی (تعریف شده در CC2 و بدون EXT در انتهای نام الزام) و اختصاصی (تعریف نشده در CC2 و EXT در انتهای نام الزام) بیان شده است، تمامی الزامات کلی (یعنی الزامات بدون EXT) در بخش ‏5-1- برای Wi-Fi نیز باید مدنظر قرار بگیرد. به جز آن موارد، برخی الزامات برای Wi-Fi نیز وجود دارد که در ادامه مطرح می‌شود.

  1. الزامات Wi-Fi

شماره الزام نام الزام
1 تولید داده‌های ممیزی (FAU_GEN1.1)
نقطه دسترسی باید بتواند از رويدادهای قابل مميزی زير، يک رکورد مميزی توليد کند: آغاز و پايان عمليات مميزی کليه رويدادهای قابل مميزی که در این سند به آن اشاره نشده ولی تولیدکننده به صلاحدید خود داده‌های ممیزی متناظر با آن رویداد را تولید مینماید (جدول زیر). فعاليت‌های موثر در کارکردهای مدیریتی تجهیز [در صورت بروز هرگونه نقص در ارتباطات بی‌سیم با تجهیز] الزام متناظر رویداد قابل ممیزی رکورد ممیزی اضافی FCS_CKM.1/WPA × × FCS_CKM.2/DISTRIB (optional) × × FCS_CKM.2/GTK × × FCS_CKM.2/PMK × × FCS_RADSEC_EXT.1 × × FCS_RADSEC_EXT.2 × × FIA_8021X_EXT.1 کلیه تلاش‌های انجام شده برای دسترسی به پورت تحت کنترل 802.1X قبل از تبادل کلید و احراز هویت موفقیت آمیز اطلاعات کاربری که سعی در برقراری ارتباط دارد؛ از قبیل آدرس IP و آدرس MAC FIA_PSK_EXT.1 × × FIA_UAU.6 تلاش‌های انجام شده برای احراز هویت مجدد آدرس IP کلاینت FMT_SMF.1/AccessSystem × × FMT_SMR_EXT.1 × × FPT_FLS.1 بروز شکست/خطا در توابع امنیتی هدف ارزیابی حاوی اطلاعات شفاف و کافی در خصوص خطا یا شکست رخ داده FPT_TST_EXT.1 اجرای تست خودکار توابع امنیتی هدف ارزیابی × FTA_TSE.1 × × FTP_ITC.1 تلاش ناموفق در برقراری کانال امن مطابق IEEE 802.11 تشخیص هرگونه دستکاری کانال ارتباطی ×
2 ممیزی انتخابی (FAU_SEL.1)
توابع امنيتي مودم بايد قابليت انتخاب رويدادهای قابل مميزی را بر اساس دارا بودن/ نبودن ويژگي‌های زير از مجموعه رويدادهای مميزی (بر اساس الزام 1) داشته باشد: الف- نوع رويداد ب-هويت سرپرست پ-موفق بودن رويداد امنيتي قابل مميزی ت-شکست رويداد امنيتي قابل مميزی
3 مسیر ذخیره‌سازی ممیزی محافظت شده (فضای ذخیره محلی) (FAU_STG.1)
الف-توابع امنيتي مودم بايد [اختصاص: مقدار فضای ذخيره‌سازی (حداقل به میزان ذخیره 6 ماه رکورد بسته به مجموعه رویدادهای ممیزی شده)] رکوردهای مميزی ذخيره‌شده در دنباله مميزی را از حذف غيرمجاز محافظت نماید. ب- توابع امنيتي مودم بايد قادر باشند تا از تغييرات غيرمجاز رکوردهای مميزی ذخيره‌شده در دنباله مميزی جلوگيری نمایند.
4 تولید کلید رمزنگاری (کلیدهای متقارن برای اتصالات WPA2/WPA3) (FCS_CKM.1.1)
عملکرد امنیتی TSF49 باید کلیدهای رمزنگاری متقارن را بر اساس الگوریتم تولید کلیدهای رمزنگاری معین [انتخاب PRF50 -384، PRF-512، PRF-704] و اندازه کلیدهای رمزنگاری معین [انتخاب: 128 بیتی، 192 بیتی، 256 بیتی] ایجاد نماید. برای این کار باید از مولد بیت‌های تصادفی که RBG51 و استانداردهای ذیل را رعایت می‌کند، استفاده کنند: [انتخاب: IEEE 802.11-2020، IEEE 802.11ax-2021] نکته کاربردی: اين الزام، تنها کليدهايي را به کار مي‌برد که برای ارتباط بين نقطه دسترسي و کلاينت، زماني‌که کلاينت احراز هويت شده است، توليد و استخراج مي‌شوند. اين الزام اشاره به استخراج PTK52 از PMK53 دارد، که با استفاده از يک مقدار تصادفي مستخرج از RBG مشخص‌شده در اين پروفايل حفاظتي، تابع HMAC مبتنی بر الگوريتم SHA-1 مشخص‌شده در اين پروفايل حفاظتي و همچنين اطلاعات توليد مي‌شود. اين مسأله در استاندارد 802.11-2007 فصل هشتم مشخص شده است (مودم باید از اتصال امن به روش WPA3 پشتیبانی کند و مستندات مربوطه و روش تولید کلید رمزنگاری بایستی به صورت جداگانه توسط تولیدکننده مودم اظهار گردد).
5 تولید کلید رمزنگاری (کلیدهای نامتقارن) (FCS_CKM.1.2)
توابع امنيتي مودم بايد کليدهای رمزنگاری نامتقارن مورد استفاده برای ايجاد کليد را مطابق با [انتخاب: استاندارد NIST SP 800-56 A حاوی توصيه‌های لازم برای طرح توافق کليد رمزنگاری مشترک با استفاده از رمزنگاری کلید عمومی مبتنی بر لگاريتم گسسته در فضای میدان‌های گالوا؛ استاندارد NIST 800-56 A حاوی توصيه‌های لازم برای طرح توافق کلید با استفاده از رمزنگاری کلید عمومی مبتنی بر لگاريتم گسسته مبتني بر خم بيضوی و پيادهسازی NIST Curves در P-256 همچنین P-384 و P-521؛ استاندارد NIST SP 800-56 B حاوی توصيه‌های لازم برای طرح تبادل کليد با استفاده از رمزنگاری کلید عمومی مبتنی بر تجزيه اعداد صحيح به شکل RSA و اندازه‌های کليد رمزنگاری شده معادل يا بزرگتر از کليد متقارن 112 بيتي] تولید نماید و کلید رمزنگاری را فاش نکند. نکته کاربردی: این نیازمندی‌ برای کلیدهای رمزنگاری توزیعی‌ای موضوعیت دارد که توسط مودم برای مخابره پیام‌ها به کاربران ایجاد می‌شوند. در استاندارد 802.11-2020 فرمت انتقال داده و این نکته ذکر شده‌ است که داده‌ها باید با روش AES Key Wrap که در استاندارد NIST SP 800-38 F مشخص شده‌ است، رمزگذاری شوند. همچنین اين مؤلفه الزام مي‌دارد که مودم قادر به توليد جفت کليد عمومي/خصوصي باشد که برای اهداف توافق کليد به منظور پروتکل‌های مختلف رمزنگاری استفاده شده توسط مودم، مثل IPsec، استفاده مي‌شوند. اگر طرح‌های چندگانه پشتيباني شوند، نويسنده هدف امنيتي بايد اين الزام را برای بيان کردن اين قابليت‌ها تکرار نماید. طرح مورد استفاده از انتخاب‌های گفته شده، توسط نويسنده هدف امنيتي تعیین خواهد شد.
6 توزیع کلید رمزنگاری (PMK) (FCS_CKM.2.1)
توابع امنيتي مودم، بايد جفت کليد اصلي 802.11 مطابق با روش توزیع کليد رمزنگاری مشخص: (دريافت از سرور احراز هويت x802.1 که استاندارد 802.11-2007 را برآورده مي‌نماید)، توزيع نماید و کليدهای رمزنگاری را افشاء ننماید.
7 توزیع کلید رمزنگاری (GTK) (FCS_CKM.2.2)
توابع امنيتي مودم، بايد کليد موقتي گروهي (GTK) را مطابق با روش توزيع کليد رمزنگاری مبتنی بر ]انتخاب: پنهان نمودن کليد AES در يک قالب کليد؛ EAPOL54 بر اساس RFC 3394 برای پنهان نمودن کليد AES در 802.11-2007[، توزيع نماید و کليدهای رمزنگاری را افشاء ننماید.
8 پاک‌سازی کلید رمزنگاری (FCS_CKM_EXT.4)
توابع امنيتي مودم بايد تمام کليدهای رمزنگاری خصوصي و مخفي و پارامترهای بحراني امنيتي رمزنگاری را که ديگر مورد استفاده قرار نمي‌گيرند، کاملاً پاک‌سازی نماید. نکته کاربردی: هرگونه اطلاعات مرتبط امنيتي (همچون کليد، داده احراز هويت و رمز عبور) بايد زماني‌که مورد استفاده قرار نمي‌گيرد، پاک‌سازی شود تا از فاش شدن و تغيير داده‌های حساس امنيتي جلوگيری گردد.
9 عملیات رمزنگاری (رمزگذاری/رمزگشایی داده‌ها)
توابع امنيتي مودم بايد (رمزگذاری و رمزگشايي) را مطابق با الگوريتم رمزنگاری مشخص شده (AES) که در ]اختصاص: يک يا بيش از يک مود عمل مي‌نماید[ و ]انتخاب: اندازه‌های کليد رمزنگاری 128 بیتی، 192 بیتی، 256 بيتي، و نه هيچ اندازه ديگری که با موارد زير تطابق داشته باشد[ انجام دهد. [انتخاب: استانداردهایAES” ، FIPS PUB 197، NIST SP 800-38A، NIST SP 800-38B،NIST SP 800-38C، NIST SP 800-38D، NIST SP 800-38E] نکته کاربردی: در قسمت «اختصاص»، نويسنده هدف امنيتي بايد مود يا مودهايي را که در آن مودهای AES عمل مي‌نماید، انتخاب نماید. برای انتخاب ابتدا، نويسنده هدف امنيتي بايد اندازه کليدی را که توسط اين عملکرد پشتيباني مي‌شود انتخاب کند.
10 عملیات رمزنگاری (امضای دیجیتال) (FCS_COP.1.2)
توابع امنيتي مودم بايد خدمات رمزنگاری امضا را مطابق با موارد زير انجام دهند: [انتخاب: الگوريتم امضای ديجيتال DSA با کليد 2048 بيتي يا بيشتر مطابق با «FIPS PUB 186-3، استاندارد امضای ديجيتال»؛ الگوريتم امضای ديجيتال (rDSA (RSA با کليد 2048 بيتي يا بيشتر مطابق با «FIPS PUB 186-3 استاندارد امضای ديجيتال»؛ الگوريتم امضای ديجيتال مبتنی بر خم بيضوی ECDSA1 با کليد 256 بيتي يا بيشتر مطابق با ]انتخاب: «FIPS PUB 186-3 استاندارد امضای ديجيتال»؛ منحني‌های استاندارد P384 ،P-256 ، NIST curves؛ P251 همچنان ‌که در «FIPS PUB 186-3 استاندارد امضای ديجيتال» تعريف شده است]].
11 عملیات رمزنگاری (Hashing) (FCS_COP.1.3)
توابع امنيتي مودم بايد خدمات درهم‌سازی رمزنگاری را مطابق با يک تابع درهم‌ساز مشخص [انتخاب: SHA-1، SHA-256، [SHA-384 و اندازه‌های چکیده پيام [انتخاب: 256، 160 و 384 بيت[ که مطابق با استاندارد FIPS 180-3 باشد، انجام دهد. نکته کاربردی: انتخاب الگوريتم درهم‌سازی بايد متناسب با اندازه خلاصه پيام باشد، به طور مثال اگر SHA-1 انتخاب شده باشد، تنها انتخاب اندازه خلاصه پيام قابل قبول 160 بيت خواهد بود.
12 عملیات رمزنگاری (پیام هش کلیددار احراز هویت) (FCS_COP.1.4)
توابع امنيتي مودم بايد [کد احراز هويت پيام مبتني بر درهم‌سازی-کليد] را در تطابق با يک الگوريتم رمزنگاری مشخص [انتخاب: SHA-1، SHA-256، SHA-HMAC-384 [ با اندازه کليد ]اختصاص: اندازه کليد (تعداد بيت) استفاده شده که مطابق با «FIPS 198-1، کد احراز هويت پيام مبتني بر درهم‌سازی-کليد» و «FIPS 180-3، استاندارد درهم‌ساز امن»] باشد، انجام دهد. نکته کاربردی: انتخاب الگوريتم درهم‌سازی بايد متناسب با اندازه خلاصه پيام باشد، به طور مثال اگر HMAC-SHA-256 انتخاب شده است، تنها اندازه خلاصه پيام قابل قبول 256 بيت خواهد بود. توابع امنيتي مودم بايد رمزنگاری و رمزگشايي را در تطابق با الگوريتم رمزنگاری مشخص AES CCMP و اندازه کليد 128 بيتي که مطابق با IEEE 802.11-2007،NIST SP 800-38C و FIPS PUB 197 است، انجام دهد.
13 عملیات رمزنگاری (WPA2/WPA3 Data رمزگذاری/رمزگشایی) (FCS_COP.1.5)
توابع امنيتي مودم بايد رمزنگاری و رمزگشايي را در تطابق با يک الگوريتم رمزنگاری مشخص AES CCMP و اندازه کليد 128 بيتي که مطابق با IEEE 802.11-2007،NIST SP 800-38C وFIPS PUB 197 انجام دهد. نکته کاربردی: توجه شود که بايد انطباق با استاندارد AES CCMP، IEEE 802.11-2007 با اندازه کليد رمزنگاری حداقل 128 بیت پياده‌سازی شود. اين الزام ممکن است شامل الزاماتي برای مودهای رمزنگاری جديد/اضافي و اندازه کليد باشد. با توجه به پشتیبانی مودم از برقراری اتصال امن به روش WPA3، مستندات مربوطه و روش تولید کلید رمزنگاری بایستی به صورت جداگانه توسط تولید کننده محصول اظهار گردد.
14 حفاظت کامل از اطلاعات کاربران (FDP_RIP.2)
توابع امنيتي مودم بايد تضمين کنند که هرگونه محتوی اطلاعات قبلي يک منبع را در زمان [انتخاب: تخصيص منابع به، آزادسازی منابع از[ تمام موجوديت‌های غيرفعال، غيرقابل دسترس کنند.
15 مدیریت رمز عبور (FIA_PMG_EXT.1)
شرح الزام: توابع امنيتي مودم بايد قابليت‌های مديريت رمز عبور زیر را فراهم نماید: رمزهای عبور بايد بتوانند هر ترکيبي از حروف کوچک و بزرگ، اعداد و کاراکترهای خاص: [انتخاب: "@"، "#"، "$"، "٪"، "^"، "!"، "&"، "*"، "("، ")"، [اختصاص: کاراکتر ديگر]] باشند.
16 شناسایی و احراز هویت کاربر (FIA_UIA_EXT.1**)**
توابع امنيتي مودم، بايد پيش از آنکه نياز به موجوديت‌های غير مودم، جهت شروع رويه شناسايي و احراز هويت باشد، اقدامات زير را مجاز نماید: ]اختصاص: ليستي از سرويس‌ها و اقداماتي که توسط توابع امنيتي مودم جهت پاسخ دادن به درخواست‌های <غير مودم> صورت مي‌گيرد[.
17 بازخورد احراز هویت محافظت‌شده (FIA_UAU.7**)**
توابع امنيتي مودم بايد زماني که فرآيند احراز هويت، در کنسول محلي در حال صورت گرفتن است؛ تنها به سرپرست بازخورد مبهمي ارائه دهند. نکته کاربردی: «بازخورد مبهم» نشان مي‌دهد که توابع امنيتي مودم، نمايش واضحي از هر داده‌ای که جهت احراز هويت شدن توسط کاربر وارد مي‌شود، ندارند (مانند انعکاس رمز عبور) هر چند «بازخورد مبهم» از روند احراز هويت ممکن است ارائه شود (همچون * که در زمان وارد نمودن هر کاراکتر توسط کاربر، نشان داده مي‌شود). «بازخورد مبهم» همچنين نشان مي‌دهد که توابع امنيتي مودم، هيچ اطلاعاتي را در طول رويه احراز هويت به کاربر برنمي‌گردانند.
18 802.1X برای احراز هویت موجودیت دارای دسترسی از طریق پورت (FIA_8021X_EXT.1)
توابع امنيتي مودم بايد مطابق با استاندارد IEEE 802.1X موجودیت پورت دسترسی را مدیریت نماید. الزام فرعی FIA_8021X_EXT.1.1: توابع امنيتي مودم بايد مطابق با استاندارد IEEE 802.1X دستيابي به پورت (PAE55 ) را برای کاربر در نقش «مدیر سیستم» فراهم نماید. الزام فرعی FIA_8021X_EXT.1.2: توابع امنيتي مودم بايد مطابق با استاندارد IEEE 802.1X و بر اساس RFC 2865 وRFC 3579 امکان برقراری ارتباط با سرورهای RADIUS را فراهم نماید. الزام فرعی FIA_8021X_EXT.1.3: توابع امنيتي مودم بایستی مانع هرگونه دسترسی از کلاینت بی‌سیم به پورت تحت کنترل 802.1X، قبل از انجام موفقیت‌آمیز فرآیند احراز هویت گردد.
19 مدیریت رفتار عملکردهای امنیتی (FMT_MOF.1)
توابع امنيتي مودم بايد قابليت فعال‌سازی، غير فعال‌سازی، تعيين و تغيير رفتار تمام توابع امنيتي مودم را که در اين پروفايل حفاظتي معرفي شده است به سرپرست احراز هويت شده محدود کنند. نکته کاربردی: تنها کاربران انساني مودم، کاربراني هستند که نقش سرپرست دارند. بنابراين، اين الزام به کاربراني اشاره دارد که نباید سازوکارهاي مودم را که در پياده‌سازی الزامات امنيتي پروفايل حفاظتي استفاده مي‌شوند، دستکاری کنند. اين قابليت‌ها به صراحت توابع پياده‌سازی‌شده در مودم را با توجه به اضافه شدن عناصر مودم که به شبکه اضافه شده‌اند، پوشش مي‌دهند.
20 مدیریت داده‌های TSF (داده‌های عمومی TSF) (FMT_MTD.1)
توابع امنيتي مودم بايد توانايي مدیریت داده‌های خود را تنها به سرپرست امنيتي محدود نمایند. نکته کاربردی: عبارت"مدیریت"مي‌تواند شامل انجام موارد زير باشد، اما تنها به اين موارد نيز محدود نمي‌شود: ايجاد، مقداردهي، مشاهده، تغيير پيش‌فرض، تغييردادن، حذف نمودن، پاک کردن و اضافه نمودن الزام به طور پيش‌فرض برای مديريت داده توابع امنيتي مودم در نظر گرفته مي‌شود. به عنوان مثال داده‌های توابع امنيتي مودم مي‌تواند شامل اطلاعات رمزنگاری باشد و همچنين، مديريت اين داده‌ها شامل مرتبط کردن پروتکل رمزنگاری به واسط مي‌باشد.
21 مدیریت داده‌های TSF (خواندن داده‌های احراز هویت) (FMT_MTD.1.2)
توابع امنيتي مودم بايد از خواندن داده‌های احراز هويت مبتني بر رمزعبور جلوگيری کنند. نکته کاربردی: منظور اين الزام آن است که هيچ کاربر يا سرپرستي قادر به خواندن داده احرازهويت اوليه (همانند رمزعبور رمز نشده) از طريق واسط‌های "معمولي" نمي‌باشد. چنانچه خواندن چنين داده‌هايي منجر به جعل هويت کاربر شود، مدير قدرتمند مي‌تواند مستقيماً حافظه را بخواند يا با يک خواندن اولویت فايل سامانه، رمز عبور را بدست آورد اما اعتمادی به انجام اين کار نيست.
22 مدیریت داده‌های TSF (برای خواندن همه کلیدهای متقارن) (FMT_MTD.1.3)
توابع ارزيابي بايد از خواندن تمام کليدهای از پيش به اشتراک گذاشته شده، کليد متقارن و کليدهای خصوصي جلوگيری نمایند. نکته کاربردی: منظور اين الزام آن است که هيچ کاربر يا سرپرستي قادر به خواندن يا مشاهده کليدهای شناسايي شده (ذخيره شده يا موقتي) از طريق واسط‌های "معمولي" نیست؛ درحالي‌که سرپرست مجاز مي‌تواند با خواندن مستقيم حافظه اين کليدها را مشاهده نماید.
23 مدیریت امنیت شبکه (FMT_SMF.1)
عملکرد امنیتی TSF باید قادر باشد تا کارکردهای مدیریتی زیر را انجام دهد: پیکربندی خط مشی امنیتی برای کلیه شبکه‌های وایرلس، شامل: نوع امنیت پروتکل احراز هویت اعتبار سرویس‌گیرنده که باید برای احراز هویت مورد استفاده قرار بگیرد شناسه SSID آیا SSID پخش شده ‌است قرار دادن فرکانس روی [انتخاب: 2.4 گیگاهرتز، 5 گیگاهرتز، 6 گیگاهرتز] سطح توان ارسالی.
24 نقش‌های مدیریت امنیت (FMT_SMR.1)
عملکرد امنیتی TSF باید قادر باشد تا به صورت از راه دور TOE سرویس‌گیرنده وایرلس که باید به صورت پیش‌فرض غیرفعال باشد، را مدیریت کند و توابع امنيتي مودم بايد نقش‌ کاربر مدیر (سرپرست) مجاز را نگهداری و پشتیبانی کنند.
25 حفظ حالت ایمن در حالت شکست (FPT_FLS.1)
توابع امنيتي مودم بايد زماني‌که شکست در خودآزمايي‌های راه‌اندازی رخ مي‌دهد، حالت ایمن خود را حفظ نمایند. نکته کاربردی: اين الزام بدان معناست که مودم بايد زماني‌که شکست شناختهشده‌ای رخ مي‌دهد به يک وضعيت امن دست پيدا نماید. چنانچه مودم در اواسط يک عمليات بحراني با شکست مواجه شد نیز همین اتفاق باید تکرار شود و نهایتاً به یک وضعیت امن پایدار برسیم.
26 تشخیص پخش مجدد (FPT_RPL.1)
توابع امنيتي مودم بايد بازپخش موجوديت‌ها (بسته‌هایی که انتقال آن‌ها توسط مودم در شبکه خاتمه یافته است) را شناسايي نماید.
27 مهر زمانی قابل اعتماد (FPT_STM.1)
توابع امنيتي مودم بايد قادر باشند برای استفاده خودشان مهرهای زماني (تأییدیه) قابل اطميناني ارائه دهند.
28 حداکثر ظرفیت قابل تخصیص (FRU_RSA.1)
توابع امنیتي مودم بايد مکانیزم مدیریت حداکثر ظرفيت منابع را به اجرا درآورند: ]اختصاص: منابعي که واسط‌های سرپرستي را پشتيباني مي‌کنند؛ منابع کنترل شده؛ کاربران فردی؛ گروهي از کاربران تعريف شده؛ موجوديت‌های فعال؛ هر منبع ديگر[. [انتخاب: مي‌توانند از موارد اعلامی، انتخاب همزمان در يک بازه زماني مشخص استفاده نمایند]. نکته کاربردی: مودم منطبق بر اين پروفايل حفاظتي، بايد حداکثر ظرفيت را روی منابع فراگيری که در پشتيباني واسط‌های سرپرستي از راه دور استفاده مي‌شوند، اعمال کند.
29 قفلکردن نشست آغاز شده توسط توابع امنیتی محصول (FTA_SSL_EXT.1)
توابع امنيتي مودم بايد پس از يک مدت زمان مشخص غيرفعال بودن، برای نشست‌ها، برخی تعاملات محلي را انجام دهند. [انتخاب: 1) قفلکردن نشست، پاککردن يا رونويسي صفحه نمايش دستگاه که سبب مي‌شود محتوای فعلي غيرقابل خواندن شود، غيرفعال‌سازی کليه فعاليت‌های مربوط به دسترسي داده‌های کاربر و دستگاه‌های نمايش. همچنين نياز است که پيش از باز شدن نشست، سرپرست توابع امنيتي مودم را دوباره احراز هويت نماید؛ 2) خاتمه‌دادن نشست. مدت زمان غيرفعال بودن، توسط سرپرست تعيين شود].
30 خاتمه نشست آغاز شده توسط توابع امنیتی مودم (FTA_SSL3.1)
توابع امنيتي مودم بايد هنگام ضرورت، امکان خاتمه‌دادن به نشست‌های فعال را به کاربر مدیر بدهند.
31 خاتمه نشست توسط کاربر (FTA_SSL.4)
توابع امنیتي مودم بايد به شروع کننده نشست، اجازه اتمام نشست تعاملي خودش را بدهند.
32 بنرهای پیش‌فرض دسترسی به مودم (FTA_TAB.1)
توابع امنيتي مودم بايد پيش از آغاز نشست کاربر، پيام اعلانی را به سرپرست مجاز نمایش دهند که بيانگر استفاده مجاز از مودم است. نکته کاربردی: اين الزام به منظور ایجاد نشست‌های تعاملي بين کاربر انساني و مودم اعمال مي‌شود. موجوديت‌های IT که اتصالات از راه دور و اتصالات برنامه‌ريزی شده‌ای (رويه‌های راه دوری که روی يک شبکه فراخواني مي‌شوند) را برقرارمي‌کنند، لازم نيست توسط اين الزام پوشش داده شوند.
33 برقراری نشست (FTA_TSE)
توابع امنیتی مودم بايد قادر باشند برقراری يک نشست کلاينت بی‌سیم را با توجه به موقعيت، زمان و روز ]اختصاص: ديگر ويژگي‌های نشست[ رد نمایند. نکته کاربردی: (موقعيت) مي‌تواند به صورت يک شماره پورت، آدرس IP، ساب‌نت، VLAN، واسط مودم و غیره مشخص شود. قسمت (اختصاص) توسط نويسنده هدف امنيتي استفاده مي‌شود تا ويژگي‌های بيشتری را که نشست‌های برقرار شده مي‌توانند براساس آن‌ها انکار شوند، مشخص نماید.
34 پالایش دسترسی کاربران بر اساس آدرس MAC (FTA_TSE.1.1)
توابع امنیتی مودم بایستی امکان مدیریت دسترسی کلاینت‌ها به تجهیز بی‌سیم، از طریق فیلتر مجاز/غیرمجاز بودن دسترسی بر اساس آدرس MAC را فراهم نمایند.
35 مدیریت قابلیت WPS (FTA_TSE.1.2)
توابع امنیتی مودم باید امکان مدیریت کامل قابلیت WPS در تجهیز را برای کاربر مدیر فراهم نمایند و در پیکربندی پیش‌فرض محصول نیز این قابلیت غیرفعال باشد. کاربر مدیر نیز باید پس از دریافت هشدارهای لازم در خصوص فعال‌سازی مکانیزم یاد شده، امکان فعالسازی/غیرفعال‌سازی آن را داشته باشد.
36 کانال قابل اعتماد درون توابع امنیتی محصول (FTP_ITC.1)
توابع امنيتي مودم بايد با استفاده از 802.11-2007، 802.1x و IPsec، و [انتخاب: SSH، TLS، TLS/HTTPS، سایر پروتکل‌های قابل تأیید[ کانال ارتباطي امن بين خود و تمام موجوديت‌های مجاز IT ارائه نمایند. این کانال که به طور منطقي از ديگر کانال‌های ارتباطي جدا است، باید به صورت مطمئن نقطه پاياني‌اش را شناسايي نموده و از داده‌های کانال در برابر تغيير يا افشاء، محافظت نماید.
37 مسیر قابل اعتماد (FTP_TRP.1)
توابع امنيتي مودم بايد با استفاده از [انتخاب: پروتکل‌هایSSH ،IPsec ، TLS، TLS/HTPPS] ارتباطي امن بين خود و سرپرست راه دور (متصل از طریق شبکه الگوریتم) ارائه نماید. این کانال ارتباطی که به طور منطقي از ديگر مسيرهای ارتباطي جدا است به صورت مطمئن نقطه پاياني‌اش را شناسايي مي‌نماید و از داده‌های مخابره شده در برابر تغيير يا افشاء محافظت مي‌نماید.

  1. پیوست چهار: الزامات مربوط به مسیریاب

    یکی از کارکردهای مهم در مودم‌های 4G/5G، استفاده از مسیریاب در لایه شبکه برای انتقال اطلاعات به مقصد درست است. به این منظور، یک سند پروفایل حفاظتی مسیریاب در سایت اِرم56 وجود دارد که می‌توان از آن به منظور دریافت و اجرای الزامات مربوط به مسیریاب در مودم استفاده نمود. با این حال، به جهت سهولت دسترسی و همچنین، اختصار و دقت بیشتر، تعدادی از این الزامات به عنوان الزامات اساسی مرتبط با کارکرد مسیریاب در این فصل در نظر گرفته شده و پیادهسازی آنها توسط سازنده در مودمِ دارای قابلیت مسیریاب الزامی است. عدد درون پرانتز در جلوی شماره الزامها نشاندهنده شماره آن الزام در سند پروفایل حفاظتی مسیریاب اشاره شده است. لازم به ذکر است که الزامات کلی مطرح‌شده برای قسمت مودم واقع در بخش ‏5-1- در اینجا نیز می‌تواند به کار گرفته شود. همچنین منظور از «هدف ارزیابی» در ادامه، همان مودم است.

1 (2) کنترل زیرمجموعه جریان اطلاعات (خط‌مشی نامعتبر) (FDP_IFC.1.1)
توابع امنيتي هدف ارزیابي باید [خط‌مشي عملکرد امنيتي جریان اطلاعات نامعتبر] را بر روی [ موجودیت فعال مبدا: واسط57 هدف ارزیابي که اطلاعات بر روی آن دریافت مي‌شود. موجودیت فعال مقصد: واسط هدف ارزیابي که اطلاعات به آن مي‌رسد. اطلاعات: بسته‌های شبکه، نمونه‌ای از اطلاعات هستند. عمليات: عبور اطلاعات به وسيله باز کردن یک اتصال رله از طریق توابع امنيتي هدف ارزیابي از طرف موجودیت فعال مبدأ به موجودیت فعال مقصد و با حصول اطمينان از شرایط زیر: اتصال از موجودیت فعال مبدأ که در یک شبکه معتبر متناظر است. اتصال رله جدید که به سمت موجودیت فعال مقصد روی یک شبکه معتبر متناظر، ساخته مي‌شود.] اجرا کند. نکات کاربردی: خط‌مشی عملکرد امنیتی جریان اطلاعات نامعتبر، همان سیاست‌گذاری سازمانی برای کنترل عملکرد این جریان اطلاعاتی است که توسط سازمان به تولیدکننده ابلاغ می‌شود. این سیاست‌گذاری معمولا در سه حوزه موجودیت‌های فعال، اطلاعات تحت کنترل و عملیات کنترل جریان اطلاعات است. منظور از اتصال رله، بازارسال تمامی بسته‌های اطلاعاتی از یک مبدأ به سمت یک مقصد بدون پردازش اضافی روی بسته‌های مربوطه است.
2 (5) مشخصه‌های امنيتی ساده (خط‌مشی نامعتبر) (FDP_IFF1.2)
توابع امنيتي هدف ارزیابي باید مجوز جریان اطلاعات بين موجودیت‌های فعال مبدا و اطلاعات کنترل شده را از طریق عمليات‌های کنترل شده، توسط قانون زیر را فراهم آورند: [هویت فرضي موجودیت مبدا، در مجموعه‌ای از شناسه‌های موجودیت مبدا مي‌باشد؛ هویت موجودیت مقصد در مجموعه‌ای از شناسه‌های موجودیت مقصد مي‌باشد؛ مشخصه‌های امنيت اطلاعات با توجه به الگوریتمهای ]اختصاص: الگوریتم‌هایي که توسط هدف ارزیابي جهت منطبق کردن مشخصه‌های امنيت اطلاعات با قوانين سياست‌گذاری اطلاعات استفاده مي‌شود[ منطبق بر صفات در قوانين سياست‌گذاری جریان اطلاعات مي‌باشد. قانون سياست‌گذاری جریان اطلاعات که انتخاب شده است، مجاز بودن جریان اطلاعات را مشخص مي‌کند[. نکات کاربردی: در مسيریاب، قوانين خط‌مشي جریان اطلاعات توسط سرپرست مشخص مي‌شود که این قوانين شامل مقادیر مربوط به صفات امنيتي اطلاعات مي‌باشند (یا علامت‌های عمومي که برای مقادیر مختلف «ایستاده» مي‌باشد؛ برای مثال آدرس 127.*.*.* هر آدرس IP که با 127 شروع مي‌شود را نشان مي‌دهد.) و به هر قانون یک اقدام مرتبط شده است که یا اجازه جریان یافتن اطلاعات را مي‌دهد یا جریان یافتن اطلاعات را غيرمجاز مي‌کند. زماني که یک بسته به واسط مبدا رسيد، مقادیر صفات امنيتي اطلاعات آن بسته توسط برخي از الگوریتم‌های مشخص هدف ارزیابي با هر یک از قوانين سياست‌گذاری جریان اطلاعات مقایسه مي‌شود و در صورت منطبق بودن، اقدام مشخص شده توسط قانون صورت مي‌گيرد. از آنجا که علامت عمومي اجازه مي‌دهد صفات خاص در یک بسته، به طور بالقوه با بيش از یک قانون مطابق باشد، نویسنده هدف امنيتي نياز دارد تا قسمت «اختصاص» را با الگوریتمي کامل گرداند که هدف ارزیابي برای یافتن « قانون منطبق» از آن استفاده مي‌کند. این مي‌تواند «اولين تطابق»، «خاص‌ترین تطابق» یا شامل توضيحات مفصل‌تری باشد
3 (9) مشخصه‌های امنيتی ساده (خط‌مشی نامعتبر) (FDP_IFF1.2)
توابع امنيتي هدف ارزیابي باید صریحاً جریان یافتن اطلاعاتي مبتني بر قوانين زیر را انکار کند: درصورتي که شناسه مبدأ مفروض اطلاعات دریافتي از هدف ارزیابي در مجموعه شناسه‌های موجودیت فعال مبدأ نباشد، هدف ارزیابي باید مانع از درخواست‌های دسترسي یا ارائه سرویس شود. درصورتي که شناسه مبدأ فرض شده از اطلاعات دریافتي توسط هدف ارزیابي یک شناسه Broadcast باشد، هدف ارزیابي باید مانع از درخواست‌های دسترسي یا ارائه سرویس شود. نکات کاربردی: منظور این الزام آن است تا اطمينان حاصل شود که کاربر نمي‌تواند بسته‌هایي که ادعای ایجاد شدن بر روی یک واسط هدف ارزیابي دیگری را دارند، روی واسطي ارسال کند که روی آن ایجاد شده است. شناسه‌ای Broadcast است که بيش از یک آدرس ميزبان را بر روی شبکه مشخص کند. بدیهي است که هدف ارزیابي مي‌تواند تنها از پيکربندی زیرشبکه‌ای از شبکه‌هایي که به طور مستقيم به واسط هدف ارزیابي متصل هستند، آگاهي یابد و در نتيجه تنها از آدرس‌های Broadcast در این شبکه‌ها مطلع مي‌شود. درصورتي که شناسه مبدأ مفروض اطلاعات دریافتي توسط هدف ارزیابي یک شناسه Loopback باشد، هدف ارزیابي باید مانع از درخواست‌های دسترسي یا ارائه سرویس شود. در صورتي که اطلاعات دریافتي توسط هدف ارزیابي شامل مسيری (مجموعه‌ای از شناسه‌های شبکه ميزبان) باشد که توسط اطلاعات باید از موجودیت فعال مبدا به سمت موجودیت فعال مقصد جریان یابد، هدف ارزیابي باید مانع از درخواست شود.
3 (11) مشخصه‌های امنيتی ساده (خط‌مشی معتبر) (FDP_IFF.1.2)
توابع امنيتي هدف ارزیابي باید مجوز جریان یافتن اطلاعات بين موجودیت‌های فعال مبدا و موجودیت فعال مقصد را از طریق عمليات‌های کنترل شده بدهد در صورتي که قوانين زیر منعقد شود: [موجودیت فعال مبدا، به طور موفقيتآميز به هدف ارزیابي احراز هویت شود. شناسه موجودیت فعال مقصد در مجموعه‌ای از شناسه‌های مقصد باشد؛ مشخصه‌های امنيت اطلاعات با توجه به الگوریتم‌های [اختصاص: الگوریتم‌هایي که توسط هدف ارزیابي جهت منطبق کردن مشخصه‌های امنيت اطلاعات با قوانين سياست‌گذاری اطلاعات استفاده مي‌شود] منطبق بر مشخصه‌هایي در قوانين سياست‌گذاری جریان اطلاعات باشد. قانون سياست‌گذاری جریان اطلاعاتي که انتخاب شده است، مجاز بودن جریان اطلاعات را مشخص کند] نکات کاربردی: در مسيریاب، سرپرست قوانين سياست‌گذاری جریان اطلاعاتي را مشخص مي‌کند که حاوی مقادیر مربوط به مشخصه‌های امنيتي اطلاعات مي‌باشند و با هر قانون اقدامي مرتبط شده است که یا اجازه جریان یافتن اطلاعات را مي‌دهد یا جریان یافتن اطلاعات را رد مي‌کند. زماني که یک بسته به واسط مبدا رسيد، مقادیر مشخصه‌های امنيتي اطلاعات بسته با هر یک از قوانين سياستگذاری جریان اطلاعات توسط برخي از الگوریتم‌های خاص هدف ارزیابي مقایسه مي‌شود و زماني که یک تطابق مشاهده شد، اقدام خاص توسط آن قانون صورت مي‌گيرد. از آنجا که جایگزیني اجازه مي‌دهد مشخصه‌های خاص در یک بسته، به طور بالقوه با بيش از یک قانون مطابق باشند، نویسنده هدف امنيتي نياز دارد تا قسمت «اختصاص» را با الگوریتمي کامل گرداند که هدف ارزیابي برای یافتن قانون منطبق استفاده مي‌کند. این مي‌تواند «اولين تطابق»، «خاصترین تطابق» یا کمي بيش از توضيحات مفصل باشد.
4 (17) مدیریت رمز عبور (FIA_PMG_EXT.1.1)
توابع امنيتي هدف ارزیابي باید قابليت‌های مدیریت رمز عبور را که در زیر ذکر شده‌اند برای رمزهای عبور سرپرستي فراهم کند: رمزهای عبور باید بتوانند هر ترکيبي از حروف کوچک و بزرگ، اعداد و کاراکترهای خاص: [انتخاب: "@"، "#"، "$"، "٪"، "^"، "!" "&"، "*"، ")"، "("، [اختصاص: کاراکتر دیگر]] باشند. حداقل طول رمز عبور باید توسط سرپرست امنيت، قابل تنظيم بوده و 15 کاراکتر یا بيشتر باشد. نکات کاربردی: نویسنده هدف امنيتي، کاراکترهای خاصي که توسط هدف ارزیابي پشتيباني مي‌شوند را انتخاب مي‌کند. نویسنده این اختيار را دارد تا کاراکترهای خاص بيشتری را با استفاده از عبارت «اختصاص» ليست کند. «رمزعبور سرپرستي» به آن دسته از رمز عبورهایي اشاره دارد، که سرپرستان از آن‌ها در کنسول محلي یا پروتکل‌هایي که از «رمزعبور» پشتيباني مي‌نمایند (همچون HTTPS، SSH)، استفاده مي‌کنند.
5 (19) شناسایی و احراز هویت کاربر (FIA_UIA_EXT.1.2)
توابع امنيتي هدف ارزیابي، باید هر سرپرست را ملزم به شناسایي و احرازهویت موفق کند، پيش از آنکه به هر اقدام مياني از سوی سرپرست اجازه داده شود. نکات کاربردی: این الزامات به کاربران سرویس‌هایي اعمال مي‌شود که از هدف ارزیابی به طور مستقيم قابل دسترس است و شامل سرویس‌هایي که با اتصال از طریق هدف ارزیابی در دسترس قرار مي‌گيرند، نمي‌شود. در حالي که باید هيچ سرویس یا سرویس‌های کمي پيش از شناسایي و احراز هویت در دسترس موجودیت‌های خارجي باشند، در صورت وجود چنين سرویس‌هایي باید در قسمت «اختصاص» ليست شوند، در غير اینصورت «بدون هيچ اقدام دیگر» انتخاب مي‌شود. احراز هویت مي‌تواند بر اساس رمز عبور از طریق یک کنسول محلي یا پروتکلي باشد که از چنين رمزهای عبوری پشتيباني مي‌کند (همچون SSH)، یا براساس گواهينامه (TLS، SSH) باشد. برای ارتباط با یک موجودیت IT خارجي (برای مثال سرور مميزی، یا NTP سرور) چنين اتصالاتي باید مطابق FTP_ITC صورت گيرد، چنين پروتکل‌هایي شناسایي و احراز هویت را انجام مي‌دهند.
6 (21) مدیریت احراز هویت ناموفق (FIA_AFL.1.2)
زماني که تعداد تلاش‌های ناموفق صورت گرفته برای احراز هویت به حد تعيين شده رسيد، توابع امنيتي هدف ارزیابي باید اقداماتي را که بدین منظور در نظر گرفته شده است [منع کردن کاربر از اجرای فعاليت‌هایي که مستلزم احراز هویت است تا زماني که اقدامي توسط سرپرست امنيتي صورت گيرد، یا تا زماني که بازه زماني تعریف شده توسط سرپرست منقضي شود] انجام دهند. نکات کاربردی: از آنجا که نيازی به قفلکردن حساب کاربری سرپرست دیده نمي‌شود، این الزام برای سرپرستان محلي به کار برده نمي‌شود. بدین منظور حساب کاربری سرپرست محلي از سایر حساب‌های کاربری مجزا مي‌شود. جداسازی حساب کاربری سرپرست از کاربران مي‌تواند در سند مربوط به سرپرست بيان شود یا سازوکار احراز هویت هدف ارزیابي، مي‌تواند تلاش‌های ورود محلي به سيستم را از تلاش‌های ورود از راه دور به سيستم متمایز کند.
7 (22) تعریف مشخصه‌های کاربری (هویت کاربر انسانی) (FIA_ATD.1.1)
توابع امنيتي هدف ارزیابي، باید مشخصه‌های امنيتي زیر را برای هر کاربر نگهداری کند: شناسه کاربر: نقش؛ [انتخاب: [اختصاص: هر ویژگي امنيتي مربوط به شناسه کاربر (همانند گواهينامه مرتبط با شناسه کاربر)]، هيچکدام]؛ و [انتخاب: [اختصاص: دیگر ویژگي‌های امنيتي کاربر]، هيچکدام]] نکات کاربردی: این الزام برای کاربران مجاز، سرپرستان و موجودیت‌های IT مجاز به کار برده مي‌شود. با توجه به این الزام مي‌توان چندین شناسه کاربری برای یک کاربر در نظر گرفت. در نتيجه اجازه داده مي‌شود که برای یک کاربر انساني نقش‌های متعددی در نظر گرفته شود، البته لازم است شناسه کاربری در ارتباط با نقش معين، احراز هویت شود. منظور از مرتبط کردن یک شناسه کاربری به یک نقش آن است که اگر نقش سرپرستي در معرض خطر قرار گيرد، ميزان آسيب به حداقل برسد. اگر یک هدف ارزیابي خاص، دارای صفات مختلفي برای سرپرستان و موجودیت‌های IT مجاز باشد، انتظار مي‌رود نویسنده هدف ارزیابي، این الزام را تنها یکبار برای هر مجموعه از کاربران تکرار کند تا تفاوت‌ها منعکس شود.
8 (25) تعریف صفات کاربر (شناسایی هدف ارزیابی به هدف ارزیابی) (FIA_UAU.2.1)
توابع امنيتي هدف ارزیابي، باید هر کاربر را پيش از آنکه امکان انجام اقدامات مياني دیگری از سوی او وجود داشته باشد، با موفقيت احراز هویت کند.
9 (33) مدیریت داده های توابع امنيتی هدف ارزیابی (FMT_MTD.1.1)
توابع امنيتي هدف ارزیابي باید توانایي مدیریت داده‌های توابع امنيتي هدف ارزیابي را تنها به سرپرست امنيتي محدود کند. نکات کاربردی: عبارت «مدیریت» مي‌تواند شامل انجام موارد زیر باشد، اما تنها به این موارد نيز محدود نمي‌شود: ایجاد، مقداردهي، مشاهده، تغيير پيش‌فرض، تغييردادن، حذف کردن، پاک کردن و اضافه کردن این الزام به طور پيش‌فرض برای مدیریت داده توابع امنيتي هدف ارزیابي درنظرگرفته مي‌شود. به عنوان مثال داده‌های توابع امنيتي هدف ارزیابي مي‌تواند شامل اطلاعات رمزنگاری باشد و همچنين مدیریت این داده‌ها شامل مرتبط کردن یک پروتکل رمزنگاری به یک واسط مي‌باشد.
10 (34) مشخصات عملکردهای مدیریتی (FMT_SMF.1.1)
توابع امنيتي هدف ارزیابي باید توانایي اجرای عملکردهای مدیریتي زیر را داشته باشد: توانایي سرپرستي کردن هدف ارزیابي به صورت محلي و از راه دور توانایي بهروزرساني هدف ارزیابي و تأیيد صحت بهروزرساني با استفاده از روش [انتخاب: امضای دیجيتال، کد درهم‌سازی منتشر شده، بدون سازوکار دیگر] پيش از آنکه بهروزرساني نصب شود. [انتخاب: توانایي پيکربندی ليستي از سرویس‌های در دسترس ارائه‌شده توسط هدف ارزیابي، پيش از آنکه یک موجودیت به صورت مشخص شده در FIA_UIA_EXT شناسایي و احراز هویت شود. توانایي پيکربندی توابع رمزنگاری بدون هيچ قابليت دیگری] نکات کاربردی: هدف ارزیابي باید ارائهدهنده عملکردی برای سرپرستي از راه دور و محلي باشد، همچنين باید امکاني را برای سرپرستان فراهم کند تا بتوانند به‌روزرساني‌های دریافت‌شده از منبع امن را تأیيد نمایند. سرپرست باید بتواند این‌گونه اقدامات را با استفاده از امضای دیجيتال و کد درهم‌سازی منتشر شده، انجام دهد. نویسنده هدف امنيتي، در اولين «انتخاب» باید مشخص کند به‌روزرساني‌ها چگونه تأیيد مي‌شوند. هر انتخاب در این قسمت باید با انتخاب در الزام «FPT_TUD_EXT» مطابقت داشته باشد. چنانچه هدف ارزیابي این توانایي را به سرپرست بدهد تا سرویس‌های در دسترس را پيش از شناسایي و احراز هویت پيکربندی کند، یا اگر هر عملکرد رمزنگاری بر روی هدف ارزیابي بتواند پيکربندی شود، بنابراین نویسنده هدف امنيتي مورد مناسب را انتخاب ميکند، یا در دومين انتخاب، عبارت «بدون هيچ قابليت دیگری» را انتخاب مي‌کند.
11 (38 تا 44) مدیریت رفتار توابع امنیتی (FMT_MOF.1.1)
توابع امنیتی هدف ارزیابی باید قابلیت‌های ذیل را به ]سرپرست امنیتی[ محدود کنند. تغيير رفتار توابع [خودآزمایي توابع امنيتي هدف ارزیابي (FPT_TST_EXT)[ فعال کردن و غيرفعال کردن توابع [خودآزمایي توابع امنيتي هدف ارزیابي FPT_TST] فعال کردن، غيرفعال کردن، تعيين و تغيير رفتار توابع مميزی امنیت فعال کردن، غيرفعال کردن، تعيين و تغيير رفتار توابع آناليز مميزی امنيت؛ و مميزی امنيت فعال کردن، غيرفعال کردن توابع هشدارهای امنيتي تعيين رفتار توابع ذیل: [تخصيص منابع اتصال‌گرای کنترل شده؛ شناسه شبکه یک سرپرست مشخص؛ تنظيم کردن شناسه شبکه یک سرپرست خاص؛ دوره زماني یک سرپرست مشخص] فعال‌سازی، غير فعال‌سازی، تعيين و تغيير رفتار توابع [اداره شکست احراز هویت (FIA_AFL مربوط به الزام 29 و 30 مودم)، تنظيم یک عدد مثبت و غير صفر از تلاش‌های ناموفق احراز هویت مربوط به احراز هویت کاربر را]
12 (45 و 46) مدیریت مشخصه‌های امنیتی
توابع امنيتي هدف ارزیابي باید [خط‌مشي عملکرد امنيتي جریان اطلاعاتي نامعتبر/معتبر] را اجرا کند، تا قابليت [انتخاب: تغيير-پيش‌فرض، پرس‌وجو، تغيير دادن، حذف کردن، [اختصاص: دیگر عمليات‌ها]] مشخصه‌های امنيتي [درصد قابل تنظيم ظرفيت ذخيره‌سازی، [اختصاص: ليستي از مشخصه‌های امنيتي]] به [سرپرست امنيتي، [نقش‌های معرفي شده مجاز]] محدود کند.
13 (52 تا 58 به جز 57) مدیریت داده‌های توابع امنیتی هدف ارزیابی (FMT_MTD)
توابع امنيتي هدف ارزیابي، باید قابليت‌های ذیل را به [سرپرست‌های موجودیتهای IT مجاز] محدود کند: [انتخاب: تغيير-پيش‌فرض، پرس‌وجو، تغيير دادن، حذف کردن، پاک کردن [انتخاب: [اختصاص: دیگر عمليات‌ها]، هيچکدام]] تمام [داده‌های توابع امنيتي هدف ارزیابي به جز داده‌های تضمين رمزنگاری و زمان و تاریخي که به صورت مهرهای زماني در FPT_STM استفاده مي‌شود[ تغيير دادن [داده امنيت رمزنگاری] ]تنظيم کردن] [زمان و تاریخي که به صورت مهرهای زماني در FPT_STM استفاده مي‌شود[ پرس‌و‌جو، تغيير دادن، حذف کردن، ایجاد[ انتخاب: [اختصاص: دیگر عمليات‌ها]، هيچکدام] [قوانين خط‌مشي جریان اطلاعات] تعيين محدوده برای [ظرفيت بر روی اتصالات لایه انتقال] تعيين محدوده برای [ظرفيت منابع اتصال‌گرای کنترل شده]
14 (62) لغو (FMT_REV.1.1)
توابع امنيتي هدف ارزیابي، باید قابليت لغو مشخصه‌های امنيتي مرتبط با [انتخاب: کاربران، موجودیت فعال، موجودیت غيرفعال، [اختصاص: دیگر منابع اضافي]] در داخل TSC58 را به [سرپرست امنيتي] محدود کند.
15 (64) مشخصات عملکردهای مدیریتی (FMT_SMF.1.1)
توابع امنيتي هدف ارزیابي، باید قادر به انجام عملکرد مدیریت امنيتي زیر باشد: محدود کردن قابليت اتخاذ تصميم و تغيير رفتار عملکرد خودآزمایي توابع امنيتي هدف ارزیابي (FPT_TST_EXT) به سرپرست امنيتي محدود کردن قابليت فعال کردن و غير فعال کردن عملکرد خودآزمایي توابع امنيتي هدف ارزیابي (FPT_TST_EXT) به سرپرست رمزنگاری محدود کردن قابليت فعال کردن، غير فعال کردن، تعيين و تغيير رفتار عملکرد تحليل مميزی امنيت به سرپرست مميزی محدود کردن قابليت فعال کردن، غير فعال کردن، تعيين و تغيير رفتار عملکرد تحليل مميزی امنيت؛ و مميزی امنيت به سرپرست امنيتي محدود کردن قابليت فعال کردن، غير فعال کردن عملکرد هشدار امنيتي (م‌ا-پ‌س) به سرپرست امنيتي محدود کردن قابليت تعيين رفتار عملکردهای زیر به سرپرست: اختصاص منابع اتصال‌گرای کنترل شده شناسه شبکه مختص سرپرست تنظيم شناسه شبکه مختص سرپرست بازه زماني مختص سرپرست به اجرا گذاردن حداکثر ظرفيت مختص سرپرست از منابع زیر: [منابع اتصال‌گرای کنترل شده] که کاربران در ارتباط با [شناسه شبکه مختص سرپرست و تنظيم شناسه شبکه مختص سرپرست] مي‌توانند بر روی یک بازه زماني مختص سرپرست استفاده شوند. اجرای [خطمشيهای عملکرد امنيتي جریان اطلاعات نامعتبر] تا مقادیر پيشفرض مشخصههای امنيتي که برای اجرای خط‌مشي‌های عملکرد امنيتي استفاده مي‌شوند را محدود کند. اجرای ]خط‌مشي‌های عملکرد امنيتي جریان اطلاعات معتبر[ تا مقادیر پيش‌فرض مشخصه‌های امنيتي که برای اجرای خط‌مشي‌های عملکرد امنيتي استفاده مي‌شوند را محدود کند. محدود کردن قابليت [انتخاب: تغيير پيش‌فرض، پرس‌وجو، تغيير دادن، حذف کردن، پاک کردن، [انتخاب: [اختصاص: دیگر عمليات‌ها]، هيچکدام]] تمام [ داده‌های توابع امنيتي هدف ارزیابي به جز داده‌های امنيتي رمزنگاری و زمان و تاریخي که به صورت مهر زماني در FPT_STM استفاده مي‌شود] به سرپرستان و موجودیت‌های IT مجاز (FMT_MTD) محدود کردن قابليت تغيير دادن داده امنيتي رمزنگاری به سرپرست رمزنگاری (FMT_MTD) محدود کردن قابليت تنظيم زمان و تاریخ استفاده شده به صورت مهرهای زماني در FPT_STM به سرپرست‌های امنيتي یا موجودیت‌های IT مجاز. محدود کردن قابليت پرس‌وجو، تغيير دادن، حذف کردن، ایجاد کردن، [انتخاب: [اختصاص: دیگر عمليات‌ها]، هيچکدام] قوانين مربوط به خط‌مشي جریان اطلاعات به سرپرست امنيتي (FMT_MTD) محدود کردن قابليت لغو مشخصه‌های امنيتي مرتبط با [انتخاب: کاربران، موجودیت‌های فعال، موجودیت‌های غير فعال، [اختصاص: دیگر منابع اضافي]] در داخل TSC به سرپرست‌های امنيتي محدود کردن مشخصات محدوده ظرفيت بر روی اتصالات لایه انتقال به سرپرست‌های امنيتي (FMT_MTD) محدود کردن مشخصات محدوده ظرفيت بر روی منابع اتصال‌گرای کنترل شده به سرپرست‌های امنيتي (FMT_MTD) محدود کردن مشخصات محدوده برای درصد ظرفيت ذخيره‌سازی برای رکوردهای مميزی (FMT_MTD) به سرپرست امنيتي محدود کردن قابليت فعال کردن، غيرفعال کردن، تعيين و تغيير رفتار عملکرد اداره کردن شکست‌های احراز هویت (FIA_AFL مربوط به الزامات 29 و 30 مودم) تا تنظيم عدد صحيح مثبت و غير صفر از تعداد تلاش‌های احراز هویت ناموفق مربوط به احراز هویت کاربر به سرپرست امنيتي [اختصاص: ليستي از عملکردهای مدیریتي امنيتي اضافي ارائه شده توسط محيط IT] نکات کاربردی: خط‌مشی‌های عملکرد امنیتی برای جریان اطلاعات معتبر و نامعتبر توسط سازمان و با توجه به کاربرد مسیریاب تعریف می‌شود.
16 (69) در دسترس بودن بين توابع امنيتی هدف ارزیابی توسط معيارهای مشخص (FPT_ITA.1.1)
توابع امنيتي هدف ارزیابي باید از در دسترس بودن [اختصاص: ليستي از انواع داده‌های توابع امنيتي هدف ارزیابي] که برای دیگر محصولات معتبرِ IT به صورت راه دور ارسال مينمایند، بر اساس [اختصاص: معيارهای مشخص در جهت اطمينان از ارائه دسترسي]، تحت شرایط [اختصاص: شرایطي که تضمين‌کننده دسترسي داده‌ها مي‌باشد] اطمينان حاصل کنند. نکات کاربردی: مسيریاب باید نسبت به پيروی کردن مشخصات برای پروتکل‌های مسيریابي مختلف که برای ارسال مجدد و دسترس‌پذیری داده‌های مسيریابي به مسيریاب‌های همتا استفاده مي‌شود، اطمينان یابد.
17 (70) محرمانگی داده‌های ارسال شده بين توابع امنيتی هدف ارزیابی (FPT_ITC.1.1)
توابع امنيتي هدف ارزیابي باید از کليه داده‌های انتقال یافته از خود به دیگر محصولات معتبرِ IT راه دور، در مقابل آشکارسازی و افشای غيرمجاز، در طول فرآیند انتقال، محافظت کند. نکات کاربردی: این الزام از مسيریابي و مسيریابي مربوط به به‌روزرساني‌های بين دو مسيریاب محافظت مي‌کند. یک مثال استفاده از پروتکل اینترنت نسخه 6 (IPv6) و پروتکل اینترنت امنيتي (IPSEC) مي‌باشد، به گونه‌ای که یک مسيریاب مي‌تواند جدول مسيریابي ارتباطات و احراز هویت با مسيریاب همتا را رمزنگاری کند. این روشي است که از محرمانگي منابع شبکه محافظت مي‌کند.
18 (71) تشخيص تغييرات بين توابع امنيتی هدف ارزیابی (FPT_ITI.1.1)
توابع امنيتي هدف ارزیابي باید بر اساس [اختصاص: معيار تغيير تعریف‌شده]، در هنگام نقل و انتقال داده‌ها بين خود و محصولات معتبر IT راه دور، قادر به شناسایي تغييرات در تمام داده‌ها باشند.
19 (72) تشخيص تغييرات بين توابع امنيتی هدف ارزیابی (FPR_ITI.1.2)
توابع امنيتي هدف ارزیابي باید توانایي بررسي یکپارچگي تمام داده‌های توابع امنيتي هدف ارزیابي که در حال انتقال بين توابع خود و محصولات معتبر IT راه دور، مي‌باشند را فراهم نموده و در صورت تشخيص تغييرات، [اختصاص: اقدامات مشخصي] را انجام دهند. نکات کاربردی: این الزام از مسيریابي و مسيریابي مربوط به به‌روزرسانيهای بين دو مسيریاب محافظت ميکند. یک مثال استفاده از پروتکل اینترنت نسخه 6 (IPv6) و پروتکل اینترنت امنيتي (IPSEC) مي‌باشد، به گونه‌ای که یک مسيریاب مي‌تواند ارتباطات همتا را به وسيله رمزنگاری جدول مسيریابي ارتباطات و احراز هویت با مسيریاب همتا، محافظت و آشکارسازی کند.
20 (73) استفاده از پروتکل استاندارد (FPT_PRO_(EXT).1.1)
توابع امنيتي هدف ارزیابي باید از سازوکارهای پروتکل استاندارد در داخل پروتکل‌های استاندارد استفاده کند. [انتخاب: [اختصاص: BGP59 ليستي از پروتکل‌های استاندارد]]
21 (74) محافظت از داده‌های توابع امنيتی هدف ارزیابی (FPT_SKP_EXT)
توابع امنيتي هدف ارزیابي باید از خوانده شدن تمام کليدهای از پيش به اشتراک گذاشته شده، کليدهای متقارن و کليدهای خصوصي جلوگيری کند. نکات کاربردی: منظور این الزام آن است که یک سرپرست قادر به خواندن یا مشاهده کليدهای شناسایي شده از طریق واسط‌های «معمول» نمي‌باشد. در حالي که قابل درک است که سرپرست مي‌تواند برای مشاهده این کليدها، مستقيماً حافظه را بخواند. از این رو سرپرست به عنوان یک عامل امن در نظر گرفته مي‌شود و فرض مي‌شود که تلاشي در این مورد نمي‌کند.
22 (75) حفاظت از کلمه‌های عبور سرپرست (FPT_APW_EXT.1.1)
توابع امنيتي هدف ارزیابي باید کلمه‌های عبور را به صورت متن آشکار ذخيره نکنند.
23 (78) بازیابی خودکار (FPT_RCV.2.2)
توابع امنيتي هدف ارزیابي باید این اطمينان را بدهند که برای [اختصاص: ليستي از شکست‌ها/سرویس‌های منقطع]، هدف ارزیابي را با استفاده از رویه‌های خودکار به یک حالت امن برمي‌گردانند.
24 (81) مهرهای زمانی قابل اطمينان (FPT_STM.1.1)
توابع امنيتي هدف ارزیابي، باید قادر به ایجاد مهرهای زماني قابل اطمينان برای استفاده هدف ارزیابی باشند.
25 (84 تا 86) به‌روزرسانی امن (FPT_TUD_EXT)
توابع امنيتي هدف ارزیابي باید به سرپرستان امنيتي این قابليت را بدهند تا بتوانند نسخه فعلي نرم‌افزار/ميان‌افزار هدف ارزیابي را پرس‌وجو و مشاهده نمایند. توابع امنيتي هدف ارزیابي باید به سرپرستان امنيتي این قابليت را بدهند تا بتوانند فرایند به‌روزرساني نرم‌افزار/ميان‌افزار هدف ارزیابي را انجام دهند توابع امنيتي هدف ارزیابي باید به وسيله روشي قبل از به‌روزرساني هدف ارزیابي، با استفاده از [انتخاب: سازوکارهای امضای دیجيتال، مقادیر درهم‌سازی منتشر شده] از صحت به‌روزرساني نرم‌افزاری/ميان‌افزاری اطمينان حاصل نمایند. نکات کاربردی: نویسنده هدف امنيتي باید سازوکارهای پياده‌سازی شده توسط هدف ارزیابي را انتخاب کند.
26 (87 تا 88) خودآزمایی توابع امنیتی هدف ارزیابی (FPT_TST_EXT)
توابع امنيتي هدف ارزیابي باید مجموعه‌ای از خودآزمایي‌ها را در حين راه‌اندازی اوليه و همچنين به صورت دوره‌ای در حين عمليات عادی سيستم، یا در زمان درخواست از کاربر مجاز اجرا نمایند، تا نشان‌دهنده عملکرد صحيح توابع امنيتي هدف ارزیابي باشد. توابع امنيتي هدف ارزیابي باید قابليت تأیيد یکپارچگي و صحت کد اجرایي ذخيره‌شده توابع امنيتي هدف ارزیابي را از طریق استفاده از سرویس‌های رمزنگاری ارائه شده برای سرپرستان مجاز فراهم کند.
27 (89 تا 94) خودآزمایی توابع امنیتی هدف ارزیابی (FPT_TST)
توابع امنيتي هدف ارزیابي باید مجموعه‌ای از خودآزمایي‌ها را مطابق با 2-140 PUB FIPS در حين راه‌اندازی اوليه (یا روشن شدن)، یا در زمان درخواست از کاربر مجاز، تحت شرایط مختلفي که در بخش 1.9.4 از 2-140 FIPS تعریف شده است، به طور متناوب (حداقل یکبار در روز) اجرا کند، تا نشان‌دهنده عملکرد صحيح توابع رمزنگاری زیر باشد: تشخيص خطای کليد الگوریتم‌های رمزنگاری PNG/PRNG توابع امنيتي هدف ارزیابي باید قابليت تأیيد یکپارچگي داده‌های توابع امنيتي هدف ارزیابي مربوط به رمزنگاری را با استفاده از عملکرد رمزنگاری ارائه شده توسط توابع امنيتي هدف ارزیابي برای سرپرستان رمزنگاری مجاز ارائه کند. توابع امنيتي هدف ارزیابي باید تأیيد یکپارچگي کد اجرایي ذخيره‌شده توابع امنيتي هدف ارزیابي مربوط به رمزنگاری را با استفاده از عملکردهای رمزنگاری ارائه شده توسط توابع امنيتي هدف ارزیابي برای سرپرستان رمزنگاری مجاز فراهم کند. توابع امنيتي هدف ارزیابي باید آزمون‌های خودآزمایي را بلافاصله پس از توليد کليد اجرا کند تا عملکرد صحيح هر یک از مؤلفه‌های توليد کليد را نشان دهد. اگر هر کدام از این آزمون‌ها با شکست مواجه شود، کليد توليد شده نباید مورد استفاده قرار بگيرد، ماژول رمزنگاری باید در صورت نياز توسط 2-140 PUB FIPS به خودآزمایي‌های منجر به شکست، عکسالعمل نشان دهد و این رویداد مميزی شود. توابع امنيتي هدف ارزیابي باید قابليت تأیيد یکپارچگي داده‌های توابع امنيتي هدف ارزیابي مربوط به توليد کليد را با استفاده از عملکرد رمزنگاری ارائه شده توسط توابع امنيتي هدف ارزیابي به سرپرستان رمزنگاری مجاز ارائه کند. توابع امنيتي هدف ارزیابي باید قابليت تأیيد یکپارچگي کد اجرایي ذخيره‌شده توابع امنيتي هدف ارزیابي مربوط به توليد کليد را با استفاده از عملکردهای رمزنگاری ارائه شده توسط توابع امنيتي هدف ارزیابي برای سرپرستان رمزنگاری مجاز فراهم کند.
28 (95 و 96) حداکثر ظرفيت (FRU_RSA)
توابع امنيتي هدف ارزیابي باید حداکثر ظرفيت منابع زیر را اجرا کند: [نمایش لایه انتقال] که یک شناسه موجودیت فعال مبدأ مي‌تواند بيش از بازه زماني مشخص شده استفاده شود. توابع امنيتي هدف ارزیابي باید حداکثر ظرفيت منابع [منابع اتصال‌گرای کنترل‌شده] را که توسط سرپرست مشخص شده است اجرا کند که کاربران مرتبط با [شناسه شبکه مشخص شده توسط سرپرست و مجموعه‌ای از شناسه‌های شبکه مشخص شده توسط سرپرست] بتوانند بيش از دوره زماني مشخص شده توسط سرپرست استفاده کنند. نکات کاربردی: "نمایش لایه انتقال" به طور خاص به حملات SYN TCP اشاره دارد، در جایي که اتصالات نيمه باز برقرار شده است، بنابراین جدول اتصالات منابع را تهي مي‌کند. انتخابات برای این الزام پالایش مي‌شود تا شناسه موجودیت فعال منبع را مشخص کند که خيلي دقيقتر از کاربر یا موجودیت فعال در زمينه مسيریاب است. چنانچه هدف ارزیابي، پروتکل TCP/IP را پياده‌سازی نکند، این الزام نوع مشابهي از موجودیت لایه انتقال برای پشته پروتکل هدف ارزیابي اعمال مي‌کند.
29 (97) قفل‌کردن نشست های شروع شده توسط توابع امنيتی هدف ارزیابی (FTA_SSL_EXT.1.1)
توابع امنيتي هدف ارزیابي باید برای نشست‌های تعاملي محلي پس از یک دوره زماني غيرفعال مشخص تعریف شده توسط سرپرست امنيت [انتخاب: قفلکردن نشست؛ غيرفعال‌سازی کليه فعاليت‌های مربوط به دسترسي داده‌های کاربر/دستگاه‌های نمایش. نياز است قبل از باز کردن نشست، توابع امنيتي هدف ارزیابي، سرپرست را دوباره احراز هویت کند. خاتمهدادن نشست].
30 (98) قفلکردن نشستهای شروعشده توسط توابع امنيتی هدف ارزیابی (FTA_SSL.3.1)
توابع امنيتي هدف ارزیابي باید نشست تعاملي راه دور را پس از ]بازه زماني نشست غيرفعال قابل پيکربندی توسط سرپرست امنيت[ خاتمه دهد.
31 (101) ایجاد نشست هدف ارزیابی (FTA_TSE.1.1)
توابع امنيتي هدف ارزیابي، باید قادر به انکار نشست‌های ایجاد شده بر اساس [اختصاص: ویژگي‌ها] باشد.
32 (102) کانال مطمئن داخلی توابع امنيتی هدف ارزیابی (FTP_ITC)
توابع امنيتي هدف ارزیابي، باید کانال ارتباطي امني با استفاده از [انتخاب: IPsec، SSH، TLS، HTTPS/TLS] ميان خود و سایر محصولات فناوری اطلاعات مطمئن فراهم کند که از قابليت‌های زیر پشتيباني مي‌کنند: سرور مميزی [انتخاب: سرور احراز هویت، [اختصاص: دیگر قابليت‌ها]] که به طور منطقي از سایر کانال‌های ارتباطي جدا است و به صورت مطمئن نقطه پایاني‌اش را شناسایي مي‌کند و از داده‌های کانال در برابر تغيير یا افشاء، محافظت کند.
33 (105) مسير مطمئن (FTP_TRP.1.1)
توابع امنيتي هدف ارزیابي، باید مسير ارتباطي امني با استفاده از [انتخاب، انتخاب حداقل یکي از: IPsec، SSH، TLS، HTTPS/TLS] ميان خود و سرپرست از راه دور فراهم کند که به صورت منطقي از دیگر مسيرهای ارتباطي مجزا مي‌باشد و نقاط پایاني خود را به صورت مطمئن شناسایي و از داده‌های تبادلي در برابر تغيير و افشاء محافظت مي‌کند و تغييرات داده‌های تبادلي را مشخص مي‌کند.

  1. پیوست فنی

این ضمیمه با جزییات بیشتری به بررسی مودم LTE و جایگاه آن در شبکه‌های LTE و نیز پروتکل‌ها و مکانیزم‌های مورد استفاده برای انجام اتصالات می‌پردازد.

  1. مروری بر معماری شبکه‌های LTE و جایگاه مودم‌های LTE در این ساختار

به طور کلی منظور از یک شبکه سلولی60 عبارت است از یک شبکه بی‌سیم متشکل از مجموعه‌ای از سایت‌های سلولی مجهز به تجهیزات رادیویی که با فراهم کردن یک سطح پوشش جغرافیایی توزیع شده امکان اتصال کاربران مستقر در نقاط مختلف را به این شبکه فراهم می‌کنند. به طور معمول هر کدام از این سایت‌های سلولی توسط یک اپراتور شبکه موبایلی61 مدیریت می‌شود، اما در برخی موارد تمام یا بخشی از ظرفیت سایت‌ها توسط اپراتورها اجاره می‌شوند که در این صورت از عنوان اپراتور مجازی شبکه موبایلی62 برای آن‌ها استفاده می‌شود. در صورتی که پوشش رادیویی در یک نقطه ضعیف باشد، اپراتورها ممکن است از تقویت کننده‌های رادیویی یا سلول‌های کوچک63 استفاده کنند که خود با تهدیدات امنیتی مختلفی برای مودم‌ها می‌تواند همراه باشد که در ادامه سند بررسی شده ‌است.

بر خلاف شبکه‌های‌های 2G و 3G که از تکنولوژی‌های مبتنی بر سویچینگ مداری 64 GSM و UMTS65 برای اتصالات مبتنی بر صدا و برای اتصالات غیر-صدا از افزونه‌های مبتنی بر سویچینگ بسته، شامل 66 GPRS (به عنوان 2.5G)، 67 EDGE (به عنوان 2.75G) و 68 HSPA (به عنوان 3.5 G و استاندارد اولیه در 4G)، استفاده می‌کردند، شبکه 69 LTE به طور یکپارچه از تکنولوژی سوئیچینگ بسته استفاده کرده و یک اتصال مطمئن IP میان مودم کاربر (اینجا مودم LTE) و سرویس‌دهنده شبکه دیتا فراهم می‌کنند، بدون اینکه جابجایی کاربر خللی جدی در این اتصال وارد آورد. به عنوان یک تکنولوژی باند گسترده که توسط سازمان 3GPP تعریف شده، تکنولوژی LTE اهداف زیر را دنبال می‌کند:

  1. افزایش سرعت ارسال داده و کاهش تأخیر

  2. افزایش امنیت

  3. پشتیبانی و امکان کار با تکنولوژی‌های فعلی (مانند 3G) و آینده )مانند (5G

  4. بهبود کارکرد سیستم و کیفیت سرویس

    1. اجزای یک شبکه LTE

همچنان که در شکل ‏10-1 نشان داده شده است، یک شبکه LTE از چهار مؤلفه‌ زیر تشکیل می‌شود:

  1. مودم LTE یا هر مودم دیگری مانند گوشی موبایل که قصد اتصال به شبکه را دارد.
  2. شبکه E-UTRAN که اولین نقطه اتصال مودم به شبکه بوده و از مجموعه‌ای از ایستگاه‌های پایه‌70 رادیویی یا base station تشکیل می‌شود. این ایستگاه‌های رادیویی در شبکه‌های LTE تحت عنوان Evolved Node B یا به طور خلاصه eNodeB نام‌گذاری‌شده و از این رو در ادامه سند از این نام برای آن استفاده خواهیم کرد.
  3. شبکه EPC که اتصال مودم به شبکه IP را مدیریت و برقرار می‌کند.
  4. شبکه IP که مقصد کاربر برای اتصال به اینترنت است.

شکل ‏10-1 اجزای اصلی یک شبکه LTE

در ادامه ضمن تمرکز روی اجزای اصلی مودم برای اتصال به شبکه، به طور کوتاه دیگر مؤلفه‌‌های شبکه LTE را نیز توضیح خواهیم داد.

  1. مودم LTE

به طور کلی یک مودم یا هر مودم LTE سمت کاربر از اجزای نرم‌افزاری و سخت‌افزاری اصلی زیر تشکیل می‌شود:

  1. یک زیر سیستم تلفنی71 برای مدیریت اتصال با ایستگاه‌های پایه (eNodeB) جهت برقراری ارتباط با شبکه LTE:
    این زیر سیستم تلفنی خود شامل اجزای زیر است:

    1. یک پردازنده اختصاصی تحت عنوان پردازنده باند پایه است که سیستم‌عامل مخصوص به خود را دارا بوده و پردازش سیگنال دریافتی یا ارسالی بر عهده آن خواهد بود.
    2. یک عدد سیم‌کارت LTE که تحت عنوان UICC72 نیز شناخته می‌شود. این سیم‌کارت‌ها هوشمند بوده و یک برنامه مبتنی بر زبان جاوا تحت عنوان اختصاری 73 USIM را اجرا می‌کنند که اینترفیس نرم‌افزاری لازم برای اتصال به eNodeB را فرهم می‌کند.

    سیم‌کارت‌ شامل اطلاعات شخصی کاربر و همچنین دو مؤلفه‌ مهم دیگر شامل کلید رمزنگاری و فیلد هویتی IMSI74 است که هویت یک کاربر (اینجا مودم) را به صورت یک موجودیت یکتا به شبکه سلولی معرفی می‌کند.

    مؤلفه‌ هویتی بعدی به طور اختصار 75 IMEI نامیده می‌شود که هویت مودم را به صورت یکتا مشخص کرده و معمولاً در حافظه مودم ذخیره می‌شود و نه در سیم‌کارت. علاوه بر این در حالت پیشرفته ممکن است اپراتور شبکه از یک فیلد هویتی موقتی بنام 76 GUTI استفاده کند تا از ارسال IMSI در شبکه و خطرات امنیتی ناشی از آن جلوگیری شود.

  2. یک سیستم‌عامل عمومی (مانند لینوکس) که برای مدیریت مودم و اتصالات آن به دیگر تجهیزات موجود در شبکه کاربر روی آن نصب شده است.

همچنان که در شکل ‏10-2 نشان داده شده است، وظیفه اصلی تعریف شده برای یک مودم LTE برقراری ارتباط با شبکه LTE از طریق مدوله کردن سیگنال دیجیتال به صورت آنالوگ و ارسال آن به ایستگاه رادیویی همتا77 شده‌ eNodeB روی باند رادیویی تعریف‌شده برای شبکه‌های LTE و دمدوله کردن آن در جهت معکوس است.

از سویی دیگر، ضمن فراهم کردن این اتصال، مودم مربوطه می‌تواند به یک روتر متصل باشد که این روتر دسترسی به اینترنت فراهم شده توسط مودم را برای تجهیزات و کاربران موجود در شبکه داخلی کاربر فراهم خواهد کرد. به عبارتی دیگر نقطه دسترسی یا access point برای کاربران اینترنت فراهم می‌کند. امروزه بسیاری از تجهیزات موجود در بازار که تحت عنوان مودم‌ LTE فروخته می‌شوند، هر سه نقش مودم، روتر و نقطه دسترسی را فراهم می‌کنند، ولی لزومی برای این کار نبوده و کارکرد اختصاصی تعریف شده برای مودم همان مواردی است که بیان شد. از این رو، تمرکز اصلی این سند عمدتاً در تعریف کارکردهای امنیتی مورد نیاز برای کانال اتصالی مودم به شبکه LTE بوده و در نظر گرفتن نقش‌های اضافه‌ای چون روتر و فراهم کننده نقطه دسترسی خارج از هدف این پروفایل حفاظتی است. با این حال، برای مودمهایی که این دو قابلیت را دارند، الزامات امنیتی Wi-Fi در فصل 8 و الزامات امنیتی نقش روتر نیز بر طبق سند پروفایل حفاظتی روتر (سند Router PP مورد تأیید افتا مورخ مرداد 93) در فصل 9 آمده است.

شکل ‏10-2 اتصال مودم به یک روتر WiFi

  1. شبکه E-UTRAN

عنوان E-UTRAN نامی است که به فرم توسعهیافته از شبکه‌های دسترسی رادیویی یا 78 RAN در LTE نهاده شده است. همچنان که در شکل ‏10-3 نشان داده شده است، E-UTRAN شامل یک شبکه کاملاً متصل از ایستگاه‌های رادیویی با نام eNodeB است که امکان دسترسی به شبکه LTE را فراهم می‌کنند. اتصالات این شبکه امکان جابجایی یا handover بین مناطق مختلف تحت پوشش ایستگاه‌های eNodeB را فراهم می‌کند. اتصال نودهای eNodeB با یکدیگر از طریق اینترفیس‌هایی با نام X و خطوط فیبر نوری، اترنت، لینک‌های ماهواره‌ای و غیره می‌تواند برقرار شود. هر نود eNodeB شامل تجهیزات رادیویی لازم برای ماژوله و دی ماژوله کردن سیگنال دریافتی یا ارسالی به کاربر است.

شکل ‏10-3 اتصالات ایستگاه‌های eNodeB در یک شبکه E-UTRAN

علاوه بر ایستگاه‌های eNodeB از ایستگاه‌های رادیویی سایز کوچک small cell هم ممکن است برای تقویت پوشش رادیویی در نقاط لازم استفاده شود.

  1. شبکه هسته (Evolved Packet Core) EPC {#شبکه-هسته-(evolved-packet-core)-epc}

EPC هسته‌ اصلی یک شبکه LTE است که امکان برقراری و مدیریت اتصالات جهت استفاده از سرویس Voice_over_LTE یا اتصال به شبکه اینترنت و داده را فراهم می‌کند. این شبکه از یک سو به E-UTRAN و از سوی دیگر به شبکه IP متصل است. لذا اتصال مودم‌های LTE به اینترنت نیز از طریق این بخش فراهم خواهد شد.

شکل ‏10-4 مؤلفه‌‌های اصلی EPC

مؤلفه‌‌های اصلی EPC از قرار زیر است:

  • مؤلفه‌ (Mobility Management Entity) MME: این مؤلفه‌ اولین نقطه‌ای است که مودم LTE برای اتصال به شبکه IP به آن مراجعه خواهد کرد. MME مجموعه مختلفی از اعمال کنترلی اعم از کنترل فرایند احراز هویت مودم، انتخاب S-GW و P-GW برای آن را انجام می‌دهد، ولی ترافیک داده از آن عبور نکرده و وظیفه اصلی آن صرفاً احراز هویت، مدیریت جابجایی مودم و اتصال آن به شبکه داده خواهد بود.

  • مؤلفه‌ (Serving Gateway) S-GW: این مؤلفه‌ انتقال و مسیریابی ترافیک IP میان دروازه ورودی به شبکه داده یعنی P-GW و E-UTRAN را انجام خواهد داد.

  • مؤلفه‌(Packet Data Network Gateway) P-GW : اختصاص آدرس IP به مودم و اتصال آن به شبکه دیتا از وظایف این مؤلفه‌ است.

  • مؤلفه‌(Home Subscriber Server) HSS : این پایگاه داده محلی برای ذخیره داده‌های مختلف کاربران (اینجا مودم) از جمله اطلاعات احراز هویت و کلیدهای رمزنگاری آن‌هاست.

  • مؤلفه‌(Authentication Center) AuC : این مؤلفه‌ ماژول‌های لازم برای احراز هویت کاربر را برای MME فراهم می‌کند.

  • مؤلفه‌(Policy and Charging Rules Function) PCRF : مدیریت فرایند حسابرسی کاربران و إعمال و کنترل مؤلفه‌‌های کیفیت سرویس از وظایف این مؤلفه‌ است.

  • مؤلفه‌(IP Multimedia Subsystem) IMS : اتصال به شبکه تلفن79 و ارائه سرویس صدا در LTE که Voice_over_LTE نامیده می‌شود توسط این مؤلفه‌ کنترل می‌شود که خود اجزای متعدد دیگری دارد که خارج از تمرکز این سند که بررسی سرویس داده است، می‌باشد.

    1. اینترفیس هوایی بین مودم و eNodeB

پس از بررسی معماری یک شبکه LTE و جایگاه مودم‌های LTE در این ساختار، به بررسی اینترفیس یا لینک هوایی80 میان مودم و ایستگاه رادیویی eNodeB می‌پردازیم. برقراری یک اتصال امن در این لینک و به دنبال آن با شبکه یکی از مهمترین کارکردهایی است که از یک مودم انتظار می‌رود. از این رو در ادامه به معرفی پشته پروتکل و پیام‌های مهم ارسالی در این لینک پرداخته و روند اتصال مودم به شبکه LTE را مرور خواهیم کرد.

  1. پشته پروتکل لینک هوایی میان مودم و eNodeB

به طور کلی دو صفحه منطقی فرایند اتصال مودم به eNodeB و شبکه‌ی LTE و سپس ارسال داده را مدیریت می‌کنند: 1) صفحه کنترل81 که مسئول انجام سیگنالینگ و اتصال مودم به شبکه LTE از طریق ارتباط با مؤلفه‌ MME است. 2) صفحه کاربر82 که مسئول مدیریت ارسال داده‌های کاربر مانند داده، صدا و غیره است. به عبارت دیگر ابتدا صفحه کنترل مودم را به شبکه IP متصل کرده و در ادامه صفحه کاربر ارسال داده‌های کاربر را مدیریت خواهد کرد.

همچنین صفحه کنترل خود از دو زیر لایه شامل زیر لایه AS (Access Stratum) و زیر لایه NAS (None-Access Stratum) تشکیل شده است که AS برای اتصال به eNodeB از طریق فرکانس رادیویی و NAS برای ارتباط و اتصال به MME در نظر گرفته شده‌اند. همچنان که قبلاً گفته شده، این MME است که اتصال مودم به شبکه IP را با احراز هویت آن و تعیین دروازه‌های S-GW و P-GW سازماندهی و فراهم می‌کند.

شکل ‏10-5 پشته پروتکل لینک هوایی میان مودم و eNodeB

شکل ‏10-5 پشته پروتکلی در نظر گرفته شده برای تمامی ارتباطات انجام شده در لینک هوایی را نشان می‌دهد. این پشته از چهار لایه یا پروتکل اصلی زیر تشکیل شده است که هر یک مسئولیت مشخصی را برعهده داشته و لایه زیرین برای کلیه پیام‌های ارسالی در صفحه کنترل و کاربر را تشکیل می‌دهند.

  • Packet Data Convergence Protocol (PDCP): مهمترین کارکرد در این لایه تأمین رمزنگاری برای صفحه کاربر است.
  • Radio Link Control (RLC): آمادهسازی بسته‌های داده برای لایه PDCF یا لایه MAC و نیز مدیریت فرایند مرتب‌سازی ترتیب بسته‌ها و در صورت نیاز ارسال مجدد آن‌ها در این لایه انجام می‌شود.
  • Medium Access Control (MAC): انجام مالتی پلکسینگ، کنترل کانال و ارتباط با لایه فیزیکی توسط MAC انجام می‌شود.
  • Physical Access (PHY): مدیریت خطاها در لایه فیزیکی، پردازش سیگنال و مدوله و دمدوله کردن داده روی لینک هوایی از وظایف این لایه است.

همچنان که در دو شکل بعدی نشان داده شده است، بسته‌های هر دو صفحه کنترل و کاربر مبتنی بر چهار لایه مذکور هستند.

شکل ‏10-6 پشته پروتکل برای صفحه کاربر

شکل ‏10-7 پشته پروتکل برای صفحه کنترل (شامل زیرلایه‌های AS و NAS و پروتکل‌های آن‌ها)

پروتکل 83 RRC که در شکل ‏10-7 نشان داده شده است، پروتکل اصلی برای کارکردهای زیر لایه AS است که اعمالی چون ارسال به صورت همهپخشی در فرایند یافتن مؤلفه‌ eNodeB، اتصال با مؤلفه‌ eNodeB مورد نظر و حتی انتقال پیام‌های پروتکل NAS برای ارتباط با MME را انجام می‌دهد.

  1. انواع اتصالات روی لینک هوایی

به طور کلی دو نوع اتصال برای انتقال پیام‌های صفحه کنترل و کاربر برقرار می‌شود که خود شامل زیر اتصالات متعدد می‌شوند:

  1. اتصالات سیگنالینگ رادیویی84 برای انجام سیگنالینگ صفحه کنترل که میان مودم و eNodeB و نیز با مؤلفه‌ MME تشکیل می‌شوند.
  2. اتصالات انتقال داده85 جهت ارسال داده‌ میان مودم و مقصد آن در شبکه IP.

اتصالات سیگنالینگ رادیویی از سه زیر اتصال 86 SRB0، SRB1 و SRB2 تشکیل شده که برای ارسال پیام‌های RRC و NAS برقرار می‌شوند.

با ارسال پیام‌های RRC و NAS، ارتباط مودم با شبکه هسته EPC برقرار شده و مودم آماده ارسال و دریافت داده با شبکه IP خواهد بود. لذا در مرحله بعد اتصالات مورد نیاز برای صفحه کاربر انجام خواهد شد که مهمترین آن‌ها اتصال 87 DBR میان مودم و eNodeB روی لینک هوایی برای ارسال بسته‌های صفحه کاربر است و اینترفیس Uu نیز نامیده می‌شود.

برای تکمیل اتصال میان مودم و مقصد آن در شبکه IP و انتقال بسته‌های صفحه کاربر زیر اتصالات دیگری نیز تشکیل می‌شود که از قرار زیر است.

  • اتصالS1 : این اتصال میان eNodeB وS-GW تعیین شده توسط MME روی اینترفیس S1-U برقرار می‌شود.
  • اتصال E-RAB88 : این اتصال به ترکیب دو اتصال S1 و DBR اطلاق می‌شود که برای ارتباط مستقیم میان مودم و S-GW است.
  • اتصال S5/S: این اتصال میان S-GW و P-GW تشکیل می‌شود.
  • اتصال EPS: منظور از این اتصال ترکیب دو اتصال فوق برای ارتباط مستقیم میان مودم و P-GW است.
  • اتصال خارجی: این اتصال میان P-GW و مقصد مودم در شبکه IP برقرار می‌شود.
  • اتصال انتها به انتها: منظور از این اتصال ترکیبی از اتصالات ذکر شده برای ارتباط مستقیم میان مودم و مقصد آن است.

اتصالات انتقال داده برای صفحه کاربر در شکل ‏10-8 نشان داده شده است.

شکل ‏10-8 اتصالات صفحه کاربر

  1. فرایند اتصال مودم به شبکه

با بررسی پشته پروتکل و نیز اتصالات مورد نیاز، در این بخش به طور مختصر فرایند اتصال مودم به شبکه و پیام‌های ارسالی در کانال‌های ذکر شده را بررسی می‌کنیم.

فرایند اتصال مودم به شبکه با ارسال یک پیام attach request از جانب مودم به نود MME آغاز می‌شود. این درخواست که از نوع پیام‌های NAS است، شامل اطلاعاتی چون شناسه IMSI بوده و توسط eNodeB به نود MME مربوطه ارسال می‌شود. در ادامه MME از نود AuC و پایگاه داده HHS برای احراز هویت کاربر استفاده کرده و درصورت درستی هویت سیم‌کارت مودم، ضمن درخواست شناسه IMEI و تکمیل احراز هویت، با کمک S-GW و P-GW یک اتصال اولیه EPS برای او تشکیل داده و یک شناسه GUTI برای کاربر ساخته می‌شود تا ضمن ذخیره‌سازی در HSS به مودم ارسال شده و در آینده از آن برای اتصال یه شبکه استفاده شود. در ادامه ممکن است اتصالات EPS بیشتری به طور اختصاصی برای کاربر (اینجا مودم) تشکیل شود تا اتصال آن به شبکه IP میسر شود. شکل ‏10-9 با جزییات بیشتر و دقیق‌تری پیام‌های مبادله شده در این فرایند را نشان می‌دهد.

اما از منظر این سند، از میان مراحل انجام شده در طول فرایند اتصال مودم به شبکه، سه مرحله احراز هویت، پیکربندی امنیتی در لایه AS و پیکربندی امنیتی در لایه NAS از اهمیت بالاتری برخوردار هستند. چرا که ضمن احراز هویت دوطرفه میان مودم و شبکه LTE، روی پارامترهای امنیتی مورد نیاز برای تأمین محرمانگی و صحت داده پیام‌های صفحه کنترل و کاربر هم توافق می‌شود.

شکل ‏10-9 پیام‌های ارسالی در فرایند اتصال مودم به شبکه

  1. کلیدهای رمزنگاری روی لینک هوایی

تصویر زیر سلسله مراتب تولید کلید برای لایه‌های ‌مختلف پشته پروتکل لینک هوایی (اینترفیس Uu) را نشان می‌دهد. همان‌طور که مشخص است تمامی این کلیدها از کلید مستر منشعب می‌شوند و مودم و MME هر یک مستقلاً باید قادر به انشعاب این کلیدها از کلید مستر K باشند. شکل بعد نیز طول این کلیدها را مشخص کرده است.

شکل ‏10-10 کلیدهای رمزنگاری در لایه‌های مختلف از پشته پروتکل لینک هوایی

آنچنان که از تصویر فوق برمیاید، در لایه PDCF از کلید رمزنگاری UPenc، در لایه RRC از RRCenc برای رمزنگاری و RRCint برای تأمین صحت داده و در لایه NAS نیز از NASenc و NASint به ترتیب برای رمزنگاری و صحت داده استفاده می‌شود. کلیدهای ذکر شده در سه لایه مذکور به ترتیب برای تأمین امنیت پیام‌های صفحه داده، در صفحه کنترل برای پیام‌های RRC و در صفحه کنترل برای پیام‌های NAS استفاده می‌شوند.

شکل ‏10-11 طول انواع کلیدها در پشته پروتکل لینک هوایی

اما از نظر الزامات امنیتی مدنظر در این سند، همانطور که گفته شد، تأمین محرمانگی و صحت داده برای اتصالات مدیریتی و ترافیک تصدیق شده ضروری است. لذا رمزنگاری و تأمین صحت داده برای پیام‌های RRC و NAS باید اعمال شود، ولی برای اتصالات داده و لایه PDCF که مسئول تأمین امنیت این پیام‌ها است، رمزنگاری پیام‌ها اختیاری خواهد بود. همچنین تأمین صحت داده برای این پیام‌ها مطرح نبوده و همانطور که مشاهده شد کلیدی نیز برای آن تعریف نشده است. شکل ‏10-12 این اتصالات را نشان می‌دهند.

شکل ‏10-12 تأمین محرمانگی و صحت داده برای اتصالات مدیریتی و داده

همچنین شکل بعد، روند توافق روی الگوریتم‌های رمزنگاری و انشعاب کلیدهای رمزنگاری ذکر شده، در طول فرایند اتصال مودم به شبکه LTE را نشان می‌دهد. بیان جزئیات پیام‌های رد و بدل شده خارج از تمرکز این سند است، ولی همانطور که مشخص است هیچ کلیدی روی لینک هوایی ارسال نشده و MME و مودم باید قادر به انشعاب کلیدهای مورد نیاز از کلید مستر K باشند.

شکل ‏10-13 توافق روی الگوریتم‌های رمزنگاری و صحت داده و انشعاب کلیدهای رمزنگاری

برای استفاده از کلیدهای مذکور و تأمین محرمانگی و صحت داده، الگوریتم‌های مورد نیاز نیز توافق می‌شوند. به طور کلی بر اساس استانداردهای NIST و 3GPP سه نوع الگوریتم زیر جهت تأمین محرمانگی و صحت داده در شبکه‌های LTE پیشنهاد شده است (عنوان الگوریتم‌های رمزنگاری برای تأمین محرمانگی با عبارت EEA شروع می‌شود که مخفف عبارت Evolved Packet System Encryption Algorithm است. همچنین الگوریتم‌های تأمین کننده صحت داده نیز با عبارت EIA شناخته می‌شوند که مخفف عبارت Evolved Packet System Integrity Algorithm است):

  1. EEA1 و EIA1 که هر دو مبتنی بر الگوریتم SNOW 3G بوده و بسیار مشابه با الگوریتم مورد استفاده در شبکه‌های UMTS هستند.

  2. EEA2 و EIA2 که مبتنی بر رمزنگاری AES هستند، به طوری که EEA2 مبتنی بر AES در مد CTR بوده و EIA2 مبتنی بر AES-CMAC است.

  3. EEA3 و EIA3 نیز هر دو مبتنی بر رمزنگاری چینی ZUC هستند.

    1. مکانیزم AKA برای احراز هویت دوطرفه

در این بخش به مکانیزم استاندارد احراز هویت دوطرفه میان مودم و مؤلفه‌ MME اشاره می‌کنیم که با نام پروتکل 89 AKA شناخته شده و به عنوان بخشی از فرایند اتصال مودم به شبکه انجام می‌شود. این فرایند باید به طور کامل پیاده‌سازی شود.

در این فرایند مودم و مؤلفه‌ MME از طریق یک کلید رمزنگاری پایه‌ای به نام کلید مستر از هویت یکدیگر اطمینان حاصل می‌کنند. قابل ذکر است که کلید مستر تنها در سیم‌کارت و پایگاه داده HHS ذخیره شده و تنها مودم و MME به آن دسترسی خواهند داشت. تمامی کلید‌های دیگر که جلوتر به آن‌ها اشاره خواهیم کرد از این کلید استخراج می‌شوند.

همچنان که در شکل ‏10-14 نشان داده شده است این فرایند با ارسال شناسه IMSI از جانب مودم به MME آغاز می‌شود. در حالت‌ امن‌تر و در دفعات بعدی به جای ارسال IMSI که یک شناسه ایستا و دائمی است، از شناسه‌های موقتی مانند 90 TMSI و GUTI91 استفاده می‌شود که توسط خود MME صادر شده و برای اتصال‌های بعدی بهتر است از آن‌ها استفاده شود.

شکل ‏10-14 فرایند احراز هویت دوطرفه میان مودم و مؤلفه‌ MME

در گام بعدی مؤلفه‌ MME این شناسه را به همراه پارامترهای رمزنگاری توافق شده با مودم و شناسه‌ شبکه SN id به مؤلفه‌ HSS/AuC ارسال خواهد کرد. در این مرحله HSS/AuC با دادن سه پارامتر شامل یک عدد تصادفی RAND، کلید رمزنگاری مستر K و یک شماره ترتیب SQN به یک تابع رمزنگاری توافق شده، 4 مقدار جدید تولید خواهد کرد: دو کلید رمزنگاری به نام‌های 92 IK و 93 CK، یک توکن احراز هویت AUTN و یک مقدار مورد انتظار با نام XRES. مطابق با مرحله 4 در تصویر فوق پارامترهای مربوطه به MME ارسال می‌شود تا در آن ذخیره گردد. مؤلفه‌ KASME در تصویر فوق کلید رمزنگاری مؤلفه‌ MME است که از دو کلید IK و CK تولید می‌شود. در مرحله 5، توکن احراز هویت AUTN و عدد رندم RAND به مودم ارسال می‌شود. مودم (به طور دقیقتر اپلیکیشن یا سیستم‌عامل سیم‌کارت) نیز با ورودی دادن این مقادیر به همراه کلید رمزنگاری مستر و SQN خود به تابع رمزنگاری توافق شده با MME یک مقدار با عنوان RES را تولید و به MME ارسال می‌کند. در صورتی که مقادیر RES و XRES برابر باشند احراز هویت دوطرفه با موفقیت کامل شده و به مودم مجوز دسترسی به شبکه داده خواهد شد. این فرایند احراز هویت دوطرفه برای کلیه اتصالات روی لینک هوایی تضمین می‌دهد.

واژه‌نامه

جدول ‏10-1 واژه نامه انگلیسی به فارسی

برگردان فارسی واژه انگلیسی
نقطه دسترسی Access Point
سرپرست Admin
لینک هوایی Air Interface
ترافیک تصدیق‌شده Authorized Traffic
شبکه سلولی Cellular Network
گواهی Certificate
کلید رمزنگاری Cipher Key
کاربر - کلاینت Client
امضای کد Code Siging
سند معیار مشترک Common Criteria (CC)
صفحه کنترل – صفحه کاربر Control Plane – User Plane
قابل اثبات Demonstrable
شماره‌های توالی بسط یافته Extended Sequence Numbers
شناسه Identifier
وارد کردن Import
کلید یکپارچگی Integrity Key
استقرار کلید Key Establishment
بازخورد مبهم Obscured Feedback
مجموعه قوانین فیلترینگ بسته Packet Filtering Rule Set
پروفایل حفاظتی Protection Profile (PP)
کلید عمومی Public Key
حمله تکرار Replay Attack
بازگرداندن Reset
وضعیت ابطال Revocation Status
الزام کارکردی امنیتی Security Functional Requirement (SFR)
هدف امنیتی Security Target (ST)
سرور Server
سلول کوچک Small Cell
انطباق سخت Strict Conformance
تابع درهم‌سازی شبه‌تصادفی Sudo Random Function
هدف ارزیابی (مودم) Target of Evaluation (TOE)
زیرسیستم تلفنی Telephony subsystem
انتقال Transport
لنگر اعتماد Trust Anchor
تونل Tunnel

علائم اختصاری

Abbreviation Description
ACL Access Control Lists
AKA Authentication and Key Agreement Protocol
AS Access Stratum
ASE Assurance Security target Evaluation
AuC Authentication Center
BTS Base Station
CA Certificate Authority
CC Common Criteria
CRL Certification Revocation List
CSP Content Security Policy
DBR Data Radio Bearer
DH Diffie–Hellman
DN Distinguished Name
EAL Evaluation Assurance Level
EDGE Enhanced Data Rates for GSM Evolution
EPC Evolved Packet Core
E-RAB E-UTRAN Radio Access Bearer
FQDN Fully Qualified Domain Name
GPG GnuPG - GNU Privacy Guard
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GUTI Globally Unique Temporary Identity
HSPA High Speed Packet Access
HSS Home Sybscriber Server
IKE Internet Key Exchange
IMEI International Mobile Equipment Identifier
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IP Internet Protocol
KEM Key Establishment Methods
LTE Long Term Evolution
MAC Medium Access Control
MITM Man In The Middle
MME Mobility Management Entity
MNO Mobile Network Operator
MNVO Mobile Virtual Network Operator
NAS Non-Access Stratum
NAT Network Address Translation
NTP Network Time Protocol
PCRF Policy and Charging Rules Function
PDCP Packet Data Convergence Protocol
P-GW Packet Data Network Gateway
PHY Physical Access
PP Protection Profile
PSTN Public Switched Telephone Network
QoE Quality of Experience
QoS Quality of Service
RAN Radio Access Network
RLC Radio Link Control
RRC Radio Resource Control
SA Security Assication
SAN Subject Alternative Name
SFR Security Functional Requirements
S-GW Serving Gateway
SRB Signaling Radio Breaers
ST Security Target
TMSI Temporary Mobile Subscriber Identity
TOE Target Of Evaluation
TSC ToE Scope of Control
TSF ToE Security Functions
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunications System
USIM Universal Subscriber Identity Module

  1. مراجع

  2. “Common Criteria for Information Technology Security Evaluation”, Version 3.1, Revisoin 5, 2017

  3. “collaborative Protection Profile for Network Devices”, Version 2.2e, 2020

  4. “3rd Generation Partnership Project, System Architecture Evolution (SAE): Security Architecture”, 3GPP TS 33.401, V13.2.0, 2016

  5. “3rd Generation Partnership Project, Study on security assurance methodology for 3GPP network products”, 3GPP TR 33.805, V12, 2013

  6. “Guide to LTE Security”, NIST Special Publication 800-187, 2017

  7. "PP-Module for Wireless Local Area Network(WLAN) Access System",Version 1.0, 2022-03-31

  1. Security Functional Requirement ↩︎

  2. Telephony subsystem ↩︎

  3. Universal Integrated Circuit Card ↩︎

  4. Universal Subscriber Identity Module ↩︎

  5. International Mobile Subscriber Identity ↩︎

  6. Globally Unique Temporary Identity ↩︎

  7. International Mobile Equipment Identifier ↩︎

  8. Air interface based Communications ↩︎

  9. Non_Air Interface based Communications ↩︎

  10. Authorized Traffic ↩︎

  11. Unauthorized Traffic ↩︎

  12. منظور از همتا شدن، اتصال به نود مربوطهeNodeB است که معمولاً نزدیک‌ترین نود با قوی‌ترین سیگنال دریافتی است. ↩︎

  13. Access Point ↩︎

  14. Common Criteria ↩︎

  15. Strict Conformance ↩︎

  16. Demonstrable ↩︎

  17. Mobility Management Entity ↩︎

  18. Man In The Middle ↩︎

  19. Security Functional Requirements (SFR) ↩︎

  20. Import (اشاره به ایمپورت یک کلید آماده دارد) ↩︎

  21. الزاماتی که انتهای آن‌ها با EXT تمام می‌شود، الزاماتی هستند که به طور خاص روی هدف مورد بررسی (در اینجا مودم) و با توجه به فناوری، کارکردها و قابلیت‌های آن قابلیت اعمال دارند. این الزامات اغلب فاقد بیان عام و کلیات هستند و در عوض، روی جزئیات متمرکز شده‌اند. ↩︎

  22. Key Establishment Methods ↩︎

  23. Key Establishment ↩︎

  24. Content Security Policy ↩︎

  25. منظور از این عبارت این است که بازنویسی یکبار یا برای اطمینان و به انتخاب سازنده چندین باز انجام شود. ↩︎

  26. SSH public key-based ↩︎

  27. certificate-based ↩︎

  28. Obscured feedback ↩︎

  29. Reset ↩︎

  30. IPSec Security Association ↩︎

  31. برای سهولت در دریافت منظور این پروفایل حفاظتی، دو مفهوم اساسی trust store و trust anchorدر حوزه تولید گواهینامههای x509 بدون ترجمه ذکر شده است. ↩︎

  32. Identifier ↩︎

  33. Certificate path ↩︎

  34. Revocation status ↩︎

  35. Access Control Lists ↩︎

  36. Extended Sequence Numbers ↩︎

  37. Payload ↩︎

  38. Security Association ↩︎

  39. Sudo random function ↩︎

  40. Identifier ↩︎

  41. Code Signing ↩︎

  42. Wireless Local Area Network ↩︎

  43. Medium Access Control ↩︎

  44. Access Point ↩︎

  45. Connection ↩︎

  46. Wired Equivalent Privacy ↩︎

  47. Wi-Fi Protected Access ↩︎

  48. Payload ↩︎

  49. ToE Security Functions ↩︎

  50. Psudo Random Function (e.g. HMAC) ↩︎

  51. Random Bit Generator ↩︎

  52. Pairwise Transient Key ↩︎

  53. Pairwise Master Key ↩︎

  54. Extensible Authentication Protocol over LAN ↩︎

  55. Port Access Entity ↩︎

  56. https://sec.ito.gov.ir/uploads/images/gallery/eram/docs/PP-Router-930526-V2.pdf ↩︎

  57. Interface ↩︎

  58. ToE Scope of Control ↩︎

  59. Border Gateway Protocol ↩︎

  60. Cellular Network ↩︎

  61. Mobile Network Operator (MNO) ↩︎

  62. Mobile Virtual Network Operator (MVNO) ↩︎

  63. Small cell ↩︎

  64. Global System for Mobile Communications ↩︎

  65. Universal Mobile Telecommunications System ↩︎

  66. General Packet Radio Service ↩︎

  67. Enhanced Data Rates for GSM Evolution ↩︎

  68. High Speed Packet Access ↩︎

  69. Long Term Evolution ↩︎

  70. Base Station ↩︎

  71. Telephony subsystem ↩︎

  72. Universal Integrated Circuit Card ↩︎

  73. Universal Subscriber Identity Module ↩︎

  74. International Mobile Subscriber Identity ↩︎

  75. International Mobile Equipment Identifier ↩︎

  76. Globally Unique Temporary Identity ↩︎

  77. منظور از همتا شدن، اتصال به نود مربوطهeNodeB است که معمولا نزدیک‌ترین نود با قوی‌ترین سیگنال دریافتی می‌باشد. ↩︎

  78. Radio Access Network ↩︎

  79. public switched telephone network (PSTN) ↩︎

  80. air interface ↩︎

  81. Control Plane ↩︎

  82. User Plane ↩︎

  83. Radio Resource Control ↩︎

  84. Signaling radio bearers ↩︎

  85. Transport bearers ↩︎

  86. Signaling Radio Bearer (SRB) ↩︎

  87. Data Radio Bearer (DBR) ↩︎

  88. E-UTRAN Radio Access Bearer ↩︎

  89. Authentication and Key Agreement Protocol ↩︎

  90. Temporary Mobile Subscriber Identity ↩︎

  91. Globally Unique Temporary UE Identity ↩︎

  92. Integrity Key ↩︎

  93. Cipher Key ↩︎

Reference in New Issue View Git Blame Copy Permalink