توضیح‌نامه‌ی ۰۴

زنجیره‌ی اعتماد گذرنامه (و جایی که می‌تواند شکسته شود)

این مهم‌ترین متن این پوشه است. هر چیز دیگری در سکو روی یک فرض می‌نشیند: این‌که سندی که کاربر اسکن می‌کند واقعی است، و «واقعی» چیزی است که می‌توانیم بدون اعتماد به کاربر، تلفن، یا هر شرکت منفردی راستی‌آزمایی کنیم.

این متن توضیح می‌دهد چگونه به آن فرض می‌رسیم — و کجا دیگر صادق نیست.

یک گذرنامه‌ی الکترونیکی / INID به‌لحاظ فیزیکی چیست

اسناد سفر بیومتریک مدرن و کارت ملی هوشمند ایران شامل یک کامپیوتر کوچک (یک ICC، تراشه‌ی مدار مجتمع) هستند که از راه NFC قابل دسترسی است. تراشه ذخیره می‌کند:

خواندن تراشه نیازمند MRZ (ناحیه‌ی قابل‌خواندن ماشینی، چاپ‌شده روی صفحه‌ی ۲ گذرنامه / جلوی INID) است تا کلیدهای جلسه (از راه BAC یا PACE) مشتق شوند. به همین دلیل برنامه‌ی ما ابتدا از کاربر می‌خواهد صفحه را با دوربین اسکن کند پیش از تماس با تراشه.

زنجیره‌ی گواهی — از بالا به پایین

ICAO PKD (دایرکتوری کلید عمومی)

  • از سوی سازمان بین‌المللی هواپیمایی کشوری ICAO، یک نهاد تخصصی سازمان ملل، نگهداری می‌شود.
  • شامل کلیدهای عمومی CSCA هر کشور است.
  • ما اسنپ‌شات آن را در یک درخت Merkle ذخیره می‌کنیم. (~۸۵۷ گواهی)
هش ریشه روی زنجیره ثبت می‌شود

CSCA — مرجع گواهی امضای کشور

  • یک یا چند به ازای هر کشور (ایران ~۳، آلمان ۱۷)
  • بلندمدت (~۱۰ سال)، در HSM صادرکننده نگه‌داشته می‌شود.
  • گواهی‌های DS را امضا می‌کند.
امضا می‌کند

DS — گواهی Document Signer

  • هر چند ماه چرخانده می‌شود.
  • یک گواهی DS هزاران گذرنامه را امضا می‌کند.
  • هش در CertificatesSMT ما یک بار ثبت می‌شود.
SOD را امضا می‌کند

SOD Security Object درون تراشه

  • شامل هش‌های DG است و از سوی DS امضا شده.
  • همان چیزی است که مدار ZK نهایتن راستی‌آزمایی می‌کند.

برای ایران به‌طور مشخص، صادرکننده سازمان ثبت احوال کشور است؛ CSCAها از سوی دولت اداره می‌شوند، گواهی‌های DS چرخانده می‌شوند، و هم گذرنامه‌ها و هم INIDها در همان طرح PKI ICAO شرکت می‌کنند.

برای INIDها به‌طور مشخص، تراشه از سوی شرکت ماتیران ساخته و نرم‌افزاری مدیریت می‌شود. تراشه دو گواهی (امضا + احراز هویت) را نشان می‌دهد، از PACE-CAM به‌جای BAC بهره می‌برد، و از راه چالش-پاسخ با یک کلید خصوصی که در عنصر امن تراشه نگه‌داشته می‌شود ثابت می‌کند که کلون نیست. فایل DG15 وجود ندارد، اما خاصیت ضد-کلون از راه مکانیزم گواهی احراز هویت حفظ می‌شود. (منبع: کار مهندسی معکوس ما در INIDOSDK.)

مدار ZK واقعن چه چیزی را بررسی می‌کند

درون مدار (≈ ۵ میلیون قید)، تلفن کاربر ثابت می‌کند که همه‌ی موارد زیر همزمان برقرار هستند:

  1. امضای SOD معتبر است تحت کلید عمومی گواهی DS.
  2. امضای گواهی DS معتبر است تحت کلید عمومی یک CSCA.
  3. آن CSCA در درخت Merkle ICAO ما حضور دارد در ریشه‌ی 0x8aebf998... (یا هر چه قرارداد پذیرفته است).
  4. هش‌های داده‌ی MRZ (DG1) با ورودی SOD مطابقت دارند برای DG1.
  5. تاریخ تولد در DG1 کاربر را به اندازه‌ی کافی مسن می‌کند.
  6. تاریخ انقضا در DG1 در آینده است.
  7. nullifier درست مشتق شده است از راز کاربر + شناسه‌ی رویداد.

فقط خروجی‌ها (۴ دسته، بدون داده‌ی خام) اثبات را ترک می‌کنند: nullifier، ریشه‌ی ICAO، کد تابعیت، تاریخ‌ها.

کاربر نمی‌تواند چه چیزی را جعل کند

این ستون گزاره‌های قوی است. هیچ‌یک از این حملات علیه سیستم ما کار نمی‌کند:

حمله‌ای که کاربر امتحان می‌کندچرا شکست می‌خورد
ویرایش DG1 / DG2 / DG13 در دامپ تراشه پیش از اسکنعدم‌تطابق هش SOD — بررسی هش مدار رد می‌کند.
جایگزینی SOD خود با هش‌های DG دست‌سازامضای SOD تحت کلید عمومی DS شکست می‌خورد.
جعل یک گواهی DSاز سوی هیچ CSCAای امضا نشده ← گام ۲ مدار شکست می‌خورد.
فرستادن یک سند واقعی اما دروغ درباره‌ی تاریخ تولدورودی‌های DG1 به مدار به هش‌های SOD مقید‌اند — تاریخ، واقعی است.
استفاده‌ی مجدد از اثبات یک نفر دیگربه کیف پول/راز کاربر متصل است که در اختیار ندارد؛ عدم‌تطابق nullifier در همان تلاش اول.
رای دادن دو بار روی همان پیشنهادهمان nullifier؛ قرارداد رای دوم را رد می‌کند.
بازپخش یک رای در پیشنهادهای مختلفشناسه‌ی رویداد متفاوت ← nullifier متفاوت؛ اما کاربر فقط ناشناس «همان شخص» است، عمدی.
اجرای یک برنامه‌ی اصلاح‌شده که بررسی‌ها را رد می‌کندبررسی‌ها در مدار زندگی می‌کنند، نه در کد برنامه. یک برنامه‌ی اصلاح‌شده اثبات‌های نامعتبر تولید می‌کند.
وصله‌زدن بایت‌های اثبات در حال انتقالمعادله‌ی pairing می‌شکند — راستی‌آزما رد می‌کند.
پرداخت به کسی برای ثبت‌نام از طرف خودبه‌لحاظ اجتماعی ممکن است، اما تفاوتی با فروش گذرنامه‌ی واقعی شما ندارد — با نرم‌افزار قابل حل نیست.

تضمین رمزنگاری قوی است: هر چیزی که نهایتن روی زنجیره می‌نشیند، چیزی است که صادرکننده آن را امضا کرده است. هیچ چیز که کاربر بتواند اختراع کند.

مهاجم می‌تواند چه کند — بخش صادقانه

این ستونی است که باید درباره‌ی آن صادق باشیم. سه حمله‌ی واقعی باقی می‌ماند و دو تای آن‌ها در هر سیستم passport-ZK جهان مشترک هستند.

حمله‌ی ۱: دولت با کلید خصوصی CSCA هویت‌های جعلی ضرب می‌کند

دولت ایران (یا هر کس با دسترسی به HSM CSCA) می‌تواند:

  1. یک گواهی DS تازه امضا کند.
  2. از آن DS برای امضای یک SOD جعلی با محتوای DG1 دلخواه (نام ساختگی، تاریخ تولد ساختگی، تابعیت ساختگی) استفاده کند.
  3. آن سند جعلی را به یک بازیگر مزدور بدهد که تلفنش یک اثبات ZK کاملن معتبر تولید می‌کند.

اثبات از مدار و قرارداد ما عبور خواهد کرد، چون ریاضی درست است: سند واقعن از سوی یک CSCA واقعی امضا شده. خود درخت ICAO «انسان واقعی» را از «امضای معتبر روی یک رکورد ساختگی» تشخیص نمی‌دهد.

این محدودیتی است که هر سیستم passport-ZK به اشتراک می‌گذارد. ZKPassport، Rarimo / FreedomTool، جریان گذرنامه‌ی World ID، و ما — همه‌ی ما این را به ارث می‌بریم. دولت ریشه‌ی اعتماد است، و اگر در ریشه تقلب کند، هیچ رمزنگاری پایین‌دستی نمی‌تواند تشخیص دهد.

آنچه می‌توانیم درباره‌اش بکنیم، از ارزان به گران:

کاهشوضعیتچه می‌کند
اسنپ‌شات قفل‌شده‌ی ICAOبرنامه برای M6یک ریشه‌ی CSCA-tree از تاریخی پیش از مشکوک‌شدن به رفتار خصمانه را پین می‌کنیم. CSCAهای جدیدی که رژیم پس از آن تاریخ اضافه می‌کند، در درخت ما نیستند.
بررسی متقابل چند-صادرکنندهآیندهبرای آرای پر-تنش، دو صادرکننده‌ی متمایز را الزام کنیم (مثلن گذرنامه + INID، یا ایرانی + کشور دیگر برای دیاسپورا). هر دو صادرکننده باید تبانی کنند.
تشخیص ناهنجاری آماریآیندهحجم صدور گواهی DS را ردیابی کنیم. جهش‌های ناگهانی یک سیگنال‌اند. تحلیل خارج از زنجیره، شفافیت روی زنجیره.
لاگ شفافیت عمومیبرنامههر گواهی DS ثبت‌شده روی زنجیره است. یک ضرب انبوه هماهنگ‌شده قابل مشاهده می‌شود.
تطبیق چهره روی دستگاه + liveness (ZKML سبک Bionetta)M7 (برنامه‌ریزی‌شده)اثبات‌کننده را مجبور می‌کنیم ثبت‌نام را به یک بیومتریک زنده گره بزند. اسناد جعلی نیاز به چهره‌های واقعی خواهند داشت که برای یک مهاجم به‌خوبی مقیاس‌پذیر نیست.

این محدودیت را بی‌پرده نام می‌بریم چون اعتبار آن را الزام می‌کند. هیچ‌کس دیگر در این فضا حاضر نیست این را این‌قدر صریح بیان کند؛ ما خواهیم بود.

حمله‌ی ۲: جناح هماهنگ از کاربران قانونی

یک گروه هم‌سو با حکومت (یا به نحوی سازمان‌یافته) از شهروندان واقعی ایرانی با گذرنامه‌های واقعی / INIDها صادقانه ثبت‌نام می‌کند و سپس سکو را پر می‌کند از محتوایی که:

این یک مشکل رمزنگارانه نیست. اثبات‌های هویت به‌تنهایی این را متوقف نمی‌کنند، چون همه‌ی شرکت‌کنندگان هویت قانونی دارند. این دقیقن همان حمله‌ای است که لایه‌ی انطباق هنجاری برای مقاومت در برابر آن طراحی شده — دو دروازه: هویت و گفتار را ببینید. ما از یک LLM بهره می‌بریم که محتوا را در برابر ۱۱ کنوانسیون حقوق بشر سازمان ملل پیش از انتشار ارزیابی می‌کند. این یک فیلتر سمیّت نیست؛ یک دفاع ساختاری در برابر تسخیر است.

حمله‌ی ۳: دستگاه کاربر در معرض خطر

اگر مهاجم روی تلفن کاربر root دارد — از راه بدافزار، یک سیستم‌عامل سفارشی فلش‌شده، یا دسترسی فیزیکی — می‌تواند:

این همان مدل تهدید برنامه‌های بانکی، واتس‌اپ، یا هر اعتبار وابسته به دستگاه دیگر است. کاهش‌ها در سطح سکو هستند:

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

چه چیزهایی را سکو محافظت نمی‌کند — فهرست صریح

این همان محتوای جدول بالاست، که به‌عنوان ادعاهای ساده بازنویسی شده تا کلمه‌به‌کلمه در مواد عمومی ما حاضر شود:

  1. یک بازیگر دولتی با کلید امضای CSCA می‌تواند هویت‌های جعلی ضرب کند که سیستم ما نمی‌تواند از واقعی تشخیص دهد. این حمله را کاهش می‌دهیم؛ حذف نمی‌کنیم.
  2. افراد واقعی که با اسناد واقعی بر اساس دستورالعمل‌های هماهنگ رای می‌دهند چیزی است که سیستم‌های هویت نمی‌توانند حل کنند. لایه‌ی انطباق هنجاری محتوا را نشانی می‌گیرد؛ خود انتخاب رای — و باید — آزاد است.
  3. یک دستگاه کاربر که root شده یا آلوده به بدافزار است خارج از حوزه‌ی رمزنگاری است. به attestation اپل / گوگل تکیه می‌کنیم، نه به رمزنگاری خودمان.
  4. یک مهاجم با دسترسی فیزیکی به تلفن قفل‌نشده‌ی کاربر می‌تواند در آن جلسه به‌عنوان آن کاربر عمل کند.

چگونه زنجیره‌ی اعتماد با M6 کنار هم می‌آید

امروز، درخت ICAO، CertificatesSMT، RegistrationSMT، و dispatcherها که نوع گواهی را decode می‌کنند، همگی از سوی Rarimo مستقر شده‌اند. ما از قراردادهای آن‌ها بهره می‌بریم. این فعلن خوب است، اما به این معناست که کس دیگری ریشه‌های اعتماد ما را مدیریت می‌کند.

پس از آن‌که مرحله‌ی M6 پایان می‌یابد، Registration2 خود، StateKeeper خود، SMTهای خود، و dispatcherهای خود را مستقر می‌کنیم — همچنان روی Rarimo L2 — با اسنپ‌شات ICAO خودمان. این به ما این‌ها را می‌دهد:

زنجیره (Rarimo L2) را حفظ می‌کنیم. قراردادها را جایگزین می‌کنیم.

واژه‌نامه

اصطلاحمعنا
MRZناحیه‌ی قابل‌خواندن ماشینی — متن مناسب OCR روی گذرنامه / کارت. برای مشتق‌کردن کلیدهای جلسه‌ی NFC به‌کاربرده می‌شود.
BAC / PACEدو پروتکل برای برقراری جلسه‌ی رمزنگاری‌شده با تراشه. PACE جدیدتر است؛ PACE-CAM نسخه‌ی INID است.
SODSecurity Object Document — فهرست هش‌های امضاشده‌ی همه‌ی گروه‌های داده در تراشه.
DG1، DG2، DG13، DG15فایل‌های داده‌ی مشخص درون تراشه. DG1 = داده‌ی MRZ، DG2 = تصویر چهره، DG13 = اطلاعات شخصی INID، DG15 = کلید عمومی احراز فعال.
CSCACountry Signing Certificate Authority — راس PKI گذرنامه‌ی الکترونیکی یک کشور.
DSDocument Signer — گواهی کوتاه‌عمر که SOD هر گذرنامه‌ی منفرد را امضا می‌کند.
ICAO PKDدایرکتوری کلید عمومی که از سوی نهاد ICAO سازمان ملل نگهداری می‌شود — فهرست جهانی CSCAها.
CertificatesSMTSparse Merkle Tree روی زنجیره از هش‌های گواهی DS ثبت‌شده.
RegistrationSMTSparse Merkle Tree روی زنجیره از تعهدات هویت.
Nullifierمقدار ضد-بازپخش، به ازای هر رویداد. اثبات‌های دانش‌صفر را ببینید.