بدون کلید، بدون مشکل؟ — بخش دوم ترجمه

۵. پروتکل‌های ارتباطی

این بخش پروتکل‌های ارتباطی برنامه Master Lock و قفل هوشمند و روش‌های رمزنگاری آن‌ها را توصیف می‌کند. تلفن از طریق اینترنت با سرورهای API ارتباط دارد، در حالی که قفل به Wi‑Fi متصل نیست و فقط با BLE با تلفن ارتباط برقرار می‌کند؛ تلفن ممکن است پیام‌ها را به سرور API منتقل کند.

۵.۱. ارتباط تلفن با سرور API

دستگاه‌های BLE Master Lock از سه سرور API استفاده می‌کنند: سرور SDK برای عملیات Firmware، سرور تله‌متری برای جمع‌آوری گزارش‌های ممیزی و سرور API سازمانی برای مدیریت کاربر و دسترسی. endpointهای بازنشانی کارخانه، به‌روزرسانی Firmware و آخرین شاخص ممیزی روی SDK هستند؛ endpointهای بارگذاری رویداد روی telemetry و سایر endpointها روی enterprise API قرار دارند. همه ارتباطات HTTPS با certificate pinning دارند.

احراز هویت SDK و تله‌متری

این دو سرور اعتبارنامه مخصوص کاربر نمی‌خواهند و فقط license و password ثابت می‌گیرند که داخل برنامه و با RSA 2048 بیتی رمزگذاری شده‌اند. کلید خصوصی RSA نیز داخل برنامه و با pad سفارشی XOR شده است. برای SDK و دو سرور تله‌متری آمریکای شمالی و اروپا، جفت‌های متفاوت استفاده می‌شود. پس از احراز هویت، bearer token یک‌ساعته برگردانده می‌شود.

Factory Reset و Firmware Update

برنامه شناسه دستگاه، نسخه Firmware و bearer token معتبر را به SDK می‌فرستد. سرور دنباله‌ای از فرمان‌های رمزگذاری‌شده را بازمی‌گرداند که در cmdfirmware فرمان FirmwareUpdate قرار گرفته و یکی‌یکی به قفل relay می‌شوند.

آخرین شاخص ممیزی و بارگذاری رویدادها

برنامه پیش از upload، آخرین audit event index را از SDK می‌گیرد، آن را افزایش می‌دهد و به‌عنوان شروع ReadAuditTrail به قفل می‌دهد. با end index برگشتی، رویدادهای جدید خوانده می‌شوند و در صورت زیادبودن تعداد، فرایند تکرار می‌شود. سه نوع رویداد بارگذاری می‌شود: encounter، device و virtual. encounter شامل سطح باتری، device ID، زمان و موقعیت مکانی است. device event شامل Firmware update، تغییر ساعت، تلاش نامعتبر و unlock است و type، data، length، event index و firmware counter دارد. virtual در برنامه تعریف شده ولی استفاده نمی‌شود. telemetry برای هر نوع endpoint جدا دارد و upload فقط bearer token و device ID را لازم دارد؛ احراز هویت کاربر، تلفن یا قفل لازم نیست.

Enterprise API

Enterprise API برای اطلاعات دستگاه، profile و key به سازمان، ایمیل و password کاربر نیاز دارد و همراه license/password برنامه ارسال می‌شود. برای آمریکای شمالی و اروپا یک جفت license/password استفاده می‌شود. bearer token برگشتی ۱٫۵ ساعت اعتبار دارد. برنامه با آن شناسه دستگاه، مدل، Firmware، update، مکان، باتری و تنظیمات را می‌گیرد، اما passcode یا session key را دریافت نمی‌کند.

Session Key و Access Profile

پس از device ID، برنامه access profile می‌گیرد:

پس از Base64 decoding، session key برابر ۳۲ بایت، P برابر ۷۰ بایت و index برابر چهار بایت little-endian است. P در StartSession به قفل ارسال می‌شود و شامل رمزگذاری session key است. پاسخ API زمان شروع و پایان اعتبار profile را نیز می‌دهد. قالب باینری cmdfirmware و P در برنامه parse نمی‌شود و اطلاعات دقیق آن‌ها در پیوست A.2 است.

۵.۲. ارتباط تلفن با قفل

تعامل سه مرحله دارد: scan، connect و communicate.

Scan

قفل پس از بیدارشدن با touchpad تبلیغ BLE می‌کند. برنامه رکورد اسکن را parse می‌کند و وجود UUID ۱۲۸بیتی را بررسی می‌کند که باید با UUIDdevice برای وضعیت عادی یا UUIDboot برای bootloader مطابقت داشته باشد. داده سازنده شامل company ID، SKU، device ID و Firmware version است. اگر device ID در فهرست دستگاه‌های مجاز کاربر باشد، اتصال انجام می‌شود.

Connection

تلفن به GATT server قفل وصل می‌شود، service discovery را با UUID سرویس انجام می‌دهد و characteristic با UUIDconn-char و descriptor با UUIDconn-desc را پیدا می‌کند. write و notification فعال می‌شوند تا تلفن پیام بفرستد و پاسخ قفل را دریافت کند.

Communication

StartSession برای احراز هویت و تبادل session key k استفاده می‌شود. profile نامعتبر یا منقضی، شروع نشست را رد می‌کند. پس از آن فرمان‌ها با k رمزگذاری و احراز اصالت می‌شوند و پاسخ‌ها نیز رمزگذاری‌شده‌اند؛ StartSession شامل IV پیش از ciphertext است.

رمزگذاری و رمزگشایی

توابع اصلی رمزنگاری داخل DEX خارجی و رمزگذاری‌شده‌اند و با loader شدیداً obfuscated در runtime بارگذاری می‌شوند. طرح، AES-CCM با embedding سفارشی است. CCM، CBC-MAC و counter mode را ترکیب می‌کند. فرمان‌ها کمتر از ۲^۱۶ بایت‌اند و nonce سیزده‌بایتی برای ساخت IV استفاده می‌شود. Algorithms 1 تا 3 قالب دقیق را مشخص می‌کنند.

الگوریتم ۱ — CmdTag

Input: Key k, nonce n, command cmd; |k| = 32, |n| = 13
cmdencoded ← 19 ∥ n ∥ |cmd|₂ ∥ cmd ∥ 00...0
x ∥ t ∥ y ← AES-CBC.Enc(k,00...0,cmdencoded)
Output: Tag t

الگوریتم ۲ — CmdEnc

Input: Key k, nonce n, command cmd; |k| = 32, |n| = 13
ccmd ← AES-CTR.Enc(k,01 ∥ n ∥ 0001,cmd)
t ← CmdTag(k,n,cmd)
Ct ← AES-CTR.Enc(k,01 ∥ n ∥ 0000,t)
C ← |cmd|₂ ∥ ccmd ∥ Ct
Output: Ciphertext C

الگوریتم ۳ — CmdDec

Input: Key k, nonce n, ciphertext C; |k| = 32, |n| = 13
|cmd|₂ ∥ ccmd ∥ Ct ← C
cmd ← AES-CTR.Dec(k,01 ∥ n ∥ 0001,ccmd)
t′ ← CmdTag(k,n,cmd)
t ← AES-CTR.Dec(k,01 ∥ n ∥ 0000,Ct)
If t′ ≠ t then cmd ← ⊥
Output: cmd or ⊥

اگر P معتبر باشد، قفل nonce کوتاه ns و رمزگذاری error code صفر را برمی‌گرداند تا برنامه یکسان‌بودن session key را بررسی کند. nonce سیزده‌بایتی n با افزودن هفت صفر به ns ساخته می‌شود و ns در هر رمزگذاری/رمزگشایی افزایش می‌یابد؛ پس از ۲^۴۸ افزایش wrap می‌کند.

فرمان‌های داخل نشست، به‌جز خواندن داده، پاسخ را با 00 ∥ CmdEnc(k,n,e) دریافت می‌کنند و فرمان‌های تلفن به قفل، به‌جز StartSession، با 01 ∥ CmdEnc(k,n,cmd) ارسال می‌شوند.

۶. حملات

۶.۱. حمله ۱ — Session Replay

نشست‌های یک کاربر از همان access profile و session key استفاده می‌کنند و قفل برای StartSession همان nonce 000000000001 را انتخاب می‌کند. مهاجم فیزیکی A1 می‌تواند ارتباط کامل BLE را ضبط و بعداً همه بسته‌ها را با همان ترتیب replay کند؛ لازم نیست رمز را بشکند یا profile معتبر داشته باشد. اثر، بازکردن غیرمجاز خانه یا اتاق هتل و نقض G1 است.

۶.۲. حمله ۲ — Exceeding Access

هر access profile طبق metadata سرور ۹ ماه معتبر است. revoke فقط در application layer مانع استفاده از برنامه رسمی می‌شود و profile زیرین تا تاریخ انقضای اصلی معتبر می‌ماند. A2 می‌تواند هنگام دسترسی قانونی profile را استخراج کند و پس از revoke تا انقضا هر فرمانی را بفرستد؛ بنابراین در حالت مورد مطالعه revocation عملاً تا ۹ ماه اثر نمی‌کند و G2 نقض می‌شود.

۶.۳. حمله ۳ — Clock Tampering

WriteTime برای همگام‌سازی ساعت قفل با تلفن است و طبق اطلاعات افشا باید فقط admin بتواند آن را اجرا کند. مهاجم بدون admin می‌تواند GATT client خود را بسازد و فرمان را مستقیماً بفرستد. با عقب‌بردن ساعت، profile موقت پس از expiration نیز معتبر می‌ماند؛ با جلو بردن ساعت، profileهای معتبر منقضی و StartSession رد می‌شود و DoS ایجاد می‌گردد. در نتیجه G2 و G5 نقض می‌شوند.

۶.۴. حمله ۴ — Audit Log Tampering

telemetry API با license/password ثابت و obfuscated داخل APK احراز هویت می‌شود. مهاجم با reverse engineering آن‌ها را بازیابی کرده و می‌تواند event بارگذاری کند؛ eventها در این مسیر رمزگذاری یا authenticated نیستند. device ID از BLE قابل مشاهده است. event index افزایشی است و اگر index از قبل وجود داشته باشد، رویداد جدید رد می‌شود. بنابراین مهاجم فقط پس از آخرین event واقعی می‌تواند جعل کند، اما eventهای واقعی بعدی نیز ممکن است رد شوند. این حمله می‌تواند رویدادهای lock/unlock، تغییر ساعت و تلاش نامعتبر را جعل و گزارش واقعی را پنهان کند؛ G3 نقض می‌شود.

۶.۵. حمله ۵ — Malformed Messages

پیام‌هایی با encoded length متفاوت از actual length می‌توانند قفل را crash کنند. در آزمایش، طول‌های ۶۱۰ تا ۶۵۶۱ باعث بی‌پاسخ‌شدن قفل به BLE و touchpad شدند. طول‌های بزرگ‌ترِ غیرcrash می‌توانند حافظه دیگر را overwrite کنند؛ برای نمونه audit event index. در نتیجه ReadAuditTrail ممکن است داده دلخواه حافظه را برگرداند و پس از upload به telemetry، در صورت parseشدن، افشا شود. eventهای نامعتبر نیز می‌توانند indexهای رویدادهای واقعی را اشغال کنند. A1 با StartSession مخدوش DoS ایجاد می‌کند و A2 می‌تواند برای memory leak/write و استخراج secret تلاش کند، هرچند پژوهشگران بدون Firmware این مسیر را کامل بررسی نکردند.

۶.۶. مسائل امنیتی بیشتر

Fingerprinting فرمان: طول ciphertext با طول plaintext یکسان است، بنابراین شنودکننده می‌تواند از طول، زیرمجموعه فرمان را حدس بزند. استفاده مجدد nonce همچنین امکان جابه‌جایی فرمان‌هایی را که در موقعیت یکسان نشست‌های مختلف قرار دارند ایجاد می‌کند.

CCM سفارشی: nonce فقط شش بایت تصادفی دارد و تازگی آن تضمین نمی‌شود؛ همین reuse حمله ۱ را ممکن کرده است. شمارنده دو بایتی است، هرچند محدودیت MTU و طول فرمان مانع plaintextهای بیش‌ازحد طولانی می‌شود.

۷. اثبات مفهوم

برای بررسی صحت تحلیل، یک برنامه Android با BLE protocol بازسازی‌شده نوشته شد. Firmware آزمایش‌شده D1000 برابر 1679338484 و جدیدترین نسخه در ۵ نوامبر ۲۰۲۴ بود. پژوهشگران ارتباط عادی را با access profile معتبر آزمایش کردند و فرمان‌هایی مانند KeepAlive، unlock، relock، read/write passcode، read/write clock، read audit، battery، temperature و تنظیمات دیگر را اجرا کردند. KeepAlive هر پنج ثانیه اتصال را حفظ می‌کرد و بدون آن، قفل پس از ۹ ثانیه اتصال را می‌بست.

در تأیید حملات، reuse profile در نشست‌های مختلف و replay کامل نشست تأیید شد؛ profile پس از revoke همچنان معتبر بود؛ WriteTime زمان دلخواه گذشته یا آینده را اعمال کرد؛ دو event جعلی Open و Close در برنامه وب ظاهر شدند و event index دو واحد افزایش یافت. در تست malformed length، مقدار کمتر از ۶۱۰ با mismatch باعث بسته‌شدن اتصال و event دسترسی بی‌سیم نامعتبر می‌شد و مقدار بالاتر از ۶۵۶۱ reboot ایجاد می‌کرد. مقدار بزرگ اما غیرcrash مانند ۶۰۹ باعث overwrite شاخص event و برگشت داده تصادفی از ReadAuditTrail شد. Master Lock پس از disclosure buffer overflow را تأیید کرد.

۸. افشا و کاهش آسیب‌پذیری

یافته‌ها در ۱۰ مارس ۲۰۲۵ گزارش شدند و تیم امنیتی Fortune Brands Connected Products در ۱۴ مارس پاسخ داد. درباره منشأ مشکلات و راهکارها گفت‌وگو شد.

Session Replay

برای جلوگیری از replay، قفل باید در هر نشست nonce تصادفی تازه و با فضای رمزنگاری بزرگ انتخاب کند. Master Lock اعلام کرد D1000 تنها محصولی بود که nonce را هنگام شروع اتصال reset می‌کرد و Firmware ژوئن ۲۰۲۵ برای تصادفی‌کردن nonce برنامه‌ریزی شد.

Exceeding Access

راهکار ساده، اتصال امن قفل به API و بررسی اعتبار profile است، اما به اینترنت نیاز دارد. برخی قفل‌ها در مکان‌های دورافتاده و آفلاین استفاده می‌شوند و این کار امنیت را با کارکرد در تضاد قرار می‌دهد. Master Lock گفت معمولاً profileها یک هفته معتبرند، اما D1000 مورد بررسی به دلیل bug قدیمی RTC برای ۹ ماه تنظیم شده بود. برنامه شرکت کاهش این مدت به هفت روز پس از rollout به‌روزرسانی Firmware بود. این mitigation حمله را حذف نمی‌کند، بلکه پنجره حمله را کوتاه می‌کند.