lte-security-profile/docs/21.md

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

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

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

شماره الزام	نام الزام
7	مدیریت کلید رمزنگاری 1 (FCS_CKM.1)
مودم می‌بایست تولید کلیدهای رمزنگاری نامتقارن را با انتخاب یکی از روش‌های مقابل برای تولید کلید انجام دهد: ]انتخاب: روش RSA با طول کلید 2048 بیت یا بزرگتر که الزامات ذکر شده در پیوست B.3 از سند FIPS PUB 186-4 با عنوان استاندارد امضای دیجیتال DSS را رعایت کند. روش ECC بر مبنای منحنی ]انتخاب: P-256, P-384, P-521[ از NIST Curves که الزامات ذکر شده در پیوست 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)
مودم باید استقرار کلید رمزنگاری را بر اساس یک روش استاندارد استقرار کلید رمزنگاری انجام دهد: ]انتخاب: الگوهای استقرار کلید 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)
مودم می‌بایست قابلیت نابودسازی کلیدهای تولید شده را داشته باشد: ]اختصاص: برای کلیدهای متن-ساده (رمز نشده) که در حافظه گذرا قرار دارند، نابودسازی باید از طریق ]انتخاب: بازنویسی ساده از طریق ]انتخاب: تولید عبارت شبه تصادفی با استفاده از تابع تولید بیت تصادفی، یک عبارت تماماً صفر، یک عبارت تماماً یک، یک مقدار جدید از کلید، ]اختصاص: یک مقدار ثابت یا پویا که شامل هیچ CSP نباشد[[، یا نابودسازی مرجع کلید (مستقیماً با درخواست زباله‌روبی) باشد[. برای کلیدهای متن-ساده (رمز نشده) که در حافظه پایدار قرار دارند، نابودسازی باید از طریق یک واسط فراهم‌شده توسط خود مودم انجام شود که ]انتخاب: به‌صورت منطقی مکان ذخیره‌سازی کلید را آدرس می‌دهد و بازنویسی را برای ]انتخاب: یک بار، ]اختصاص: لیست دفعات[[ انجام می‌دهد که شامل ]انتخاب: تولید عبارت شبه تصادفی با استفاده از تابع تولید بیت تصادفی، عبارت تماماً صفر، عبارت تماماً یک، یک مقدار جدید از کلید، ]اختصاص: یک مقدار ثابت یا پویا که شامل هیچ 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 که در ISO 18033-3 تعریف شده است و استاندارد ]انتخاب: CBC که در ISO 10116 تعریف شده است، GCM که در ISO 19772 تعریف شده است، CTR که در ISO 10116 تعریف شده است[ انجام دهد. نکات کاربردی: نخست حالت یا مد کاری الگوریتم 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 کمینه الزام خواهد بود. انتخاب الگوریتم درهم‌ساز باید با توجه به قدرت الگوریتم مورد استفاده برای الزام "عملیات رمزنگاری/رمزنگاری داده‌ها" و الزام "عملیات رمزنگاری/تولید و تأیید امضا" انجام شود (مثلاً SHA-256 برای کلیدهای 128 بیتی).
16	عملیات رمزنگاری/الگوریتم درهم‌ساز مبتنی بر کلید (FCS_COP.1/KeyedHash)
مودم باید احراز هویت پیام مبتنی بر کلید درهم‌سازی شده را بر اساس الگوریتم رمزنگاری ]انتخاب: HMAC-SHA-1، HMAC-SHA-256، HMAC-SHA-384، HMAC-SHA-512[ و سایز کلید رمزنگاری ]اختصاص: اندازه کلید به بیت که در HMAC استفاده شده[ و اندازه خلاصه پیام ]انتخاب: 160، 256، 384، 512[ بیتی و با رعایت نکات ذکر شده در بخش 7 از سند ISO/IEC 9797-2:2011 انجام دهد. نکات کاربردی: اندازه کلید k در عبارت "اختصاص" بین L1 و L2 خواهد بود (تعریف شده در ISO/IEC 10118 مربوط به توابع درهم‌ساز). به طور مثال در مورد 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] منبع نرم‌افزاری برای تولید آنتروپی.