security through obscurity / امنیت از طریق تیرگی

نظر به اینکه بیشتر برنامه نویسان از security through obscurity برای تامین امنیت برنامه هاشون استفاده میکنن، گفتم تا این تاپیک رو در این باره استارت کنم.

———————————–

security through obscurity یک اصطلاح تنزل دهنده است که به یک قاعده در مهندسی امنیت اشاره دارد که تلاش میکند از طریق محرمانگی طراحی یا پیاده سازی امنیت را تامین کند.

یک سیستم که بر security through obscurity اتکا دارد ممکن است آسیب پذیری های تئوریک یا عملی داشته باشد، اما مالکان یا طراحان اعتقاد دارند که اگر ضعفها دانسته نشوند، نامحتمل است که دشمنان آنها را بیابند.

یک سیستم ممکن است از security through obscurity بعنوان دفاع در عمق (defense in depth) استفاده کند؛ درحالیکه همهء آسیب پذیری های امنیتی از طریق راههای دیگر تخفیف داده میشوند، افشای عمومی محصولات و نسخه های درحال استفاده آنها را هدفهای اولیه برای آسیب پذیری های جدید کشف شده در آن محصولات و نسخه ها میسازد. قدم اول یک نفوذگر معمولا جمع آوری اطلاعات است؛ این قدم بوسیلهء security through obscurity به تاخیر انداخته میشود. این تکنیک در تضاد با امنیت بر اساس طراحی (security by design) و امنیت باز (open security) است، هرچند بسیاری از پروژه های دنیای واقعی عناصری از تمام استراتژی ها را دارند.

امنیت بر اساس تیرگی (Security through obscurity) هیچوقت بعنوان یک خط مشی برای تامین امنیت یک سیستم مورد پذیرش مهندسی واقع نشد، چراکه آن با قاعدهء «ساده نگه داشتن» (keeping it simple) در تضاد است. انستیتوی ملی استانداردها و فناوری ایالات متحده (NIST) بخصوص برضد آن در بیش از یک سند توصیه میکند. نقل قول از یکی از آنها: « امنیت سیستم نباید بر محرمانگی پیاده سازی یا اجزای آن متکی باشد ».

منبع: http://en.wikipedia.org/wiki/Security_through_obscurity

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

منبع: http://en.wikipedia.org/wiki/Security_by_design

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

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

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

منبع: http://en.wikipedia.org/wiki/Security_through_obscurity

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

یکی از اصول کرکهف درمورد سیستم رمزنگاری: « نباید نیاز باشد که سیستم محرمانه نگه داشته شود، و باید این امکان وجود داشته باشد که سیستم به دست دشمن بیفتد بدون اینکه باعث دردسر شود. »

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

Bruce Schneier (متخصص مشهور امنیت و رمزنگاری): « قانون کرکهف فراتر از کدها و رمزها به امنیت سیستمها در کل اعمال میشود: هر چیز محرمانه یک نقطهء شکست احتمالی را ایجاد میکند. به بیان دیگر، محرمانگی یک عامل اصلی شکنندگی است – و بنابراین چیزی است که یک سیستم را مستعد فروپاشی فاجعه بار میکند. برخلاف آن، باز بودن باعث انعطاف پذیری میشود. »

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

الگوریتم های رمزنگاری استفاده شده برای حفاظت از اطلاعات طبقه بندی شدهء حکومتی یا نظامی اغلب محرمانه نگه داشته میشوند. اما نباید فرض شود که الگوریتم های رمز حکومت/ارتش برای حفظ امنیت باید محرمانه نگه داشته شوند. ممکن است درنظر گرفته شده باشد که آنها همانقدر از نظر رمزنگاری معقول باشند که الگوریتم های عمومی هستند، و تصمیم برای محرمانه نگه داشتن آنها در جهت یک دیدگاه امنیت لایه بندی شده باشد.

Eric Raymond: هر طراحی نرم افزار امنیتی که فرض نمیکند دشمن کد منبع را دراختیار دارد غیرقابل اعتماد است؛ بنابراین، هیچوقت به نرم افزار کدبسته اعتماد نکنید.

John Savard: اینکه امنیت یک الگوریتم رمز باید بر کلید و نه الگوریتم استوار باشد به یک حقیقت بدیهی در عصر رایانه تبدیل شده است، و این بیادماندنی ترین از گفته های کرکهف است. … برخلاف یک کلید، یک الگوریتم میتواند بوسیلهء متخصصان برای تعیین اینکه آیا امن بودن آن محتمل است تحلیل شود. یک الگوریتم که شما خودتان اختراع کرده اید و محرمانه نگه داشته اید فرصت چنان بررسی ای را نداشته است.

Steve Bellovin: … به بیان دیگر، سیستم خود را با این فرض که مخالفان شما آنرا با تمام جزییات میدانند طراحی کنید (یک مقام سابق مرکز امنیت ملی رایانه در آژانس امنیت ملی (NSA) به من گفت که فرض استاندارد در آنجا این بود که شماره سریال یک هر دستگاه جدید به کرملین تحویل داده شده است). پس از آن، هرچند، اینکه تلاش کنید آنرا محرمانه نگه دارید اشتباه نیست. آن یک فاکتور مانع دیگر برای دشمن است که باید بر آن غالب شود (یک مانع که بریتانیایی ها وقتی به سیستم انیگمای آلمانی حمله کردند با آن مواجه شدند ساده بود: آنها نگاشت سادهء بین کلیدهای کیبورد و ورودی به آرایهء روتور را نمیدانستند). اما، *بر سری بودن اتکا نکنید*.

منبع: http://en.wikipedia.org/wiki/Kerckhoffs%27_principle

———————————–

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

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

طبیعتا ما روشهای اصولی کافی هم برای تمام سناریوهای متداول داریم. اما متاسفانه بیشتر برنامه نویسان ظاهرا از این روشها و علت و اهمیت استفاده از اونها اطلاع ندارن و همچنان میخوان به میانبر ساده اما غیراصولی و ضعیف «امنیت از طریق تیرگی» پناه ببرن.

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

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

نمیدونم واقعا این برنامه های زیادی که تمام یا بخش مهمی از امنیت اونها بر پنهان نگه داشتن کد منبع و الگوریتم متکی هستن چه جایگاهی در دنیای امنیت واقعی و برنامه نویسی قابل قبول حرفه ای دارن. درواقع هیچ! این برنامه ها به هیچ وجه حرفه ای نیستن. این برنامه ها استانداردهای حداقلی رو رعایت نکردن. از کار زده شده. در خیلی موارد برنامه نویس اصلا سواد و توان لازم رو نداشته و نمیدونسته چنین چیزهایی هم وجود دارن و روش صحیح چیه.
در دنیای بازمتن هم که مسلما کلا نمیشه از این روش استفاده کرد.
اگر میخوایم حرفه ای باشیم و برنامه نویسی واقعی بکنیم، یک برنامه نویسی باکیفیت و قابل اعتماد، باید از روش اصولی پیروی کنیم. و بدیهی هست اول باید دانش تئوریک لازم رو بدست بیاریم. صرفا با کد زدن و تجربهء عملی نمیشه به خیلی چیزها رسید.

———————————–

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

الگوریتم های باز به مرور زمان کاملتر شده و هر چه از عمر آنها میگذرد اطمینان نسبت به بی نقص بودن آنها بیشتر میشود، چرا که درحالیکه در دنیا در دسترس همگان هستند اما هیچکس چه دوست و چه دشمن نتوانسته آنها را شکست دهد.

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

———————————–

بعضی افراد میگن ما میایم security through obscurity رو در کنار روشهای اصولی و استاندارد امنیت استفاده میکنیم و این اشکالی نداره.

خب این حرف درسته، اشکالی نداره از نظر تئوری، ولی احتمالا این افراد هنوز بخوبی متوجه کل ماجرا نشدن و بیش از حد از security through obscurity استفاده و روی اون حساب میکنن.

البته موارد مشروعی از استفاده از security through obscurity بوده و هست. مثلا در بعضی موارد اصلا روش اصولی و استاندارد کارایی وجود نداره؛ مثل قفل گذاری روی برنامه های انحصاری برای جلوگیری از کشف الگوریتم و دستکاری اونا و همچنین کپی غیرمجاز. در اینطور موارد از security through obscurity استفاده میشه؛ در اینطور موارد روش استاندارد و اصولی تقریبا وجود نداره (اینکه میگم تقریبا چون بنا بر اطلاعاتی که دارم، ممکنه راه اصولی تری وجود داشته باشه ولی به دلایلی که لزوما فنی هم نیستن، ازشون استفاده نمیشه یا خیلی کمتر/در موارد خاصی استفاده میشه). مثلا Obfuscator ها که کد/الگوریتم برنامه رو بصورت ناخوانا درمیارن نمونه ای از security through obscurity هستند. ما مشاهده میکنیم که این Obfuscator ها در نهایت دیر یا زود قابل شکست هستند، درحالیکه رمزنگاری های مدرن استاندارد مثل AES بعد از سالهای سال هنوز امن باقی موندن. یعنی میخوام بگم ضعف security through obscurity در این مورد هم دیده میشه که تقریبا هیچوقت نمیتونه امنیت خیلی زیادی رو تامین کنه.
البته ما در قفل گذاری از برنامه ها به دلایل فنی معینی نمیتونیم مستقیما یا به تنهایی از الگوریتم های رمزنگاری استانداردی مثل AES استفاده کنیم و اون امنیت حداکثری رو بدست بیاریم، و بخاطر همین است که میگیم در این موارد روش اصولی تری وجود نداره و مجبور هستیم برای تامین یا افزودن امنیت به security through obscurity متوسل بشیم. علت عمده این مسئله اینه که برنامه و عملیات رمزگذاری و/یا رمزگشایی هر دو روی سیستمی که تحت کنترل ما نیست انجام میشن و طبیعتا در این مراحل کلید رمزنگاری و/یا یا داده های خام بالاخره در زمانی هرچند کوتاه و در جایی هرچند دشوار برای دسترسی در سیستمی که برنامه روش اجرا میشه وجود خواهند داشت (چون بالاخره باید در دسترس پردازنده و عملیات پردازش و غیره قرار بگیرن)؛ سیستمی که سیستم کاربر عادی، هکر، یا کرکر است و ما نمیتونیم از دست نخوردگی محیط نرم افزاری و سخت افزاری اون هیچ اطمینانی داشته باشیم.

خب این یک استفاده از security through obscurity بود که گفتم.
اما مثال دیگری از استفاده از security through obscurity میگم که همون چیزیه که بعضی افراد میگن؛ یعنی استفاده در کنار روشهای اصولی و استاندارد.
البته این مثال من تاحدی غیرواقعی است، اما بعنوان مثال خوبه.

فرض کنید من دیتایی دارم که میخوام اون رو رمز کنم تا کسی نتونه اون رو بخونه یا دستکاری کنه.
من میام این دیتا رو با الگوریتم AES128 + HMAC و با یک کلید رندوم x که تولید میکنم، رمز میکنم.
از نظر تئوری و عملی در زمان حاضر، این روش هیچ نقص جدی ای نداره، ولی بعضی افراد بدبین و شکاک بوده و هستن که حتی به اینم شک دارن و میگن از کجا معلوم شاید کسی یا سازمان مخفی در دنیا، بتونه این الگوریتم رو کرک کنه یا اینکه شاید مثلا فردا، یک سال دیگه، 5 سال دیگه، … کسی موفق به این کار شد و اونوقت دیتای ما که در دسترس دیگران قرار داره افشا میشه.
البته بنظر بنده این استدلالها فقط درمورد اطلاعاتی که از نظر امنیتی اهمیت و حساسیت بسیار بالایی دارن (مثل مسائل حساس نظامی و امنیتی کشورها) قابل قبول (یا حتی لازم) است، نه اکثر کارهای دیگه.

خب این افراد میتونن چکار کنن؟

1- راه اول اینه که این افراد از الگوریتم اختصاصی ای که خودشون طراحی کردن برای رمزگذاری استفاده کنن.

اما این راه غلطه، چون بر اساس اصول و تجربه های علم رمزنگاری، تقریبا تمام متخصصان میگن که غلطه! حالا توضیح و اثباتش جای بحثش در اینجا نیست و طولانی میشه و پایهء دانش خودش رو میخواد؛ بهرحال چیزی که مشخصه اینه که این کار اشتباهیه و امنیت این روشها تقریبا در تمام موارد از چیزی که افراد غیرمتخصص فکر میکنن خیلی کمتره و احتمال شکسته شدن اونا از الگوریتم های استاندارد خیلی بیشتره.
در این روش security through obscurity جایگزین روشهای اصولی ممکن شده، و بنابراین غلط است.

2- راه دوم اینه که طرف اگر میتونه، الگوریتم مورد استفاده رو افشا نمیکنه. یعنی از همون AES استفاده میکنه، اما به کسی نمیگه که از AES استفاده کرده؛ شاید حتی اخبار غلطی درمورد روش استفاده شده رو برای منحرف کردن هکرها/کرکرها منتشر بکنه.

خب این راه هم باز استفاده از security through obscurity است (عدم اطلاع دیگران از روش استفاده شده و جزییات فنی)، اما چون ما از روش اصولی استفاده کردیم (رمزنگاری استاندارد و قوی AES که توسط متخصصان دنیا طراحی و تایید شده)، این استفاده از security through obscurity مشکلی نداره و بعنوان یک احتیاط و لایهء افزوده امنیت خواستیم ازش استفاده کنیم. چون حتی اگر الگوریتم استفاده شده به هر علت و شکلی لو بره، بازهم امنیت سیستم در حد استاندارد باقی میمونه و نفوذگر با سد عظیم یک الگوریتم رمزنگاری مدرن قوی روبرو است.
ولی باید بگم که این نوع از security through obscurity بسیار ضعیف است چون حدس زدن و تست کردن اون کار ساده ای است. در ضمن ما با عدم انتشار جزییات الگوریتم/روش خودمون، اینکه حتی نمیتونیم اون رو به دو نفر متخصص دیگه نشون بدیم و درمیون بذاریم، خودمون رو از مغزهای و چشم های دیگری که میتونستن باگها و خطاهای انسانی و حفره هایی رو در طراحی و پیاده سازی ما کشف و بهمون گزارش کنن و حتی راهکار و روشهای بهتری رو بهمون معرفی کنن، محروم کردیم.
پس باید دید آیا این security through obscurity واقعا بیشتر به نفع ما بوده یا ضرر ما. خب کمی بستگی به شرایط هم داره. و البته به شانس!!
البته این security through obscurity با اینکه امنیت کمی اضافه میکنه و شاید حتی در مواردی امنیت رو پایین بیاره (بخاطر جلوگیری از کمکهای دیگران)، اما درمقابل هزینهء زیادی هم از نظر برنامه نویسی نداشته چون ما هیچ چیز اضافه ای رو طراحی و پیاده سازی نکردیم و صرفا از افشای طرز کار برنامه امتناع کردیم.
بازهم بسته به برنامه نویس و برنامه و هدف و شرایط داره که این تمهید بکار بره یا نه. نمیشه حکم کلی داد. میان علما در این زمینه اختلاف نظر هست. چیزی که بدیهی است اینه که در این کار هیچ یادگیری و پیشرفت و تکامل (بهبود بهینهء برنامه) مطمئنی وجود نخواهد داشت، چون نمیتونیم راجع بهش با با دیگران همفکری کنیم؛ ولی ممکنه کار حساس و خاصی باشه که به دلایل قانونی یا امنیتی و شرایط خاصی که داره اصولا نمیتونیم اون رو با دیگران به اون شکل بقدر کافی مستقیم و با جزییات مطرح کنیم، و طبیعتا در این موارد جلوی یادگیری و پیشرفت و تکامل با کمک دیگران پیش از این گرفته شده.

3- روش سوم اینه که ما از دو الگوریتم همزمان استفاده کنیم. یعنی یک بار داده ها رو با AES رمز کنیم و بعد دیتای رمز شده رو مجددا با الگوریتم اختصاصی خودمون رمز کنیم یا بهرصورتی مخدوش و دستکاری بیشتر کنیم که فکر میکنیم امنیت رو اضافه میکنه. البته استفاده از این روش مانع استفاده از روش 2 (عدم افشای این قضایا) نیست، ولی همچنان با محدودیت ها و معایب روش 2 روبرو میشیم.
البته ما اگر بخوایم روش 3 و 2 رو همزمان استفاده کنیم باز خودش دو شکل داره: ما میتونیم بخش رمزنگاری AES برناممون رو افشا کنیم ولی الگوریتم اختصاصی خودمون رو افشا نکنیم، و یا میتونیم هیچکدام رو افشا نکنیم.
دقت کنید که الگوریتم اختصاصی خودمون نباید افشا بشه، چون یک الگوریتم غیراستاندارده و قاعدتا امنیتش خیلی کمتر از الگوریتم های استاندارد است، و بخش بزرگی از امنیت اون بر پنهان بودن خود الگوریتم استوار است. ما نمیتونیم چنین الگوریتمی رو افشا کنیم، چون افراد کمی در دنیا هستن که دانش و توانایی تحلیل و بهبود الگوریتم های رمزنگاری رو در سطح بالا داشته باشن و گیر آوردن و استفاده کردن از این افراد دشواره، و نهایتا هم اگر این کار رو بکنیم خب این میشه همون روش اصولی که البته از قبل الگوریتم هایی مثل AES برای این کار موجود هستن که تحلیل و محک بیشتری هم داشتن.

خب حالا این روش سوم، یعنی استفاده همزمان از دو الگوریتم رمزنگاری، یکی استاندارد و دیگری اختصاصی، روش اصولی + security through obscurity، آیا صرف میکنه؟
حساب کنید پردازش که اضافه میشه، پیچیدگی و حجیم تر شدن کد و برنامه و مشکل تر شدن تست و توسعه و باگیابی و باگ زدایی اون هم هست.
بنده به شخصه فکر نمیکنم این روش ترکیبی برای بیشتر کاربردها عاقلانه باشه. مگر کاربردهای بسیار حساس و خاص.
تازه وقتی شما از روشهای اختصاصی (که طبیعتا باید فرض کرد غیراصولی هستن در اکثر موارد) استفاده کنید، بازهم ابهامات و پیچیدگی ها و کارهای اضافی دیگری پیش میان.
مثلا اگر ما در هر دو مرحله رمزنگاری از کلید یکسان x استفاده کنیم، این خطر وجود داره که رمزنگاری اختصاصی ما ضعفی داشته باشه که بتونه در نهایت کشف کردن x توسط هکر/کرکر رو ساده تر بکنه. اگر چنین چیزی اتفاق بیفته، امنیت ما جمع امنیت روش استاندارد (اصولی) و روش غیراستاندارد/اختصاصی (security through obscurity) نخواهد بود، بلکه درحد امنیت روش اختصاصی ما خواهد بود.
اینکه بعضی الگوریتم های ضعیف رمزنگاری باعث امکان کشف کلید میشن واقعیتی هست که ناشناخته نیست و در تئوری و عمل بررسی شده و مواردی داره (اگر منابع مربوطه رو خونده باشید، که بیشتر افراد نخوندن و نمیخونن!).
پس اینجا شما مشاهده میکنید که ما فکر کردیم میتونیم با افزودن یک لایهء بیشتر security through obscurity و ترکیب کردن دو الگوریتم رمزنگاری، امنیت رو اضافه کنیم، اما با غفلت از یک نکته، این ترکیب میتونه حتی باعث پایین آمدن شدید امنیت بشه!
راه حل این موضوع اینه که ما برای هر رمزنگاری از یک کلید جداگانه استفاده کنیم. یعنی برای رمزنگاری اختصاصی خودمون از کلید رندوم جدید y بجای کلید x که در رمزنگاری AES استفاده میشه، استفاده کنیم.
اما این طبیعتا کار ما و حجم کلیدهایی رو که باید ذخیره بشن زیاد میکنه، پردازش زیاد میشه، تعداد کلیدها بیشتر میشه، کد برنامه حجیم تر و پیچیده تر میشه.
تازه ما بازهم از کجا میتونیم مطمئن باشیم که نکتهء دیگری وجود نداشته باشه که ما ازش بی اطلاع هستیم یا دچار فراموشی و غفلت در این زمینه شدیم؟

این مثال به خوبی نشون میده که security through obscurity چقدر مسئلهء خطرناک و ظریفی است، و تحلیل و ارزیابی فواید و مضرات اون کاری دشوار!
بنده میتونم بگم اکثرا تنها در واضح ترین و حساس ترین موارد هست که افزودن security through obscurity میتونه دلایل معقول و ارزش کافی داشته باشه. در اکثریت برنامه ها بهتره از security through obscurity استفاده نشه، یا تنها از انواع محدود و ساده ای از اون در جاهایی که فایده اون بقدر کافی واضح و بزرگ است استفاده بشه.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>