همه چیز درباره MTProto و امنیت در تلگرام
همه چیز درباره MTProto و امنیت در تلگرام
پروتکل موبایل MTProto
توضیحات کلی
این پروتکل به منظور دسترسی به یک سرور API از اپلیکیشنهای دستگاههای موبایل طراحی شده است. لازم به ذکر است که مرورگرهای وب جزء این اپلیکیشنها نمیباشند.
پروتکل مذکور به اجزاء سازندهی زیر تقسیم میشود
جزء بالادستی (زبان کوئری API): معرف روشی است که پرسشها و پاسخهایAPI به وسیلهی آن به پیامهای باینری تبدیل میشوند.
لایهی رمزنگاری (صدور مجوز): معرف روشی است که پیامها پیش از ارسال از طریق پروتکل انتقال رمزگذاری میشوند.
جزء انتقال: معرف روشی برای کلاینت و سرور برای ارسال پیامها به یک پروتکل شبکه دیگر (مانند http, https, tcp, udp) میباشد.
نکته ۱
- هر پیام متنی ساده که در MTProto رمزگذاری شود همواره شامل اطلاعات زیر است که لازم است طی رمزگشایی چک شوند تا سیستم را در مقابل مشکلات شناخته شدهی اجزاء قوی کنند:
- زمان
- طول پیام
- ترتیب عددی پیام
- آی دی session
- Server salt (64bit)
نکته ۲
گفتگوهای محرمانه تلگرام از یک لایه رمزگذاری علاوه بر آنچه در بالا شرح داده شد نیز استفاده می کنند. برای جزئیات بیشتر https://core.telegram.org/api/end-to-end را ببینید.
ایده هایی برای ساخت ربات تلگرام
جزء بالادستی(زبان کوئری RPC/API)
از نظرگاه جزء سطح بالا، کلاینت و سرور پیامها را در یک session تبادل میکنند. این session بیشتربه یک دستگاه کلاینت (به بیان دقیقتر اپلیکیشن) متصل است تا یک ارتباط http/https/tcp connection. علاوه براین هرsession به یک آی دی کلیدی کاربر متصل است که مجوزدهی در واقع از طریق آن صورت میپذیرد.
ممکن است چندین کانکشن به یک سرور باز باشند. پیامها میتوانند از طریق هر کدام از کانکشن ها و در هر جهتی ارسال شوند(پاسخ یک کوئری الزاماً از طریق همان کانکشنی که کوئری اصلی را انتقال داده بود برگشت داده نمیشود، گرچه اکثر اوقات به هرحال یک پیام نمیتواند از طریق کانکشنی که به یک session متفاوت تعلق دارد برگشت داده شود). زمانی که از پروتکل UDP ستفاده می شود ممکن است پاسخ به آی پی دیگری غیر از آنی که کوئری به آن ارسال شده بود فرستاده شود.
چندین نوع پیام وجود دارد:
- تماسهایRPC(کلاینت به سرور): تماسهای به روش API
- پاسخهای RPC(سرور به کلاینت): نتایج تماسهای RPC
- تاییدیه دریافت پیام (یا به عبارت بهتر، وضعیت پیام ارسال شده)
- کوئری پیام ارسال شده
- پیام چند بخشی یا منبع (منبعی که حاوی چند پیام است و برای ارسال چند تماس آر پی سی در لحظه از طریق یک کانکشن HTTP مورد نیاز است)
از نقطه نظر پروتکلهای پاییندستیتریک پیام دادهای است باینری که در یک محدودهی ۴ یا ۱۶ بایتی ردیف شده است. چند فیلد ابتدایی یک پیام ثابت بوده و توسط سیستم مجوزدهی/رمزگذاری مورد استفاده قرار میگیرند.
هر پیام چه به صورت منفرد چه درون یک منبع، از یک شناساگر پیام(۶۴ بیتی)،یک توالی اعداد در یک سشن(۳۲ بیتی)، طول(بدنه پیام به بایت، ۳۲ بیتی) و .یک بدنه(به هر اندازهای از یک مضرب ۴) تشکیل شده است علاوه براین زمانی که یک منبع یا یک پیام ارسال میشود، یک عنوان داخلی به ابتدای پیام اضافه میشود سپس کل پیام رمزگذاری میشود و یک عنوان خارجی در ابتدای پیام قرار میگیرد(یک کلید شناساگر ۶۴بیتی و یک کلید پیام ۱۲۸ بیتی).
بدنه پیام به طور معمول از یک مدل پیام ۳۲ بیتی تشکیل شده که پارامترهای وابسته به مدل به دنبال آن آورده میشوند. به طور مشخص هر تابع آر پی سی دارای یک مدل پیام معدل می باشد.
مجوزدهی و رمزگذاری
پیش از مخابره یک پیام(یا یک پیام چند بخشی) از طریق یک شبکه با استفاده از پروتکل انتقال، این پیام به طریق خاصی رمزگذاری میشود و یک عنوان خارجی به ابتدای پیام اضافه میشود که عبارت است از: یک کلید شناساگر۶۴ بیتی (که به طور خاص یک کلید مجوزدهی را برای سرور و کلاینت مشخص میکند).
کلید کاربر به همراه کلید پیام یک کلید ۲۵۶ بیتی را تعریف میکنند که پیام را با استفاده از شیوهی AES-256 رمزگذاری میکنند.
به خاطر داشته باشید که بخش ابتدایی پیام که باید رمزگذاری شود اطلاعات متنوعی را در بر دارد(session، آی دی پیام، رقم توالی، server salt) که کلید پیام را تشکیل میدهد(و در نتیجه بر روی کلید AES اثر می گذارد). کلید پیام به عنوان جزء ۱۲۸ بیتی پایین دستی SHA1 بدنه پیام تعریف میشود(شامل session، آی دی پیام و …). پیامهای چند قسمتی به عنوان یک مسیج واحد رمزگذاری میشوند.
برای توضیحات فنی در این خصوص به پروتکل موبایل: توضیح جزئیات مراجعه کنید. اولین کاری که اپلیکیشن کلاینت باید انجام دهد ساختن یک کلید مجوزدهی است که معمولاً هنگامی که برای اولین بار اجرا میشود تولید شده و تقریباً هیچگاه تغیر نمیکند.
مانع اصلی بر سر راه پروتکل عامل مزاحمی است که مانع ارسال پیامها شده و سپس کلید مجوزدهی را تصاحب میکند(برای مثال زمانی که یک دستگاه به سرقت میرود) و میتواند تمام پیامها را رمزگشایی کند.
ربات ساخت نظرسنجی در تلگرام
احتمالاً این یک مشکل محسوب نمیشود(با سرقت یک دستگاه همچنین میتوان به تمامی اطلاعات موجود روی دستگاه بدون رمزگشایی دسترسی پیدا کرد). به هر حال برای غلبه بر این ضعف میتوان این کارها را انجام داد:
- کلیدهای session تولید شده به وسیلهی پروتکل Diffie-Hellman که در اتصال با کلیدهای مجوزدهی و کلیدهای پیام برای انتخاب پارامترهای AES به کار گرفته شدهاند. برای ساختن آنها اولین کاری که یک کلاینت پس از ساخت یک session باید انجام دهد، ارسال یک کوئری RPC مخصوص به سرور است («generate session key») تا سرور به آن پاسخ دهد، که در نتیجهی آن تمامی پیامهای پس از آن در session با استفاده از کلید session رمزگذاری میشوند.
- حفاظت از کلید ذخیره شده بر روی دستگاه کلاینت با یک گذرواژهی متنی. این گذرواژه هیچگاه در حافظه ذخیره نمیشود و با اجرای اپلیکیشن توسط کاربر وارد میشود.
- اطلاعات ذخیره شده بر روی دستگاه کاربر همچنین می تواند با رمزگذاری به وسیلهی یک کلید مجوزدهی (که با یک گذرواژه محافظت میشود) رمزگذاری شود. پس از آن حتی برای دسترسی به آن اطلاعات یک گذرواژه نیاز خواهد بود.
هم زمان سازی
اگر اختلاف زمانی کلاینت و سرور زیاد باشد، ممکن است به علت وجود یک شناساگر(که به زمان ایجاد مربوط است) پیام نامعتبر سرور پیامهای کلاینت را به رسمیت نشناسد یا بالعکس. تحت این شرایط، سرور پیام خاصی را به کلاینت ارسال میکند که حاوی زمان صحیح و یک salt ۱۲۸ بیتی مشخص است (که یا مشخضاً توسط کلاینت طی یک درخواست همزمانسازی RPC مخصوص فراهم شده و یا همان آخرین کلید پیام دریافت شده از کلاینت در session فعلی میباشد). این پیام اولین پیام در منبعی است که حاوی دیگر پیامهاست(این اتفاق در حالتی رخ میدهد که اختلاف زمانی بارز است ولی نه به میزانی که موجب رد شدن و به رسمیت شناخته نشدن پیامهای کلاینت شود).
با دریافت چنین منبع یا منبعی که حاوی این پیام باشد، کلاینت ابتدا فرآیند هم زمان سازی را به عمل می آورد ( که در اثر آن به سادگی تفاوت زمانی میان زمان سرور و زمان خود را ذخیره می کند تا بتواند در آینده زمان صحیح را محاسبه کند) و پس از آن بر اساس نتیجه صحت شناساگر پیام ها را بررسی می کند.
ربات هوشمند قرعه کشی در تلگرام
زمانی که اصلاحاتی از قلم افتاده باشند، کلاینت مجبور خواهد بود session جدید ی تولید کرده و ازیکنواختی شناساگر پیام ها اطمینان حاصل کند.
انتقال
فرآیند انتقال تحویل منابع رمزگذاری شده به صورت یکجا به همراه عنوان خارجی از سرور به کلاینت و بالعکس، را ممکن می سازد (که نام این فرآیند Payload می باشد). سه مدل فرآیند انتقال وجود دارد:
- HTTP
- TCP
- UPD
انتقال HTTP
این مدل انتقال بر بروی HTTP/1.1 پیادهسازی و از طریق TCP Port 80 قدیمی اجرا می شود. HTTPS مورد استفاده قرار نگرفته و به جای آن روش رمزگذاری فوق استفاده می شود.
یک کانکشن HTTP به یک session مشخص در آخرین کوئری دریافتی کاربر متصل است که session مربوطه در تمامی کوئری ها یکسان بوده ولی پروکسیهای HTTP جعلی ممکن است آن را مخدوش کنند. سرور اجازهی ورود هیچ پیامی را به یک کانکشن HTTP نمیدهد مگر اینکه به همان session تعلق داشته باشد و در عین حال نوبت سرور باشد (یک درخواست HTTP از کلاینت دریافت شده باشد که پاسخ آن هنوز ارسال نشده باشد). سپس کلاینت یک یا دو کانکشن HTTP را به سرور باز می کند. اگرقرار باشد پیام یا پیام هایی ارسال شوند، تبدیل به یک payload می شوند که از پی یک درخواست POST به URL/api منتقل می شوند. لازم به ذکر است Content-Length, Keepalive و Host هدرهای معتبر HTTP می باشند.
۲ دیدگاه
[…] امنیت در تلگرام […]
[…] امنیت در تلگرام […]