• info@arka.ir
  • تماس با ما: 02191300476 - ۰۲۱۸۸۸۰۴۹۶۱
  • تهران، خیابان شهید بهشتی، خ پاکستان، کوچه ۴ پلاک ۱۱ واحد ۷

آرشیوها

اخبار و مقالات

30 آگوست 2021

پگاسوس چیست؟ یک متخصص امنیت سایبری توضیح می دهد که چگونه نرم افزار جاسوسی به تلفن ها حمله می کند و وقتی وارد دستگاه می شود چه می کند

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

این نوع رمزگذاری برای محافظت از حریم خصوصی شما خوب است ، اما دولت ها آن را دوست ندارند زیرا جاسوسی از افراد را برای آنها دشوار می کند ، چه ردیابی جنایتکاران و تروریست ها و(* یا همانطور که برخی از دولت ها در جستجوی خلافکاران ، معترضان و روزنامه نگاران وارد یک شرکت فناوری اسرائیلی ، NSO Group شوید.*)

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

چگونه کار می کند؟

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

از سال ۲۰۱۹ ، کاربران Pegasus قادر به نصب نرم افزار بر روی تلفن های هوشمند با تماس از دست رفته در WhatsApp هستند ، و حتی می توانند سابقه تماس از دست رفته را حذف کنند ، و این باعث می شود که صاحب تلفن نتواند بداند که مشکلی وجود دارد. راه دیگر این است که به سادگی پیامی را به تلفن کاربر ارسال کنید که هیچ اعلانی ایجاد نمی کند.

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

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

چه کسی و چرا از Pegasus استفاده کرده است؟

گروه NSO می گوید که Pegasus را فقط برای دولتها می سازد تا در کارهای ضد تروریسم و اجرای قانون استفاده کنند. این شرکت آن را به عنوان یک ابزار جاسوسی هدفمند برای ردیابی جنایتکاران و تروریست ها و نه برای نظارت گسترده به بازار عرضه می کند. این شرکت مشتریان خود را فاش نمی کند.

اولین استفاده از پگاسوس توسط دولت مکزیک در سال ۲۰۱۱ برای ردیابی بارون بدنام مواد مخدر خواکین “ال چاپو” گوزمان انجام شد. گفته می شود این ابزار برای ردیابی افراد نزدیک به جمال خاشقجی روزنامه نگار سعودی مورد استفاده قرار گرفته است.

مشخص نیست چه افرادی یا چه نوع افرادی مورد هدف قرار می گیرند و چرا. با این حال ، بسیاری از گزارش های اخیر در مورد پگاسوس شامل یک لیست از ۵۰،۰۰۰ شماره تلفن است. این فهرست به گروه NSO نسبت داده شده است ، اما منشاء لیست نامشخص است. در بیانیه عفو بین الملل در اسرائیل آمده است که این لیست شامل شماره تلفن هایی است که برای مشتریان مختلف NSO به عنوان “مورد علاقه” مشخص شده است ، اگرچه مشخص نیست که آیا هیچ یک از تلفن های مرتبط با شماره ها واقعاً ردیابی شده است.

کنسرسیوم رسانه ای ، پروژه پگاسوس ، شماره تلفن های موجود در لیست را تجزیه و تحلیل کرد و بیش از ۱۰۰۰ نفر را در بیش از ۵۰ کشور شناسایی کرد. این یافته ها شامل افرادی است که به نظر می رسد خارج از محدودیت گروه NSO برای تحقیقات در مورد فعالیت های جنایی و تروریستی هستند. این افراد شامل سیاستمداران ، کارمندان دولت ، روزنامه نگاران ، فعالان حقوق بشر ، مدیران تجاری و اعضای خانواده سلطنتی عرب می شوند.

راه های دیگری که می توان تلفن شما را ردیابی کرد

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

سازمان های اجرای قانون از شبیه سازهای سایت های تلفن همراه مانند این StingRay برای رهگیری تماس های تلفن در مجاورت دستگاه استفاده می کنند. دفتر ثبت اختراعات و علائم تجاری ایالات متحده از طریق AP

دولت ها و شرکت های تلفن می توانند با ردیابی سیگنال های سلولی از فرستنده و گیرنده های برج سلولی و شبیه سازهای گیرنده سلولی مانند دستگاه StingRay ، مکان تلفن را ردیابی کنند. همچنین می توان از سیگنال های وای فای و بلوتوث برای ردیابی گوشی ها استفاده کرد. در برخی موارد ، برنامه ها و مرورگرهای وب می توانند مکان تلفن را تعیین کنند.

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

آژانس امنیت ملی با شرکت های فناوری به دنبال توافقاتی بوده است که بر اساس آن این شرکت ها از طریق درهای پشتی (backdoors) به آژانس دسترسی ویژه ای به محصولات خود می دهند و بنا بر گزارش ها درهای پشتی به تنهایی ساخته شده است. این شرکت ها می گویند که درهای پشتی هدف رمزگذاری سرتاسری را شکست می دهند.

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

theconversation

30 آگوست 2021

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

دفتر JCDC برای برنامه ریزی سایبری مشترک متشکل از نمایندگان دولت فدرال است – از جمله وزارت امنیت داخلی (DHS)، وزارت دادگستری (DOJ)، فرماندهی سایبری ایالات متحده (USCYBERCOM) ، آژانس امنیت ملی (NSA) ، دفتر تحقیقات فدرال(FBI) ، و دفتر مدیر اطلاعات ملی (ODNI). علاوه بر این ، JCDC با شرکای داوطلبانه ، از جمله دولت های ایالتی ، محلی ، قبیله ای و سرزمینی (SLTT) ، سازمان ها و مراکز اشتراک گذاری و تجزیه و تحلیل اطلاعات (ISAOs/ISAC)، و همچنین صاحبان و اپراتورهای سیستم های اطلاعاتی مهم و در صورت لزوم ، نهادهای خصوصی مشورت خواهد کرد.

ماموریت و چشم انداز

برنامه ریزی یک عنصر مهم در هماهنگی قابلیت های دفاع سایبری برای اطمینان از رویکرد کل کشور برای تامین زیرساخت های حیاتی و دفاع از منافع ملی است. JCDC ذینفعان فدرال ، SLTT و دولتی-خصوصی را که دارای حقوق مربوط در عملیات دفاع سایبری هستند ، گرد هم می آورد تا برنامه ریزی و آمادگی امنیت سایبری را هماهنگ کرده و توانایی ها ، اختیارات و تخصص مربوطه را در گروه های مختلف نمایندگان خود متحد کند. برای انجام این مسئولیت ، JCDC ماموریت و چشم انداز زیر را تعریف کرده است:

ماموریت:

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

چشم انداز:

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

قابلیت های کلیدی JCDC

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

 

شرکای کلیدی           

JCDC نمایندگان مناسب از بخش خصوصی – دولتی را شامل می شود – شامل شرکای بین سازمانی ، دولت های SLTT ، ISAOs/ISAC ، و مالکان و اپراتورهای زیرساخت های حیاتی. علاوه بر این ، JCDC با ارائه دهندگان فناوری اطلاعات و ارتباطات مناسب(ICT) و اطلاعات تهدید سایبری (CTI) برای محافظت ، دفاع و پاسخ به حملات سایبری مهم مشورت خواهد کرد.

نمایندگی بین سازمانی:

NDAA 2021 بخش ها و آژانس های فدرال زیر را که شامل دفتر JCDC برای برنامه ریزی سایبری مشترک می شوند ، شناسایی کرد: DHS ، DOJ ، USCYBERCOM ، NSA ، FBI و ODNI. علاوه بر این ، JCDC نمایندگان سایر نهادهای USG  (به عنوان مثال ، آژانس های مدیریت ریسک بخش  [SRMA]  ) را در برنامه ریزی تلاش ها ، بر اساس اقتدار و توانایی های مربوطه ، ادغام می کند. JCDC بعنوان سلول برنامه ریزی قابل همکاری عمل خواهد کرد که در آن قابلیت های USG در پشتیبانی از عملیات دفاع سایبری یکپارچه شده و در یک راستا قرار گرفته است. هر یک از شرکای USG مجموعه ای منحصر به فرد از مقامات ، منابع و قابلیت ها را برای ماموریت امنیت سایبری ملی به ارمغان می آورد.

دولت های SLTT :

از ذینفعان SLTT دعوت می شود تا اطلاعات مربوط به خطرات سایبری ایالتی و محلی را با JCDC ، از جمله اولویت های بلندمدت برای کاهش خطر زیرساخت های حیاتی ، با JODC به اشتراک بگذارند تا از توسعه برنامه های مشترک عملیات سایبری در سطح ملی مطلع شوند. JCDC مقامات و قابلیت های SLTT را در چارچوب برنامه ریزی JCDC گنجانده و به هماهنگی اجرای برنامه عملیات ملی دفاع سایبری در سطح ایالتی و محلی کمک می کند.

ISAO ها/ISAC ها:

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

مالکان و اپراتورهای زیرساخت های بحرانی:

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

همکاران صنعت و دانشگاه:

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

 

cisa

25 آگوست 2021

میلیون ها کاربر تلفن های هوشمند در سراسر کشور هدف فیشینگ اس ام اس هستند.

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

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

سینا گرسین، وکیل FTC هشدار می دهد: “این متون فیشینگ کلاهبرداری با هدف سرقت اطلاعات شخصی، مزایای بیکاری یا هر دو انجام می شود.”

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

گرسین می گوید: “سازمان های دولتی پیام های متنی برای درخواست اطلاعات شخصی ارسال نمی کنند.” و “در صورت دریافت پیام متنی یا ایمیل ناخواسته … پاسخ ندهید و روی هیچ پیوندی کلیک نکنید.”

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

کین مک گلادری ، یکی از اعضای هیئت مشاوره گروه Alliance Technology NW ، هشدار می دهد که این کلاهبرداری ها می توانند موثر واقع شوند. او می گوید این طرح ها زمانی پشتیبانی می شوند که از کمپین های بزرگتر قبل از هرگونه ارسال پیامک پشتیبانی شود.

Phishing Attacks Soaring

هشدار FTC در حالی مطرح می شود که حملات فیشینگ همچنان عامل اصلی مجرمان سایبری است که کارکنان راه دور را هدف قرار می دهند. کاربران نهایی سازمانی که به دستگاه های BYOD تکیه می کنند و قربانی حملات (smishing) مخرب می شوند ، می توانند درهای نفوذی را باز کنند که به طور بالقوه می تواند شبکه های شرکتی را فلج کند.

شرکت امنیتی Egress می گوید که بر اساس نظرسنجی رهبران فناوری اطلاعات ، ۷۳ درصد از سازمان ها در سال گذشته قربانی حملات فیشینگ موفق شدند.

بر اساس گزارش مرکز شکایات جنایی اینترنتی FBI ، Phishing/smishing  و سایر تاکتیک های مهندسی اجتماعی مهمترین تهدید دیجیتالی در شمار قربانیان در سال ۲۰۲۰ بوده است. از بین جنایات مختلف اینترنتی که توسط FBI ردیابی می شود ، فیشینگ بالاتر از اخاذی ، کلاهبرداری از کارت اعتباری و سایر طرح ها قرار گرفته است.

شاخص های فیشینگ

در راهنمای صادر شده در سال ۲۰۲۰ ، آژانس امنیت سایبری و زیرساخت ها نکات امنیتی در مورد Phishing/smishing ارائه داد. CISA تاکید کرد که ادغام ایمیل ، صدا ، پیام های متنی و عملکرد مرورگر وب در حملات مهندسی شده اجتماعی احتمال قربانی شدن کاربران را افزایش می دهد.

این آژانس شاخص های رایج تلاش برای Phishing/smishing را ذکر کرده که شامل موارد زیر است: فرستنده مشکوک ، تبریک عمومی و پیوندهای مشکوک که ممکن است به عنوان مکانیسم تحویل بدافزار مورد استفاده قرار گیرد.

کمیسیون ارتباطات فدرال همچنین هشدار داده است که کمپین های smishing می توانند به دلیل سطح متفاوتی از اعتماد نسبت به دستگاه های تلفن همراه بسیار موثر باشند. این آژانس به کاربران تلفن های هوشمند توصیه می کند:

  • هنگام دریافت پیام ها از شماره های ناشناس ، هرگز روی پیوندها کلیک نکنید ، به پیام های متنی پاسخ ندهید یا تماس نگیرید.
  • به سوالات مشکوک که از طریق متن به اشتراک گذاشته می شود پاسخ ندهید ، حتی اگر پیام “پیام را متوقف کنید” برای پایان ارتباط به کاربران ارسال کند.
  • با جستجوی وب سایت های رسمی و برقراری ارتباط جداگانه ، متون مشکوک را که ظاهراً از شرکت ها یا سازمان های دولتی است ، تأیید کنید.

govinfosecurity

23 آگوست 2021

شما در حال انجام IoT RNG هستید (تولید اعداد تصادفی در اینترنت اشیا)

در امنیت اینترنت اشیاء (IoT ) یک شکاف (crack) وجود دارد که بر ۳۵ میلیارد دستگاه در سراسر جهان تأثیر می گذارد. اساساً، هر دستگاه اینترنت اشیا با مولد اعداد تصادفی سخت افزاری ( RNG) دارای یک آسیب پذیری جدی است که به موجب آن نمی تواند به درستی اعداد تصادفی تولید کند، که امنیت هرگونه استفاده بالادستی را تضعیف می کند.

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

شکل ۱: آلیس و باب سعی می کنند با استفاده از RNG مکالمه خصوصی داشته باشند

 

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

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

از سال ۲۰۲۱، اکثر سیستم های IoT روی تراشه SoCs  دارای سخت افزار اختصاصی RNG هستند که دقیقاً برای حل این مشکل طراحی شده است. اما متأسفانه، به این سادگی نیست. نحوه استفاده از وسایل جانبی بسیار مهم است و لبه دانش در اینترنت اشیا فقط به درستی می تواند به عنوان “انجام آن اشتباه” توصیف شود.

تماس نادرست با RNG سخت افزار

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

هنگامی که یک دستگاه اینترنت اشیا به یک عدد تصادفی نیاز دارد، از طریق SDK دستگاه یا به طور فزاینده ای از طریق سیستم عامل اینترنت اشیا با RNG سخت افزاری اختصاصی تماس می گیرد. البته آنچه فراخوانی تابع نامیده می شود متفاوت است، اما در لایه انتزاعی سخت افزار HAL  صورت می گیرد. این یک API است که توسط سازنده دستگاه ایجاد شده است و به گونه ای طراحی شده است که بتوانید به راحتی از طریق کد C با سخت افزار ارتباط برقرار کنید و نیازی به تنظیم و بررسی رجیسترهای خاص منحصر به فرد دستگاه نداشته باشید. عملکرد HAL چیزی شبیه به این است:

               u8 hal_get_random_number(u32 *out_number);

ما به دو بخش توجه داریم:

  • یک پارامتر خروجی به نام out_number . اینجاست که تابع عدد تصادفی را قرار می دهد. این نشانگر یک عدد صحیح ۳۲ بیتی بدون علامت است.
  • مقدار بازگشتی برای مشخص کردن موارد خطا. بسته به دستگاه، ممکن است بولی یا تعدادی از شرایط خطای شمارش شده باشد.

بنابراین، اولین سوالی که ممکن است بپرسید این است: “چند نفر در طبیعت این کد خطا را بررسی می کنند؟” متأسفانه، پاسخ تقریباً هیچ کس است.

به عنوان مثال، فقط به نتایج GitHub برای استفاده از عملکرد MediaTek 7697 SoC HAL نگاه کنید:

یا حتی لایه انتزاعی FreeRTOS یک سیستم عامل محبوب IoT

https://github.com/search?q=HAL_RNG_GenerateRandomNumber&type=code

بدترین چیزی که می تواند اتفاق بیفتد چیست؟

دستگاه ها کد خطای عملکرد RNG HAL را بررسی نمی کنند. اما واقعا چقدر مخرب است؟ این بستگی به دستگاه خاص دارد، اما به طور بالقوه بد است. خیلی بد. بیایید نگاهی بیندازیم.

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

اما این مسئله در مورد اعداد تصادفی است؛ فقط داشتن یکی کافی نیست هنگامی که یک دستگاه نیاز به ایجاد یک کلید خصوصی جدید ۲۰۴۸ بیتی دارد، به عنوان مثال، عملکرد RNG HAL را بارها و بارها در یک حلقه فراخوانی می کند. این امر به طور جدی از توانایی سخت افزاری برای حفظ وضعیت مالیات می گیرد و در عمل، اغلب نمی توانند. چند تماس اول ممکن است موفقیت آمیز باشد، اما معمولاً به سرعت باعث ایجاد خطا می شود.

بنابراین … عملکرد HAL در واقع برای یک عدد تصادفی هنگامی که از کار می افتد به شما چه می دهد؟ بسته به سخت افزار، یکی از موارد زیر است:

  • آنتروپی جزئی
  • عدد ۰
  • حافظه غیر اولیه

تصویر ۲: این نباید وجود داشته باشد.

هیچکدام از آنها حافظه بسیار خوبی ندارند، اما حافظه اولیه چطور؟! چگونه این اتفاق می افتد؟ خوب، به یاد داشته باشید که عدد تصادفی یک اشاره گر خروجی است. سپس شبه کد زیر را در نظر بگیرید (که در صورت تمایل می توانید نمونه های زیادی از آن را در GitHub بیابید):

u32 random_number;

hal_get_random_number(&random_number);

// Sends over the network

packet_send(random_number);

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

این‌ها سناریوهای ساختگی یا غیرواقعی نیستند. دستگاه ها در حال حاضر از کلیدهای رمزنگاری ۰ یا بدتر استفاده می کنند.

با تجزیه و تحلیل Keyfactor در سال ۲۰۱۹ از گواهینامه های RSA در دسترس عموم مشخص شد که از هر ۱۷۲ گواهینامه ۱ مورد در برابر حملات شناخته شده آسیب پذیر است. نویسندگان به ایجاد اعداد تصادفی در دستگاه های IoT به عنوان یکی از جرایم اشاره کردند، اما از شناسایی علت دقیق آن کوتاهی کردند. در حالی که نمی توان با اطمینان گفت که تحقیقات ما مسئول این نتایج است … موارد گسترده کلیدهای RSA ضعیف در دستگاه های IoT دقیقاً همان چیزی است که انتظار می رود.

مطمئناً به نظر می رسد که این یک مسئله مقیاس بزرگ در عمل است، نه فقط در تئوری.

کاربر را سرزنش نکنید

به راحتی می توانید وضعیت موجود را بررسی کرده و نتیجه بگیرید که این فقط خطای کاربر است، اما اینطور نیست. کاربران در وضعیت بدون برد قرار گرفته اند. می بینید، اعداد تصادفی در مواقع ضروری بسیار مهم هستند. غالباً نمی توانید خطا را به شکلی ظریف “مدیریت” کرده و به جلو حرکت کنید.

به عنوان مثال، مستندات MediaTek شامل کد نمونه زیر برای توسعه دهندگان MT7697 SoC است:

if(HAL_TRNG_STATUS_OK != hal_trng_get_generated_random_number(&random_number)) {

    //error handle

}

اما اگر شما مجموعه شبکه ای هستید که در حین تولید یک رمز برای ارتباطات ایمن هستید، چگونه باید خطا را “مدیریت” کنید؟ در واقع فقط دو گزینه وجود دارد:

  • لغو کنید، کل فرایند را از بین ببرید.
  • حلقه را روی عملکرد HAL به مدت نامحدود تا زمان تکمیل تماس بچرخانید، تمام فرآیندهای دیگر را مسدود کرده و از ۱۰۰٪ CPU در این فرآیند استفاده کنید.

هیچ کدام راه حل قابل قبولی نیستند. به همین دلیل است که توسعه دهندگان شرایط خطا را نادیده می گیرند – گزینه های جایگزین وحشتناک هستند و اکوسیستم اطراف سخت افزار RNG هیچ لطفی به آنها نکرده است.

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

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

زیر سیستم CSPRNG

بنابراین شاید برای شما این سوال پیش آمده باشد که “چه چیزی این ویژگی را منحصر به فرد در اینترنت اشیا می کند؟ آیا این مسئله روی لپ تاپ ها و سرورها نیز تأثیر می گذارد؟ ” پاسخ این است که این یک مشکل منحصر به فرد برای دنیای اینترنت اشیا است زیرا این نوع مدیریت سطح پایین دستگاهها معمولاً توسط سیستم عاملی انجام می شود که به طور قابل توجهی در دستگاه های IoT معمولی وجود ندارد.

شکل ۳: اجزای زیرسیستم CSPRNG

 

هنگامی که یک برنامه به یک شماره تصادفی امن رمزنگاری شده در سرور لینوکس نیاز دارد، از RNG سخت افزاری به طور مستقیم نمی خواند یا با برخی از توابع HAL تماس نمی گیرد و با کدهای خطا مبارزه می کند. نه، فقط از /dev /urandom می خواند. این یک زیرسیستم تولیدکننده اعداد شبه تصادفی امن CSPRNG) ) است که به عنوان API در اختیار برنامه های کاربردی قرار گرفته است. در هر سیستم عامل اصلی نیز زیر سیستم های مشابهی وجود دارد: Windows، iOS، MacOS، Android، BSD.

نکته مهم این است که تماس با /dev /urandom هرگز شکست نمی خورد و هرگز اجرای برنامه را مسدود نمی کند. زیر سیستم CSPRNG می تواند بلافاصله دنباله ای بی پایان از اعداد تصادفی قوی تولید کند. با این کار مشکل توابع HAL که اجرای برنامه را مسدود می کنند یا با شکست مواجه می شوند حل می کند.

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

این روش صحیح برای تولید اعداد تصادفی امن رمزنگاری شده است و از قبل در همه جا استاندارد است … به جز اینترنت اشیا.

چرا واقعاً به یک زیر سیستم CSPRNG احتیاج دارید

طراحی کل زیر سیستم CSPRNG بسیار سخت به نظر می رسد، به ویژه هنگامی که ابزار شما از یکی از آن سیستم عامل های IoT جدید استفاده نمی کند. شاید کافی باشد فقط گلوله را بکشید و حلقه را بر روی عملکرد RNG HAL بچرخانید. به این ترتیب شما همیشه اعداد تصادفی خوبی دریافت می کنید، درست است؟

این بخش از این ایده که استفاده از RNG های سخت افزاری به تنهایی بی خطر است، نادیده گرفته شده است.

کد منبع آسیب پذیر

هیچ کس کد منبع را کاملاً از ابتدا نمی نویسد، به ویژه در دنیای دستگاه های اینترنت اشیا. همیشه تعدادی کد مرجع یا نمونه سند وجود دارد که توسعه دهندگان از آنها شروع می کنند. رابط با سخت افزار برای هر دستگاهی دشوار است، چه برسد به سخت افزاری مانند سخت افزار RNG جانبی.

وقتی کد منبع دستگاه دارای آسیب پذیری باشد، به هر دستگاهی که از آن استفاده می کند انتشار می یابد. پس از همه اینها، چگونه باید توسعه دهنده تفاوت بین یک مرجع آسیب پذیر و یک برنامه عجیب و غریب را بداند؟ در اینجا چند نمونه آورده شده است:

استفاده از HWRNG برای کاشت PRNG ناامن

PRNG هایی مانند libc rand ()  بسیار ناامن هستند زیرا اعدادی که تولید می کنند اطلاعاتی در مورد وضعیت داخلی RNG نشان می دهد. آنها برای زمینه های غیر مرتبط با امنیت مناسب هستند زیرا پیاده سازی آنها سریع و آسان است. اما استفاده از آنها برای مواردی مانند کلیدهای رمزگذاری منجر به سقوط فاجعه بار امنیت دستگاه می شود، زیرا همه اعداد قابل پیش بینی هستند.

متأسفانه، بسیاری از SDK ها و سیستم عامل هایی که از RNG های سخت افزاری پشتیبانی می کنند از PRNG ناامن استفاده می کنند. سیستم عامل Contiki-ng IoT برای Nrdic Semiconductor’s nrf52840 SoC دقیقاً این کار را با کاشتن عملکرد Libc rand ()  ناامن با سخت افزار RNG ::  انجام می دهد.

https://contiki-ng.readthedocs.io/en/release-v4.6/_api/arch_2cpu_2nrf52840_2dev_2random_8c_source.html

void

 random_init(unsigned short seed)

 {

   (void)seed;

   unsigned short hwrng = 0;

   NRF_RNG->TASKS_START = 1;

   NRF_RNG->EVENTS_VALRDY = 0;

   while(!NRF_RNG->EVENTS_VALRDY);

   hwrng = (NRF_RNG->VALUE & 0xFF);

   NRF_RNG->EVENTS_VALRDY = 0;

   while(!NRF_RNG->EVENTS_VALRDY);

   hwrng |= ((NRF_RNG->VALUE & 0xFF) << 8);

   NRF_RNG->TASKS_STOP = 1;

   srand(hwrng);

 }

Seeding libc rand() with the hardware RNG entropy: شکل ۴

 

unsigned short

 random_rand(void)

 {

   return (unsigned short)rand();

 }

Future calls to random_rand() call the insecure libc rand() :شکل ۵

 

به طور واضح، هیچ روش مطمئنی برای استفاده از libc rand () برای تولید مقادیر امن وجود ندارد. این واقعیت که مقدار تصادفی با استفاده از سخت افزار ایجاد می شود اهمیتی ندارد زیرا مهاجم می تواند آن را با استفاده از untwister استخراج یا شمارش کند. آنچه مهم است این است که وقتی کاربر random_rand () را صدا می کند، خروجی ناامن از تماس libc rand حاصل خواهد شد.

همچنین می توانید رفتار آسیب پذیر یکسانی را در کد MediaTek Arduino مشاهده کنید:

https://github.com/MediaTek-Labs/Arduino-Add-On-for-LinkIt-SDK/blob/53acd43fbee57b034141068969fa643465dfd743/project/linkit7697_hdk/apps/wifi_demo/src/sys_init.c#L198

/**

* @brief       This function is to get random seed.

* @param[in]   None.

* @return      None.

*/

static void _main_sys_random_init(void)

{

#if defined(HAL_TRNG_MODULE_ENABLED)

    uint32_t            seed;

    hal_trng_status_t   s;

    s = hal_trng_init();

    if (s == HAL_TRNG_STATUS_OK) {

        s = hal_trng_get_generated_random_number(&seed);

    }

    if (s == HAL_TRNG_STATUS_OK) {

        srand((unsigned int)seed);

    }

 Insecure libc rand() usage in MediaTek SDK :شکل ۶

بنابراین حتی اگر دستگاه شما دارای سخت افزار RNG جانبی باشد و حتی اگر فکر می کنید از آن استفاده می کنید، ممکن است امن نباشید.

 

مزایای استفاده

گاهی اوقات، دستگاه ها به روشی بسیار عجیب و غریب کار می کنند که اصلاً واضح نیست. عدم رعایت صحیح این ویژگی ها می تواند منجر به سقوط فاجعه بار امنیت دستگاه شود. یکی از این موارد LPC 54628 است.

هنگام آزمایش LPC 54628، متوجه شدیم که از RNG سخت افزاری اعداد تصادفی با کیفیت بسیار نامناسب دریافت می کنیم-آنقدر بد که ما مشکوک هستیم که ممکن است در ابزار ما مشکلی وجود داشته باشد. معلوم شد حق با ما بود اگر دفترچه راهنمای کاربر را با دقت بخوانید، در صفحه ۱،۱۰۶ (از ۱،۱۵۲) ، به دستورالعمل های زیر توجه خواهید کرد:

“کیفیت تصادفی بودن (آنتروپی) اعداد تولید شده توسط مولد اعداد تصادفی به حالتهای اولیه منطق داخلی بستگی دارد. در صورت نیاز به یک عدد تصادفی ۱۲۸ بیتی یا ۲۵۶ بیتی، توصیه نمی شود چندین کلمه ۳۲ بیتی را به یکدیگر متصل کنید. به عنوان مثال، اگر دو کلمه ۱۲۸ بیتی به هم متصل شوند، RNG سخت افزاری ۲ برابر ۱۲۸ بیت آنتروپی را ارائه نمی دهد.

برای تشکیل یک عدد ۱۲۸ بیتی، یک عدد تصادفی ۳۲ بیتی خوانده می شود، سپس ۳۲ عدد بعدی خوانده می شود اما استفاده نمی شود. عدد ۳۲ بیت بعدی خوانده و استفاده می شود و غیره. بنابراین ۳۲ عدد تصادفی ۳۲ بیتی بین دو عدد ۳۲ بیتی که استفاده می شود رد می شود.”

بنابراین برای اینکه بتوانید از RNG جانبی درست استفاده کنید، باید یک عدد تصادفی دریافت کنید و سپس ۳۲ بعدی را کنار بگذارید. سپس این کار را به صورت حلقه ادامه دهید! در کد آزمایش، ما فقط تابع RNG HAL را فراخوانی کردیم و از نتایج استفاده کردیم … ، که روشی نسبتاً منطقی برای نوشتن کد است. چند نفر زحمت می کشند آن دفترچه راهنمای کاربر را بخوانند؟ یا حتی اگر آنها کد “صحیح” را که اعداد را دور انداخته است پیدا کردند، آیا آن را حذف می کنند زیرا غیر ضروری به نظر می رسد؟

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

تحلیل آماری

بسیار خوب، بنابراین فرض کنید که مشکل حسابرسی کد دستگاه خود را پشت سر گذاشته اید تا مطمئن شوید که در واقع از RNG سخت افزاری استفاده می کند، و اطمینان حاصل کرده اید که شرایط خطا را بررسی کرده و تا زمان آماده شدن دستگاه بچرخید، و با زحمت آن را مطالعه کرده اید. دفترچه راهنمای کاربر ۱۰۰۰ صفحه ای دستگاه شما برای اطمینان از اینکه هرگونه مزاحمت را تشخیص داده اید…. مطمئناً شما باید ایمن باشید، درست است؟

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

MediaTek 7697

یکی از مواردی که ما هنگام تجزیه و تحلیل آنتروپی برای آن آزمایش کردیم، توزیع نسبی بایت های تولید شده توسط RNG است. در یک دنیای کامل، باید انتظار داشته باشیم که هر بایت به یک اندازه محتمل باشد، بنابراین توزیع بایت ها باید یک خط مسطح باشد (البته Modulo هر گونه برآمدگی تصادفی جزئی). اما این چیزی نیست که ما برای MT7697 می بینیم:

شکل ۷: هیستوگرام فراوانی هر بایت ۰ تا ۲۵۵ در مدیاتک ۷۶۹۷ SoC

نمودار بالا یک هیستوگرام است که فرکانس نسبی هر بایت ممکن (۰ -> 255) را به صورت تجربی از RNG سخت افزاری MediaTek 7697 SoC اندازه گیری می کند. به آن الگوی دندان اره توجه کنید: این قطعاً “تصادفی نیست”. هیچ الگویی نباید وجود داشته باشد. چقدر از استفاده مستقیم از آن به عنوان کلید رمزنگاری خود احساس راحتی می کنید؟

Nordic Semiconductor nrf52840

RNG سخت افزاری Nrdic Semiconductor nrf52840 SoC یک الگوی ۱۲ بیتی تکراری ۰x000 را نشان می دهد که هر ۰x50 بایت رخ می دهد:

Repeating 0x000 in the nrf52840 SoC :شکل ۸

این واقعیت که این ۱۲ بایت بود، و نه ۸ یا ۱۶، بسیار جالب بود. ما توضیحی عالی برای آن نداریم، اما احتمالاً به عملکرد داخلی سخت افزار RNG جعبه سیاه بستگی دارد.

STM32-L432KC

متأسفانه، ما نمودار خوبی برای نشان دادن این مورد نداریم، اما در اینجا نتایج حاصل از dieharder، یک ابزار آزمایش تصادفی آماری استاندارد صنعت، آمده است:

#=============================================================================#

#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #

#=============================================================================#

          rng_name   |           filename             |rands/second|

  file_input_raw|STM32L432randData.4gb.32768trans.fullblocking.bin| 1.72e+07  |

#=============================================================================#

       test_name   |ntup| tsamples |psamples| p-value |Assessment

#=============================================================================#

rgb_minimum_distance|   ۰|     ۱۰۰۰۰|   ۱۰۰۰|۰٫۰۰۰۰۰۰۰۰| FAILED

شکل ۹: نمونه ای از نتایج تجزیه و تحلیل آماری dieharder برای STM32-L432KC SoC

 

همانطور که می بینید، این آزمایش در آزمون RGB Minimum Distance” ” (فاصله حداقل) شکست می خورد. این آزمایش این است که از RNG برای ترسیم تصادفی اعداد در یک شبکه بزرگ و سپس محاسبه کوچکترین فاصله بین هر دو نقطه استفاده می کند. این آزمون به ویژه در شناسایی همبستگی های ظریف بین اعداد، مانند تکرار، خوب است. شکست این آزمایش به احتمال زیاد نشان می دهد که اعداد تولید شده توسط RNG مستقل از یکدیگر نیستند یا به نحوی تکرار می شوند.

در حالی که بسیاری از RNG های سخت افزاری که آزمایش کردیم خوب به نظر می رسند، مانند   LPC54628 (با دور انداختن ۳۲*۳۲ بیتی) و ESP32، تنها نتیجه منطقی که می توان در اینجا گرفت این است که آنتروپی خام گرفته شده از RNG سخت افزاری نباید به طور جداگانه مورد اعتماد قرار گیرد. تجمع کلیدی و آنتروپی که زیر سیستم CSPRNG ارائه می دهد اساساً برای اجتناب از انجام IoT RNG ضروری است.

نتیجه گیری

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

این امر بر کل صنعت اینترنت اشیا تأثیر می گذارد. آسیب پذیری اصلی در SDK یک دستگاه یا در اجرای SoC خاص نیست.

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

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

هرگز از آنتروپی مستقیماً از سخت افزار RNG استفاده نکنید. در کل، RNG های سخت افزاری برای استفاده رمزنگاری (فوری) مناسب نیستند. آنتروپی ضعیف را می توان و باید از طریق نرم افزار، از طریق CSPRNG برطرف کرد.

در کوتاه مدت، آنچه شما می توانید انجام دهید این است:

مالکان دستگاه

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

توسعه دهندگان دستگاه IOT

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

تولیدکنندگان دستگاه / سیستم های عملیاتی IOT

هرگونه استفاده مستقیم از عملکرد RNG HAL را در SDK خود منسوخ و یا غیرفعال کنید. در عوض، یک API CSPRNG که با استفاده از منابع آنتروپی قوی و متنوع با استفاده از RNG سخت افزاری مناسب استفاده می شود، قرار دهید. پیاده سازی /dev /urandom هسته لینوکس می تواند به عنوان یک مرجع عالی عمل کند.

 

bishopfox

21 آگوست 2021

 

واحد امنیت اطلاعات شرکت رایان سامانه آرکا برگزار می کند:

 

عنوان وبینار:

استانداردهای امنیت اطلاعات و استانداردسازی الگوریتم‌های رمزنگاری پساکوانتومی

Information Security Standards and Standardization of Post-Quantum Cryptographic Algorithms

 

 

چکیده سخنرانی:

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

 

 

بیوگرافی سخنران:

 

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

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

 

Biography

Amir Hassani Karbasi received his Ph.D. in Cryptography and Information Security at the University of Guilan, Iran. He was the Head of department at the department of Computer Science and Computer Engineering at Khazar University, in Baku, Azerbaijan and He is a visiting professor at Azerbaijan Shahid Madani University of Tabriz, as well as University of Guilan, Islamic Azad University, and in Faradars E-Learning Institute as well. He is Chief Information Security Officer (CISO) at Rayan Samaneh Arka company.

His specialties are mostly gathered in algebraic cryptography, post-quantum cryptography, and lattice-based cryptography which He has worked in multi-disciplinary fields with cutting-edge papers and state-of-the-art research and development. In addition, He is a member in the talented students’ office and top researcher at the University of Guilan, and He is an analyst, designer, and developer for information security protocols at the knowledge-based and start-up companies. He is researcher and developer of Blockchain-based protocols and cryptocurrencies, and the Internet of Things security protocols and He has some start-up products in the field of network security and cryptography

 

زمان وبینار:

دوشنبه مورخ ۱۵/۰۶/۱۴۰۰ از ساعت ۱۵ الی ۱۶ ظهر

لینک ورود به جلسه (برای عموم رایگان است):

https://join.skype.com/CN3eXKXX9zaD

16 آگوست 2021
واتس‌اپ سرانجام امکان انتقال آرشیو چت بین دو پلتفرم اندروید و iOS را که یکی از بزرگ‌ترین مشکلات این پیام‌رسان بود، فراهم کرد.

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

این انتقال آرشیو شامل تصاویر و پیامهای صوتی خواهد بود و تا چند هفته دیگر برای کاربران قابل دسترس می شود.

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

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