یک راه حل امن که دستگاه های اینترنت اشیاء را به فضای ابری متصل می کند

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

　　برای رفع این مسائل و ساده سازی پیاده سازی ویژگی های امنیتی در دستگاه های اینترنت اشیا، Microchip Technology و گوگل با همکاری یکدیگر روشی را ایجاد کرده اند که ویژگی های سخت افزاری امن Microchip را با ساختار داده ساده ای به نام JSON Web Token (JWT) ترکیب می کند. نتیجه این است که روشی ساده برای اطمینان از احراز هویت متقابل بین دستگاه های اینترنت اشیاء و سرویس های هسته ای Google Cloud IoT وجود دارد.

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

　　آسیب پذیری های امنیتی در دستگاه های اینترنت اشیاء

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

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

　　آی سی ایمنی

　　دستگاه های امنیتی اختصاصی مانند مدارهای CryptoMemory و CryptoAuthentication شرکت Microchip Technology دارای عملکردهای سخت افزاری مبتنی بر مکانیزم هایی برای حفاظت از کلیدهای خصوصی و سایر داده های محرمانه هستند. آرایه های EEPROM در این دستگاه ها یکپارچه شده اند و مکانیزم های امنیتی امن ذخیره سازی و رمزنگاری را فراهم می کنند که تنها از طریق رابط سریال SPI یا I2C دستگاه قابل دسترسی است (نگاه کنید به شکل ۱). بنابراین، این دستگاه ها راه ساده ای برای افزودن ذخیره سازی امن و سایر ویژگی های امنیتی به هر طراحی دستگاه IoT ارائه می دهند.

　　شکل ۱: دستگاه های امنیتی سخت افزاری Microchip Technology (مانند AT88SC0204C CryptoMemory IC) ذخیره سازی امن فراهم می کنند و از مکانیزم های رمزنگاری یکپارچه برای محافظت از دسترسی به EEPROMهای داخلی استفاده می کنند. (تصویر: Microchip Technology)

　　اعضای سری Microchip CryptoAuthentication (مانند ATECC608A) پایه های ذخیره سازی امن را تقویت می کنند و از الگوریتم های رمزنگاری رایج در طراحی امنیتی پشتیبانی می کنند. در میان ویژگی های سخت افزاری دستگاه، شتاب دهی سخت افزاری برای الگوریتم های مختلف وجود دارد، از جمله:

　　الگوریتم رمزنگاری نامتقارن:

　　الگوریتم امضای دیجیتال منحنی بیضوی FIPS186-۳ (ECDSA)

　　منحنی بیضوی FIPS SP800-56A دیفی-هلمن (ECDH)

　　استاندارد NIST P256 رمزنگاری منحنی بیضوی (ECC)

　　الگوریتم رمزنگاری متقارن:

　　کد هش SHA-256

　　رمزنگاری کد احراز هویت پیام مبتنی بر هش (HMAC)

　　رمزنگاری AES-128

　　رمزنگاری AES-GCM (ضرب میدان گالوا)

　　تابع استخراج کلید (KDF):

　　تابع شبه تصادفی (PRF) KDF

　　استخراج مبتنی بر HMAC – و گسترش KDF (HKDF)

　　برای کارشناسان رمزنگاری، این مجموعه ویژگی های رمزنگاری نمایانگر فهرست جامعی از مکانیزم های لازم برای پشتیبانی از پروتکل های امنیتی سطح بالاتر است. احراز هویت و تبادل امن داده ها. برای مثال، ویژگی KDF مکانیزم های پایه ای مورد نیاز پروتکل های امنیت لایه انتقال (TLS) را فراهم می کند تا شرکت کنندگان در جلسات تبادل داده را قبل از تبادل ها یا حتی آغاز آن ها تأیید کنند.

　　در این پروتکل، جلسات TLS درخواست ها را از کلاینت ها به سرور ارسال می کنند تا یک جلسه امن را آغاز کنند. سرور با استفاده از گواهی دیجیتال خود پاسخ می دهد که کلاینت از آن برای تأیید هویت سرور استفاده می کند. پس از اینکه کلاینت سرور را به این روش تأیید کرد، تنظیمات جلسه به تولید کلیدهای نشست با استفاده از کلید عمومی سرور ادامه می دهند تا برخی مقادیر تصادفی ایجاد شده با PRF KDF یا HDKF قدرتمندتر را رمزنگاری کنند.

　　پروتکل احراز هویت TLS پایه و اساس امنیت اینترنت است. کل صنعت ارائه دهندگان گواهی، که به عنوان مرجع گواهی (CA) شناخته می شود، به یک مؤلفه کلیدی برای پشتیبانی از ارتباطات امن تبدیل شده است. این شرکت یک گواهی معتبر از CA دریافت می کند تا روی سرورهای خود نصب شود و پروتکل استاندارد احراز هویت سرور TLS را پشتیبانی کند.

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

　　با وجود خطرات، توسعه دهندگان اینترنت اشیاء اغلب در پیاده سازی پروتکل های احراز هویت متقابل TLS دچار مشکل می شوند، زیرا گواهی ها، کلیدها و نرم افزارهای مورد نیاز برای احراز هویت کلاینت با استفاده از TLS ممکن است از قابلیت های بسیاری از دستگاه های IoT فراتر رود. از طریق همکاری، Microchip Technology و گوگل رویکردی جایگزین ایجاد کرده اند که عملکرد ATECC608A را با ساختار داده ساده ای به نام JSON Web Token (JWT) ترکیب می کند. نتیجه این است که روشی ساده برای اطمینان از احراز هویت متقابل بین دستگاه های اینترنت اشیاء و سرویس های هسته ای Google Cloud IoT وجود دارد.

　　احراز هویت بر اساس JWT

　　RFC 7519 مشخص می کند که JWT یک کانتینر استاندارد صنعتی برای اطلاعات درباره نهاد تهیه و ارسال JWT است که به آن ادعا گفته می شود. ساختار JWT خود از سه بخش تشکیل شده است:

　　عناوین، از جمله نام JSON: نام الگوریتم رمزنگاری ("alg") (برای مثال، "EC256" ECDISA از منحنی NIST P-256 استفاده می کند) برای امضای توکن ها و انواع توکن ها ("type") ("JWT" این توکن ها)

　　محموله، شامل نام JSON: جفت مقدار برای هر ادعا

　　امضا: از الگوریتم مشخص شده در هدر برای رمزگذاری کلید، هدر و مجموعه اعلامیه ها استفاده می کند که هر کدام به صورت جداگانه به رمزگذاری URL base64 تبدیل می شوند قبل از رمزنگاری

　　RFC 7519 انعطاف پذیری زیادی برای مشخص کردن ادعاها در محموله ها یا سایر قطعات فراهم می کند. استاندارد حتی اجازه می دهد JWTهای ناایمن بدون امضا یا رمزنگاری ایجاد شوند، که در این صورت هدر شامل نام الگوریتم خواهد بود: جفت مقدار {{alg":"none"}. برای JWTهایی که با سرویس های هسته ای Google Cloud IoT استفاده می شوند، گوگل به یک بخش امضا و یک بار اطلاعاتی نیاز دارد که شامل سه اعلامیه اجباری است، از جمله:

　　"iat" - "زمان صدور توکن" هنگام ساخت توکن در قالب مهر زمانی ISO 8601 UTC، تعداد ثانیه ها از زمان 1970-01-01T00:00:00Z (برای مثال، 1561896000 ساعت 12:00 به وقت گرینویچ در 30 ژوئن 2019)

　　"exp" - زمان زمان UTC که زمان انقضای توکن را تا ۲۴ ساعت بیشتر از مقدار "IAT" به علاوه یک دوره مهلت ۱۰ دقیقه ای مشخص می کند تا سوگیری های مختلف ساعت سیستم بین کلاینت و سرور را برطرف کند (مثلا ۱ ژوئیه ۲۰۱۹ 1561982400، GMT ۰۰:۰۰:۰۰)

　　«aud» - رشته ای که شناسه پروژه Google Cloud توسعه دهنده را در خود دارد

　　< p> راهکار احراز هویت دستگاه IoT گوگل، احراز هویت سرور مبتنی بر TLS معمولی را با JWT که با این اعلامیه های نسبتا ساده برای احراز هویت دستگاه های IoT ایجاد شده اند، ترکیب می کند. برای شروع یک نشست جدید، دستگاه IoT یک سوکت امن به سرور باز می کند و سرور را با همان پروتکل TLS که قبلا توضیح داده شد، احراز هویت می کند.

　　گام بعدی در این فرایند بر پروتکل سبک وزن انتقال تله متری صف پیام (MQTT) گوگل IoT Cloud برای تراکنش های شبکه اینترنت اشیا استوار است. با استفاده از سوکت امن به یک سرور احراز هویت شده، دستگاه IoT از JWT منحصر به فرد خود به عنوان رمز عبور ورود برای «ورود» به سرویس میزبان MQTT آن سرور استفاده می کند (Inventory 1).

　　اگرچه دستگاه های اینترنت اشیاء نام کاربری را به عنوان بخشی از این توالی ورود ارسال می کنند، اما نام های کاربری برای احراز هویت استفاده نمی شوند. بنابراین، یک نام کاربری مجازی (فهرست ۲) منتقل شد. در عوض، احراز هویت دستگاه های IoT بر اساس رمز عبور ورود JWT ارسال می شود. از آنجا که امضاهای JWT ترکیبی از هدرها، محموله ها و کلیدهای خصوصی دستگاه هستند، خدمات هسته ای Google Cloud IoT می توانند تأیید کنند که آیا JWT واقعا از دستگاه های مجاز آمده است یا خیر. برای این تأیید، خدمات اینترنت اشیا گوگل کلود از کلیدهای عمومی دستگاه هایی استفاده می کند که قبلا توسط توسعه دهندگان دستگاه های اینترنت اشیا در گوگل کلود با استفاده از فرآیند مدیریت کلید که در ادامه توضیح داده شده است، ذخیره شده اند. در مقایسه با استفاده تنها از TLS، این رویکرد از طریق رویکرد ترکیبی احراز هویت متقابل را فراهم می کند و فرآیندها را سرعت می بخشد و در عین حال نیاز به منابع برای دستگاه های IoT را کاهش می دهد.

　　تسهیل کننده های کلیدی

　　ATECC608A و عملکرد زنجیره تأمین آن، عوامل کلیدی این رویکرد هستند. در حالی که هر MCU می تواند در نهایت امضاهای رمزنگاری شده را از هدرها و محموله های JWT تولید کند، هر روش صرفا نرم افزاری بدون ذخیره سازی کلید امنیتی مبتنی بر سخت افزار همچنان در برابر حملات آسیب پذیر است. علاوه بر این، برای بسیاری از دستگاه ها یا برنامه های اینترنت اشیا با منابع محدود و الزامات زمان پاسخ سختگیرانه، بار پردازنده و تأخیر اجرای مورد نیاز برای پیاده سازی «فقط نرم افزاری» ممکن است ممنوع باشد. در نهایت، بدون الگوریتم های امنیتی گسترده و تجربه پیشرفته تر در پروتکل، پیاده سازی توابع نرم افزاری مورد نیاز برای توسعه دهندگان دشوار است. Microchip این مسائل را از طریق کتابخانه CryptoAuthLib خود (شکل ۲) برطرف می کند.

　　شکل ۲: از آنجا که CryptoAuthLib از لایه انتزاع سخت افزاری (HAL) برای جدا کردن توابع API و ابتدایی های اصلی از سخت افزار زیرین استفاده می کند، توسعه دهندگان می توانند نرم افزار خود را برای دستگاه های پشتیبان مختلف قرار دهند. (تصویر: Microchip Technology)

　　Microchip CryptoAuthLib پیاده سازی ویژگی های امن اینترنت اشیا، مانند پروتکل احراز هویت Google JWT را ساده می کند و عملیات پیچیده امنیتی را به مجموعه ای از فراخوانی های تابع که از طریق رابط برنامه نویسی کاربردی CryptoAuthLib (API) ارائه می شود، کاهش می دهد. برای توسعه دهندگان اینترنت اشیا، شاید مهم ترین ویژگی ویژگی اصلی Microchip CryptoAuthLib باشد که به طور کامل از مدارهای رمزنگاری Microchip مانند ATECC608A برای تسریع اجرای ویژگی های امنیتی در طراحی بهره می برد. برای مثال، در فهرست ۱، فراخوانی به atca_jwt_finalize() از دستگاه های رمزنگاری موجود (مانند ATECC608A) برای ایجاد JWT رمز عبور در لیست ۲ استفاده می کند. در این حالت، ATECC608A تسریع رمزگذاری امضاهای JWT، طراحی را از کلید ذخیره سازی امن یکپارچه تا تکمیل فرآیند ایجاد امضا که قبلا توضیح داده شد، بخوانید.

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

　　در این رویکرد جدید، میکروچیپ از توانایی ATECC608A برای تولید جفت کلید بدون اینکه دستگاه کلید خصوصی داشته باشد استفاده می کند (شکل ۳). سپس Microchip از یک گواهی واسطه برای امضای کلید عمومی تولید شده توسط دستگاه استفاده می کند که توسط مشتری ارائه شده و روی یک سرور امن در تأسیسات امنیتی Microchip ذخیره می شود. در نهایت، Microchip کلید عمومی را به صورت امن به حساب مشتری در Google Cloud IoT Device Manager ارسال می کند که می تواند تا سه کلید عمومی را برای هر دستگاه ذخیره کند تا از سیاست های چرخش کلید پشتیبانی کند. پس از استقرار، دستگاه های IoT می توانند از ویژگی های امنیتی ATECC608A برای ایجاد JWTهایی که در فرآیند احراز هویت متقابل توضیح داده شد، استفاده کنند.

　　شکل ۳: ترکیب فناوری میکروچیپ و خدمات Google Cloud IoT پیکربندی کلید و گواهی را ساده می کند و مکانیزمی محافظت شده برای تقویت امنیت برنامه های IoT فراهم می آورد. (تصویر: گوگل)

　　این همکاری بین مایکروچیپ و گوگل به توسعه دهندگان اجازه می دهد تا این فرآیند حیاتی مدیریت کلید را به طور کامل از بار خود خارج کنند. برای نیازهای سفارشی، توسعه دهندگان می توانند از عملکرد API CryptoAuthLib atcab_genkey() برای پیاده سازی فرآیند مدیریت کلید خود استفاده کنند که منجر به تولید جفت کلید، ذخیره کلیدهای خصوصی در حافظه امن و بازگرداندن کلید عمومی مرتبط ATECC608A می شود. /پ>

　　برای بررسی تولید کلید و سایر ویژگی های امنیتی ATECC608A، توسعه دهندگان می توانند به سرعت محیط توسعه جامعی را حول کیت ارزیابی Microchip SAM D21 Xplained Pro بسازند. بر پایه Microchip ATSAMD21J18A Arm ® Cortex-M0 ® + MCU 32 بیتی، کیت SAM D21 Xplained Pro یک درایور کامل سخت افزاری و ماژول کد را ارائه می دهد که توسط چارچوب نرم افزاری پیشرفته Microchip (ASF) پشتیبانی می شود.

　　برای ارزیابی دستگاه های CryptoAuthentication، از جمله ATECC608A، توسعه دهندگان می توانند به سادگی برد افزونه CryptoAuth XPRO-B را در یکی از دو سر افزونه برد Xplained Pro قرار دهند. Microchip نرم افزار نمونه ای برای ارزیابی ویژگی های امنیتی CryptoAuthLib و ATECC608A ارائه می دهد. علاوه بر این، توسعه دهندگان می توانند برد افزودنی Wi-Fi Microchip ATWINC1500-XPRO را در هدر دیگری قرار دهند تا نرم افزار نمونه Microchip را اجرا کنند که فرآیند احراز هویت متقابل توصیف شده در این مقاله را نشان می دهد، از جمله احراز هویت سرور TLS و احراز هویت دستگاه JWT.

　　نتیجه گیری

　　اگرچه امنیت برنامه های IoT نیازمندی های متعددی دارد، چالش اصلی اغلب در پیاده سازی احراز هویت متقابل برای دستگاه های IoT و منابع ابری نهفته است. در سیستم های اینترنت اشیا با منابع محدود، پروتکل های سنتی ممکن است از منابع حافظه و پردازش موجود فراتر روند. با استفاده از کتابخانه CryptoAuthLib شرکت Microchip Technology و ATECC608A CryptoAuthentication IC، توسعه دهندگان می توانند رویکردی کارآمدتر مبتنی بر توکن های وب JSON را برای اتصال امن دستگاه های IoT به خدمات Google Cloud اجرا کنند.