رمزنگاری ثابت می‌کند پیام شما قفل است؛ شماره امنیتی ثابت می‌کند کلید آن قفل در دست چه کسی است.
رمزنگاری سرتاسری به‌تنهایی به شما نمی‌گوید در آن سر خط، واقعاً همان شخصی نشسته است که فکر می‌کنید. «شماره امنیتی» دقیقاً برای همین ساخته شده: رشته‌ای از اعداد که از کلیدهای واقعی همان گفت‌وگو ساخته می‌شود، و مقایسهٔ آن از یک مسیر بیرونی تنها راه عملی برای فهمیدن این است که کلیدِ رمزنگاری بی‌سروصدا با کلید یک مهاجم جابه‌جا نشده باشد. اگر این مقایسه را انجام ندهید، در بهترین حالت می‌دانید چت شما رمز شده است — نه اینکه برای چه کسی رمز شده است.
نکات کلیدی
- شماره امنیتی یک رشتهٔ کوتاه از اعداد است که از کلیدهای عمومی همان گفت‌وگو ساخته می‌شود؛ تأیید آن ثابت می‌کند پیام‌های شما با کلیدی رمز می‌شوند که طرف مقابل هم همان را روی دستگاه خودش دارد.
- حمله مرد میانی در پیام‌رسان امن با شکستن رمزنگاری انجام نمی‌شود، بلکه با جایگزین‌کردن کلید انجام می‌شود؛ قربانی تا وقتی شماره امنیتی را بیرون از چت مقایسه نکند، هیچ نشانه‌ای نمی‌بیند.
- هشدار تغییر کلید رمزنگاری همیشه به معنای حمله نیست — نصب مجدد برنامه، دستگاه جدید یا بازیابی حساب هم آن را می‌سازد — اما تا وقتی با یک کانال مستقل مطمئن نشده‌اید که علت بی‌خطر بوده، باید با آن مثل یک رخداد امنیتی رفتار کنید.
- برای بررسی شماره امنیتی هیچ نیازی به اسکن QR نیست؛ خواندن بلند اعداد در یک تماس صوتی یا مقایسهٔ حضوری همان نتیجه را می‌دهد و QR فقط میان‌بری برای وارد نکردن رقم‌ها است.
- در لیوارا شماره‌های امنیتی نسخهٔ ۳ روی یک پشتهٔ ترکیبی پساکوانتومی برای پیام‌ها می‌نشینند: LVR1 برای چت‌های دونفره و LGS1 برای گروه‌های خصوصی؛ کانال‌های پخش عمومی از ابتدا عمومی‌اند و رمزنگاری سرتاسری ندارند.
شماره امنیتی پیام‌رسان چیست و دقیقاً چه چیزی را تأیید می‌کند؟
شماره امنیتی یک اثر انگشت کوتاه‌شده از کلیدهای عمومی همان گفت‌وگو است، و تأیید آن فقط یک چیز را ثابت می‌کند: کلیدی که برنامه پیام‌های شما را با آن رمز می‌کند، همان کلیدی است که طرف مقابل روی دستگاه خودش نگه می‌دارد. کلید عمومی را می‌توان مثل قفل یک صندوق تصور کرد؛ پیام شما در آن صندوق گذاشته می‌شود و فقط کسی که کلید خصوصی متناظر را دارد می‌تواند بازش کند. اگر کسی جای آن قفل را با قفل خودش عوض کند، پیام در راه خوانده می‌شود و هر دو طرف هم متوجه نمی‌شوند.
شماره امنیتی از کلیدهای هویت دو طرف ساخته می‌شود، پس هم شما و هم طرف مقابل یک عدد یکسان می‌بینید. همین ویژگی، مقایسه را ممکن می‌کند: دو نفر روی دو دستگاه جدا باید دقیقاً یک رشتهٔ عددی را ببینند.
مهم است که محدودیتش را هم در همان جمله بگوییم: تأیید شماره امنیتی ثابت نمی‌کند پشت آن حساب کدام انسان نشسته است، ثابت نمی‌کند دستگاه طرف مقابل سالم است، و هیچ چیز دربارهٔ کانال‌های عمومی نمی‌گوید. اگر گوشی طرف مقابل به بدافزاری آلوده باشد که صفحه را می‌خواند، کلید سالم است و رمزنگاری هم درست کار می‌کند، اما محتوا هم‌زمان دست مهاجم هم هست. شماره امنیتی خطر را در یک نقطه — جابه‌جایی کلید در مسیر — می‌بندد، نه در همهٔ نقاط.
حمله مرد میانی در پیام‌رسان امن چطور رخ می‌دهد؟
مهاجم رمز را نمی‌شکند؛ کلید را عوض می‌کند. در حمله مرد میانی، او خودش را در وسط گفت‌وگو قرار می‌دهد و به هر طرف کلیدی می‌دهد که ادعا می‌کند مال طرف دیگر است. از آن لحظه، برنامهٔ شما پیام را با کلید مهاجم رمز می‌کند، او رمزگشایی می‌کند، متن را می‌خواند و دوباره با کلید واقعی طرف مقابل رمز می‌کند و می‌فرستد. هر دو نفر قفل سبز، تیک تحویل و همهٔ نشانه‌های عادی را می‌بینند.
نکتهٔ کلیدی این است که رمزنگاری سرتاسری لوله را محافظت می‌کند؛ اگر دو سر آن لوله را مهاجم انتخاب کرده باشد، محرمانگی فقط ظاهر دارد. راه‌حل رمزنگاری نامتقارن هم همین است: چیزی را از مسیری بررسی کنید که مهاجم کنترلش نمی‌کند. اینجاست که مقایسهٔ اعداد — همان چیزی که در راهنمای چطور یک چت رمزنگاری‌شده را تأیید کنیم گام‌به‌گام آمده — تبدیل به تنها دفاع واقعی می‌شود.
یک محدودیت را هم روشن بگوییم: برای اجرای چنین حمله‌ای، مهاجم باید جایی از زنجیره را در دست داشته باشد — سرور، مسیر توزیع کلید، به‌روزرسانی برنامه یا خود دستگاه. به همین دلیل بررسی یکپارچگی نسخهٔ نصب‌شده هم بخشی از همین بحث است: در لیوارا می‌توانید چک‌سام SHA-256 منتشرشدهٔ فایل APK را خودتان و آفلاین در آزمایشگاه اثبات با فایل نصب‌شده مقایسه کنید.
تأیید اثر انگشت کلید در چت را چطور انجام دهیم؟
روش کار ساده است: بخش امنیت را در پروفایل مخاطب باز کنید، اعداد را ببینید و همان اعداد را از یک کانال کاملاً جدا با طرف مقابل مقایسه کنید. در بیشتر پیام‌رسان‌ها این مسیر در پروفایل مخاطب زیر عنوان «امنیت»، «تأیید» یا «شماره‌های امنیتی» قرار دارد و رشتهٔ عددی معمولاً در بلوک‌های دو یا سه رقمی نمایش داده می‌شود.
ترتیب کار:
۱. پروفایل مخاطب را باز کنید و شماره امنیتی را پیدا کنید.
۲. اعداد را با طرف مقابل رو در رو، در یک تماس صوتی، یا از طریق پیام‌رسان دیگری بخوانید — نه در همان گفت‌وگویی که می‌خواهید تأییدش کنید.
۳. کل رشته را مقایسه کنید، نه فقط چند رقم اول را.
۴. اگر حتی یک بلوک جابه‌جا بود، همان‌جا متوقف شوید و چیزی حساس نفرستید.
۵. هر بار که یکی از دو دستگاه کلیدش را عوض می‌کند، نتیجهٔ تأیید باطل می‌شود و باید دوباره انجام شود.
دو محدودیت جدی وجود دارد. اول، کانالی که برای مقایسه انتخاب می‌کنید باید خودش قابل اعتماد باشد؛ اگر هشدار کلید را همان‌جا ببینید که به آن مشکوکید، مقایسه ارزشی ندارد. دوم، تأیید یک‌بار برای همیشه نیست. کلیدها عوض می‌شوند و هر تغییر، تأیید قبلی را بی‌اعتبار می‌کند؛ به همین دلیل در لیوارا شماره‌های امنیتی نسخهٔ ۳ همراه با هشدار تغییر کلید کار می‌کنند، نه به‌جای آن.
بررسی شماره امنیتی بدون اسکن QR ممکن است؟
بله، و هیچ امنیتی از دست نمی‌رود: QR و رشتهٔ اعداد از یک داده ساخته می‌شوند و دقیقاً یک چیز را تأیید می‌کنند. کد QR فقط تایپ را حذف می‌کند و احتمال خطای انسانی در خواندن رقم‌ها را کم می‌کند؛ اگر دوربین در دسترس نیست، طرف مقابل راه دور است، یا فایل صفحه را نمی‌توانید جابه‌جا کنید، خواندن بلند اعداد در یک تماس صوتی همان نتیجه را می‌دهد.
برای موارد واقعاً حساس، خواندن اعداد در حضوری که هر دو نفر می‌توانند دستگاه طرف مقابل را ببینند دقیق‌ترین حالت است، چون در تماس صوتی هم امکان جعل صدا وجود دارد. QR هیچ لایهٔ رمزنگاری اضافه‌ای روی اعداد نمی‌گذارد و اسکن‌نکردن QR چیزی از امنیت شما کم نمی‌کند.
هشدار تغییر کلید رمزنگاری را چطور تفسیر کنیم؟
این هشدار یعنی کلیدی که طرف مقابل الان استفاده می‌کند با کلیدی که پیش‌تر تأیید کرده بودید یکی نیست. دلایل بی‌خطر آن کاملاً معمول است: نصب مجدد برنامه، خرید دستگاه جدید، پاک‌کردن داده‌های برنامه، یا بازیابی حساب روی سخت‌افزار تازه. در همهٔ این حالت‌ها کلید از نو ساخته می‌شود و هشدار به‌درستی فعال می‌شود.
اما از بیرون، حالت بی‌خطر و حالت حمله شکل یکسانی دارند و شما نمی‌توانید با نگاه‌کردن به هشدار بفهمید کدام‌یک است. پس رویهٔ درست این است: تا وقتی مطمئن نشده‌اید، محتوای حساس نفرستید؛ از یک کانال دیگر از طرف مقابل بپرسید دستگاه یا برنامه‌اش را عوض کرده یا نه؛ و بعد از توضیح قانع‌کننده، خیلی معمولی حرف بزنید و بعد شماره امنیتی جدید را تأیید کنید.
یک محدودیت مهم را نباید پنهان کرد: چیزی که در بازهٔ پیش از کشف هشدار فرستاده یا دریافت شده، ممکن است خوانده شده باشد. رمزنگاری رو‌به‌جلو گذشته را پاک نمی‌کند. در لیوارا، رچت دوره‌ای LVR1 امنیت پس از افشا را فراهم می‌کند، یعنی پس از مرحلهٔ بعدی رچت، کلید افشاشده دیگر پیام‌های تازه را نمی‌خواند — اما پیام‌های رد‌وبدل‌شدهٔ پیش از آن را به عقب برنمی‌گرداند. اگر می‌خواهید بدانید غیر از متن پیام چه چیزی ممکن است در دسترس باشد، توضیح متادیتای پیام‌رسان چه چیزهایی را لو می‌دهد تصویر کامل‌تری می‌دهد.
تشخیص دستکاری کلید در چت خصوصی با چه نشانه‌هایی ممکن است؟
صریح‌ترین نشانه، همان هشدار تغییر کلید است؛ نشانه‌های غیرمستقیم همیشه ضعیف‌تر و گمراه‌کننده‌ترند. مواردی که ارزش توجه دارند: هشداری که طرف مقابل برایش توضیح روشنی ندارد، اصرار او بر اینکه دستگاهش را عوض نکرده، پاسخ‌دادن به پیام‌هایی که شما هرگز نفرستاده‌اید، تفاوت روایت دو نفر از یک گفت‌وگوی واحد، و تأییدی از شماره امنیتی که هیچ‌وقت جور نمی‌شود.
محدودیت این فهرست را باید صریح گفت: نبودن این نشانه‌ها دلیل سالم‌بودن نیست. مهاجم خوب دیده نمی‌شود و کارش دقیقاً همین است که همه‌چیز عادی به نظر برسد؛ بنابراین «حس می‌کنم مشکلی نیست» جای تأیید واقعی را نمی‌گیرد. تنها سنجه‌ای که به مهاجم وابسته نیست، مقایسهٔ اعداد از یک مسیر بیرونی است.
اگر Signal شفافیت کلید را خودکار تأیید می‌کند، چرا شماره امنیتی هنوز لازم است؟
چون شفافیت کلید یک بررسی سروری است، در حالی که شماره امنیتی چیزی است که خود دو کاربر در دو سر گفت‌وگو با هم می‌سنجند — و این دو، جای هم را نمی‌گیرند. طبق گزارش AboutSignal، در ۱۲ اوت ۲۰۲۶ قابلیتی به نام Automatic Key Verification معرفی شد که بر پایهٔ شفافیت کلید کار می‌کند و کمک می‌کند دستگاه‌ها بر سر این توافق داشته باشند که کدام کلید به کدام شناسه تعلق دارد. همان گزارش تصریح می‌کند این قابلیت هویت شخص پشت حساب را تأیید نمی‌کند.
جزئیات فنی آن هم روشن است: بر پایهٔ گزارش protect.computer، دو حسابرس مستقل، Cloudflare و Trail of Bits، یکپارچگی گفت‌وگوها را بررسی می‌کنند تا مطمئن شوند کلید عمومی مرتبط با یک شماره یا نام کاربری واقعی است و بی‌سروصدا با کلید مهاجم عوض نشده است. این دقیقاً همان سناریویی است که جابه‌جایی کلید بدون اطلاع صاحب کلید را پوشش می‌دهد.
اما تحلیل Shield53 که بر گزارش BleepingComputer تکیه دارد، صریح می‌گوید این قابلیت یک گلولهٔ جادویی نیست و سازمان‌ها برای حفاظت کامل به گام‌های بیشتری نیاز دارند. دلیلش هم ساده است: شفافیت کلید به زیرساخت، حسابرس و درستی آن زیرساخت وابسته است، در حالی که مقایسهٔ اعداد در دو دستگاه، تنها گامی است که در کنترل خود کاربر است. لیوارا همان مسیر دستی و قابل‌کنترل را انتخاب کرده: شماره‌های امنیتی نسخهٔ ۳ که هر کاربر می‌تواند مستقل از هر سرور و هر حسابرس، با طرف مقابل بسنجد.
شماره امنیتی در لیوارا: چت خصوصی رمزنگاری‌شده، کانال عمومی خواندنی
در لیوارا لایه‌های رمزنگاری و تأیید هویت طوری چیده شده‌اند که هم قابل بررسی باشند و هم مرزهایشان روشن باشد. پیام‌های دونفره با پروتکل LVR1 رد‌وبدل می‌شوند: یک رچت ترکیبی پساکوانتومی که در آن یک رچت ECDH روی منحنی P-256 و یک رچت دوره‌ای ML-KEM-768 پهلو‌به‌پهلو کار می‌کنند و کلید هر پیام از هر دو ساخته می‌شود؛ نتیجه، رمزنگاری رو‌به‌جلو و امنیت پس از افشا است. ML-KEM-768 همان الگوریتم استانداردشده در FIPS 203 سازمان NIST است و بقیهٔ اجزا هم مشخصات شناخته‌شده‌اند: HKDF-SHA-256 بر پایهٔ RFC 5869، رمزنگاری AES-256-GCM با نانس ۱۲ بایتی و برچسب ۱۶ بایتی، و امضاهای ECDSA P-256 با SHA-256.
گروه‌های خصوصی با پروتکل LGS1 کار می‌کنند، جایی که کلید فرستنده در پاکت‌های دونفرهٔ LVR1 بسته‌بندی می‌شود؛ یعنی پیام گروهی هم پساکوانتومی است، ولی هر عضو همچنان باید کلید دونفرهٔ خودش را با بقیه تأیید کند. تصاویر، ویدیوها، فایل‌ها، زیرنویس و پیام‌های صوتی هم هرکدام یک کلید محتوای تصادفی ۳۲ بایتی تازه می‌گیرند و پیش از بارگذاری رمز می‌شوند؛ آن کلید داخل همان مسیر LVR1 یا LGS1 سفر می‌کند. تماس صوتی و تصویری، چه دونفره و چه گروهی (۲ تا ۶ نفر در اندروید)، با WebRTC DTLS-SRTP محافظت می‌شود و سیگنالینگ تماس هم به‌صورت یک پیام دونفرهٔ معمولی فرستاده می‌شود. این لایه پساکوانتومی نیست: رسانهٔ تماس روی همان گارد کلاسیک WebRTC می‌ایستد و رچت پساکوانتومی فقط پیام‌ها و محتوای فایل را پوشش می‌دهد، نه صدا و تصویر تماس.
برای ورود، رمز عبور هرگز روی شبکه فرستاده نمی‌شود: پروتکل SRP بر پایهٔ RFC 5054 دانش رمز را با یک اثبات دانش‌صفر تأیید می‌کند. محدودیت این لایه را هم بگوییم تا اشتباه گرفته نشود: SRP ثابت می‌کند رمز شما درست است و از ارسال و ذخیره‌شدن آن جلوگیری می‌کند؛ کاری به هویت طرف مقابل ندارد و جای شماره امنیتی را نمی‌گیرد. برای درک نقشهٔ کامل اینکه چه کسی چه چیزی را می‌بیند، مدل تهدید لیوارا مرجع دقیق‌تری است، و اگر می‌خواهید بدانید چرا لایهٔ پساکوانتومی امروز و نه ده سال بعد اهمیت دارد، رمزنگاری پساکوانتومی در پیام‌رسان این بحث را باز می‌کند.
مرزها را باید بی‌پرده گفت. کانال‌ها در لیوارا عمداً عمومی و رمزنگاری‌نشده‌اند: یک کانال، رسانهٔ پخش یک‌طرفه برای مخاطب نامحدود است، نه گفت‌وگوی خصوصی، و همین خوانا بودن است که به لیوارا اجازه می‌دهد به گزارش‌ها رسیدگی کند و کانال‌های متخلف را حذف کند. هیچ‌وقت محتوای کانال را سرتاسری‌رمزشده تصور نکنید. همچنین متادیتای مسیریابی معمول — فرستنده، مقصد و زمان تحویل — برای همگام‌سازی دستگاه‌ها ذخیره می‌شود و بخشی از حریم خصوصی است که رمزنگاری محتوا پوشش نمی‌دهد. دو مرز دیگر را هم باید در همان جمله گفت: عضویت و مدیریت گروه‌های خصوصی در سرور کنترل می‌شود، پس لایهٔ رمزنگاری گروه تعیین نمی‌کند چه کسی عضو است؛ و برای پروتکل‌های لیوارا ممیزی مستقل شخص ثالثی منتشر نشده است، پس اعتبارشان را باید از مشخصات و آزمون‌پذیری خودشان سنجید، نه از یک برچسب. تأیید شماره امنیتی هم چون کار خود کاربران است، به چنین ممیزی وابسته نیست.
پرسش‌های پرتکرار
شماره امنیتی را از کجا پیدا کنم؟
در لیوارا، شماره‌های امنیتی نسخهٔ ۳ از پروفایل مخاطب و بخش «امنیت» یا «تأیید» باز می‌شود و بدون اسکن QR قابل مقایسه است. اگر در یک پیام‌رسان این بخش وجود نداشت و فقط به عبارتی کلی مثل «رمزنگاری سرتاسری فعال» بسنده شده بود، آن پیام‌رسان ابزار تأیید واقعی به شما نمی‌دهد.
اگر شماره امنیتی جور نشد چه کنم؟
فوراً محتوای حساس نفرستید و فرض کنید گفت‌وگو در معرض شنود است. از یک کانال کاملاً جدا — رو در رو، تماس صوتی یا پیام‌رسان دیگر — از طرف مقابل بپرسید دستگاهش را عوض کرده یا برنامه را دوباره نصب کرده است. اگر پاسخ منفی بود، آن گفت‌وگو را تا برقراری دوبارهٔ کلیدها از مسیر سالم رها کنید.
آیا تأیید با QR امن‌تر از خواندن اعداد است؟
نه. QR میان‌بری برای وارد نکردن رقم‌ها است، نه یک لایهٔ امنیتی اضافه؛ هر دو از یک داده ساخته می‌شوند و یک چیز را تأیید می‌کنند.
هشدار تغییر کلید یعنی حسابم هک شده؟
نه لزوماً. نصب مجدد برنامه، دستگاه جدید یا بازیابی حساب روی سخت‌افزار تازه هم کلید را عوض می‌کند. اما از بیرون این حالت با حمله قابل تفکیک نیست، پس تا وقتی از کانالی مستقل مطمئن نشده‌اید که علت بی‌خطر بوده، با آن مثل یک رخداد امنیتی برخورد کنید.
کانال‌های عمومی هم رمزنگاری سرتاسری دارند؟
نه. کانال یک رسانهٔ پخش عمومی است، نه گفت‌وگوی خصوصی؛ محتوا عمداً رمزنگاری سرتاسری نمی‌شود تا رسیدگی به گزارش‌ها و حذف کانال‌های متخلف ممکن باشد. چت‌های دونفره و گروه‌های خصوصی اما سرتاسری رمزنگاری می‌شوند.
منابع
- AboutSignal — Signal introduces Automatic Key Verification
- protect.computer — Signal Adds Key Transparency Feature to Block Interception Attacks
- Shield53 — Signal's Automatic Key Verification: A Major Step Forward Against MITM Threats — But Not a Silver Bullet
- FIPS 203 سازمان NIST (ML-KEM)، RFC 5869 (HKDF) و RFC 5054 (SRP) — مشخصات فنی نام‌برده‌شده در متن.
