WebRTC چه پروتکل های امنیتی دارد؟ #

هر اتصال WebRTC احراز هویت و رمزگذاری شده است. می‌توانید مطمئن باشید که شخص ثالث نمی‌تواند آنچه را که ارسال می‌کنید ببیند یا پیام‌های جعلی درج کند. همچنین می توانید مطمئن باشید که عامل WebRTC که Session Description را ایجاد کرده است، همانی است که شما با آن در ارتباط هستید.

بسیار مهم است که هیچ کس در آن پیام ها دستکاری نکند. اگر شخص ثالثی توضیحات جلسه را در حال انتقال بخواند مشکلی ندارد. با این حال، WebRTC هیچ حفاظتی در برابر تغییر آن ندارد. یک مهاجم می‌تواند با تغییر ICE Candidates و تغییر گواهی اثر انگشت، یک حمله مرد میانی به شما انجام دهد.

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

WebRTC از دو پروتکل موجود استفاده می‌کند، امنیت لایه انتقال داده‌گرام (DTLS) و پروتکل امن حمل و نقل بلادرنگ (SRTP).

DTLS به شما این امکان را می دهد که در یک جلسه مذاکره کنید و سپس داده ها را به صورت امن بین دو همتا مبادله کنید. این پرتکل شبیه TLS است، همان فناوری که HTTPS را تقویت می کند، اما DTLS از UDP به جای TCP به عنوان لایه انتقال استفاده می کند. این بدان معناست که پروتکل باید چیزی را تحویل دهد که قابل اعتماد نیست. SRTP به طور خاص برای تبادل رسانه ایمن طراحی شده است. بهینه سازی هایی وجود دارد که می توانیم با استفاده از آن به جای DTLS انجام دهیم.

در ابتدا از DTLS استفاده می شود. یک دست دادن(Handshake) بر روی اتصالی که توسط ICE انجام می شد انجام می داد. DTLS یک پروتکل مشتری/سرور است، بنابراین یک طرف باید دست دادن را شروع کند. نقش های کلاینت/سرور در طول سیگنال دهی انتخاب می شوند. در طول دست دادن DTLS، هر دو طرف گواهی ارائه می دهند. پس از تکمیل دست دادن، این گواهی با هش گواهی در توضیحات جلسه مقایسه می شود. این برای اطمینان از اینکه دست دادن با عامل WebRTC که انتظار داشتید اتفاق افتاده است. سپس اتصال DTLS برای استفاده برای ارتباطات DataChannel در دسترس است.

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

امنیت 101 #

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

متن ساده و متن رمزی #

متن ساده ورودی یک رمز است. متن رمزی خروجی یک رمز است.

رمز #

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

یک رمز ساده ROT13 است. هر حرف 13 کاراکتر به جلو منتقل می شود. برای خنثی سازی رمز، 13 کاراکتر را به عقب حرکت می دهید. متن ساده HELLO به متن رمزی URYYB تبدیل می‌شود. در این حالت، رمز ROT است و کلید 13 است.

توابع هش #

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

یک تابع هش ساده این است که فقط حروف دیگر را در بگیرد. HELLO به HLO تبدیل می‌شود. نمی‌توانید فرض کنید HELLO ورودی بوده است، اما می‌توانید تأیید کنید که HELLO با خلاصه هش مطابقت دارد.

رمزنگاری کلید عمومی/خصوصی #

رمزنگاری کلید عمومی/خصوصی نوع رمزهایی را که DTLS و SRTP استفاده می‌کنند. در این سیستم شما دو کلید عمومی و خصوصی دارید. کلید عمومی برای رمزگذاری پیام ها است و به اشتراک گذاری امن است. کلید خصوصی برای رمزگشایی است و هرگز نباید به اشتراک گذاشته شود. این تنها کلیدی است که می تواند پیام های رمزگذاری شده با کلید عمومی را رمزگشایی کند.

تبادل دیفی–هلمن #

تبادل Diffie–Hellman به دو کاربر که قبلا هرگز ملاقات نکرده‌اند اجازه می‌دهد تا یک رمز مشترک را به صورت ایمن از طریق اینترنت ایجاد کنند. کاربر A می تواند بدون نگرانی در مورد استراق سمع، یک رمز را برای کاربر B ارسال کند. پیچیدگی رمزنگاری به دشواری شکستن مسئله لگاریتم گسسته بستگی دارد. شما نیازی به درک کامل نحوه عملکرد این کار ندارید، اما دانستن اینکه این چیزی است که به دست دادن DTLS را ممکن می‌کند.

ویکی‌پدیا نمونه‌ای از این را در عمل دارد اینجا.

تابع شبه تصادفی #

یک تابع شبه تصادفی (PRF) یک تابع از پیش تعریف شده برای تولید مقداری است که تصادفی به نظر می رسد. ممکن است چندین ورودی بگیرد و یک خروجی تولید کند.

تابع مشتق کلید #

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

فرض کنید یک کلید به شما داده شده است که 8 بایت است. می توانید از KDF برای قوی تر کردن آن استفاده کنید.

هیچ (Nonce) #

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

اگر یک پیام را 10 بار رمزگذاری کنید، رمزگذار همان متن رمزی را 10 بار به شما می دهد. با استفاده از یک nonce می‌توانید خروجی‌های متفاوتی دریافت کنید، در حالی که همچنان از یک کلید استفاده می‌کنید. مهم است که برای هر پیام از یک nonce متفاوت استفاده کنید! در غیر این صورت، مقدار زیادی از ارزش را نفی می کند.

کد احراز هویت پیام (MAC) #

کد احراز هویت پیام، همان هش است که در انتهای پیام قرار می گیرد. MAC ثابت می کند که پیام از طرف کاربری که انتظار داشتید می آید.

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

چرخش کلید #

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

DTLS #

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

برای ارتباط یک کلاینت DTLS و یک سرور، باید روی رمز و کلید به توافق برسند. آنها این مقادیر را با انجام یک دست دادن DTLS تعیین می کنند. در حین دست دادن، پیام ها به صورت متن ساده هستند. هنگامی که یک سرویس گیرنده/سرور DTLS جزئیات کافی را برای شروع رمزگذاری رد و بدل می کند، تغییر مشخصات رمز(Change Cipher Spec) را ارسال می کند. پس از این پیام، هر پیام بعدی رمزگذاری می شود!

قالب بسته #

هر بسته DTLS با یک هدر شروع می شود.

نوع محتوا #

شما می توانید نوع های زیر را انتظار داشته باشید:

• 20 - تغییر مشخصات رمز
• 22 - دست دادن
• 23 - داده های برنامه

Handshake برای تبادل جزئیات برای شروع جلسه استفاده می شود. از تغییر مشخصات رمز برای اطلاع دادن به طرف مقابل استفاده می‌شود که همه چیز رمزگذاری خواهد شد. Application Data پیام های رمزگذاری شده هستند.

نسخه #

نسخه می تواند 0x0000feff (DTLS v1.0) یا 0x0000fefd (DTLS v1.2) باشد، نسخه 1.1 وجود ندارد.

####Epoch Epoch از 0 شروع می‌شود، اما پس از تغییر مشخصات رمز به 1 تبدیل می‌شود. هر پیامی با Epoch غیر صفر رمزگذاری شده است.

شماره ترتیب #

Sequence Number برای مرتب نگه داشتن پیام ها استفاده می شود. هر پیام تعداد توالی را افزایش می دهد. هنگامی که دوره افزایش می یابد، شماره توالی دوباره شروع می شود.

طول و بار #

Payload نوع محتوا خاص است. برای هر داده های برنامه، Payload رمزگذاری شده است. برای Handshake بسته به پیام متفاوت خواهد بود. طول به میزان بزرگی بار محموله است.

مکانیسم حالت دست دادن #

در حین دست دادن، مشتری/سرور یک سری پیام را مبادله می کند. این پیام ها در دسته هایی گروه بندی می شوند. هر دسته ممکن است چندین پیام در خود داشته باشد (یا فقط یک). یک دسته تا زمانی که تمام پیام‌های موجود در دسته دریافت نشده باشد کامل نمی‌شود. در زیر هدف هر پیام را با جزئیات بیشتر شرح خواهیم داد.

![دست دادن](../images/04-handshake.png دست دادن)

####ClientHello ClientHello پیام اولیه ارسال شده توسط مشتری است. این شامل لیستی از ویژگی ها است. این ویژگی ها رمزها و ویژگی هایی را که مشتری پشتیبانی می کند را به سرور می گوید. برای WebRTC به این صورت است که رمز SRTP را نیز انتخاب می کنیم. همچنین حاوی داده های تصادفی است که برای تولید کلیدهای جلسه استفاده می شود.

HelloVerifyRequest #

HelloVerifyRequest توسط سرور برای مشتری ارسال می شود. برای اطمینان از اینکه مشتری قصد ارسال درخواست را داشته است. سپس کلاینت ClientHello را مجدداً ارسال می کند، اما با یک توکن ارائه شده در HelloVerifyRequest.

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

گواهی #

گواهی شامل Certificate برای مشتری یا سرور است. از این برای شناسایی منحصر به فرد افرادی که با آنها در ارتباط بودیم استفاده می شود. پس از پایان دست دادن، مطمئن می شویم که این گواهی زمانی که هش می شود با اثر انگشت در Description Session مطابقت داشته باشد.

ServerKeyExchange/ClientKeyExchange #

این پیام ها برای انتقال کلید عمومی استفاده می شود. هنگام راه اندازی، مشتری و سرور هر دو یک جفت کلید ایجاد می کنند. پس از دست دادن، از این مقادیر برای ایجاد Pre-Master Secret استفاده می شود.

####CertificateRequest یک CertificateRequest توسط سرور ارسال می شود و به مشتری اطلاع می دهد که گواهی می خواهد. سرور می تواند درخواست یا نیاز به گواهی داشته باشد.

####ServerHelloDone ServerHelloDone به مشتری اطلاع می دهد که کار سرور با دست دادن تمام شده است.

####CertificateVerify CertificateVerify روشی است که فرستنده ثابت می کند که کلید خصوصی ارسال شده در پیام Certificate را دارد.

ChangeCipherSpec #

ChangeCipherSpec به گیرنده اطلاع می دهد که هر چیزی که پس از این پیام ارسال می شود رمزگذاری خواهد شد.

####Finished Finished رمزگذاری شده است و حاوی هش از همه پیام‌ها است. این برای اثبات این است که دست دادن دستکاری نشده است.

نسل کلید #

پس از اتمام Handshake، می توانید شروع به ارسال داده های رمزگذاری شده کنید. رمز توسط سرور انتخاب شده و در ServerHello قرار دارد. چگونه این کلید انتخاب می شود؟

ابتدا Pre-Master Secret را تولید می کنیم. برای به دست آوردن این مقدار، Diffie–Hellman روی کلیدهای مبادله شده توسط ServerKeyExchange و ClientKeyExchange استفاده می شود. جزئیات بسته به رمز انتخابی، متفاوت است.

سپس Master Secret تولید می شود. هر نسخه از DTLS یک Pseudorandom function تعریف شده دارد. برای DTLS 1.2 این تابع مقادیر Pre-Master Secret و مقادیر تصادفی را در ClientHello و ServerHello می گیرد. خروجی اجرای Pseudorandom function Master Secret است. Master Secret مقداری است که برای رمز استفاده می شود.

تبادل داده های برنامه #

نقطه قوت DTLS چیزی جز ApplicationData نیست. اکنون که یک رمز اولیه داریم، می توانیم رمزگذاری و ارسال مقادیر را شروع کنیم.

پیام‌های ApplicationData از هدر DTLS همانطور که قبلاً توضیح داده شد استفاده می‌کنند. Payload با متن رمز پر شده است. شما اکنون یک جلسه DTLS در حال کار دارید و می توانید به طور ایمن ارتباط برقرار کنید.

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

SRTP #

SRTP یک پروتکل است که به طور خاص برای رمزگذاری بسته های RTP طراحی شده است. برای شروع یک جلسه SRTP، کلیدها و رمز خود را مشخص می کنید. برخلاف DTLS مکانیسم دست دادن ندارد. تمام تنظیمات و کلیدها در حین دست دادن DTLS ایجاد شدند.

DTLS یک API اختصاصی برای صادر کردن کلیدها برای استفاده در فرآیند دیگری فراهم می کند که در RFC 5705 تعریف شده است.

ایجاد جلسه #

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

تبادل رسانه #

هر بسته RTP یک SequenceNumber 16 بیتی دارد. این اعداد ترتیبی برای مرتب نگه داشتن بسته ها مانند کلید اصلی استفاده می شود. در طول یک تماس، اینها جابجا می شوند. SRTP آن را ردیابی می کند و آن را rollover counter می نامد.

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