في برامج المراسلة ذات التشفير من طرف إلى طرف (E2E) ، يكون المستخدم مسؤولاً عن مفاتيحه. عندما يخسرهم ، يضطر لإعادة ضبط حسابه.

إعادة تعيين حساب أمر خطير. يمكنك محو المفاتيح العامة وتصبح غريباً في جميع المحادثات. تحتاج إلى استعادة هويتك ، ويعني هذا في جميع الحالات تقريبًا اجتماعًا شخصيًا ومقارنة "أرقام الأمان" بكل جهة اتصال. كم عدد المرات التي تمر بها بالفعل مثل هذا الاختبار ، والذي يعد الحماية الوحيدة من MiTM؟

حتى إذا كنت جادًا بشأن أرقام الأمان ، فسترى فقط العديد من شركاء الدردشة مرة واحدة سنويًا في أحد المؤتمرات ، لذلك فأنت عالق.

ولكن هذا يحدث بشكل غير منتظم ، أليس كذلك؟

كم مرة يحدث إعادة التعيين؟ الإجابة: في معظم تطبيقات الدردشة E2E طوال الوقت.

في هؤلاء المرسلين ، تقوم بإسقاط التشفير وببساطة تثق في الخادم: (1) في كل مرة تقوم فيها بالتبديل إلى هاتف جديد ؛ (2) كلما انتقل المحاور إلى هاتف جديد ؛ (3) عند إعادة تعيين إلى إعدادات المصنع من الهاتف ؛ (4) عندما يقوم أي محاور بإجراء إعادة ضبط على إعدادات المصنع ؛ (5) كلما قمت بإلغاء تثبيت التطبيق وإعادة تثبيته ، أو (6) عندما يقوم أي شخص تتحدث معه بإلغاء التثبيت وإعادة تثبيته. إذا كان لديك عشرات جهات الاتصال ، فستتم إعادة الضبط كل بضعة أيام.

تحدث إعادة التعيين بشكل منتظم بحيث تدعي هذه التطبيقات أن هذه ليست مشكلة:


يبدو أن لدينا ترقية أمنية! (ولكن ليس حقا)

هل حقا توفو؟

في التشفير ، يصف مصطلح TOFU ("الثقة عند الاستخدام الأول") لعبة فرصة عندما يتحدث طرفان للمرة الأولى. بدلاً من الاجتماع شخصيًا ، يكون الوسيط مسؤولاً عن كل جانب ... وبعد ذلك ، بعد تقديم الأطراف نفسها ، يراقب كل جانب المفاتيح بعناية للتأكد من عدم تغير أي شيء. إذا كان المفتاح قد تغير ، فإن كل جانب ينذر.

إذا كان مفتاح المضيف البعيد يتغير في SSH في هذه الحالة ، فلن "يعمل فقط" ، بل سيصبح محاربًا تمامًا:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
Please contact your system administrator.
Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/rmueller/.ssh/known_hosts:12
RSA host key for 8.8.8.8 has changed and you have requested strict checking.
Host key verification failed.

هنا هو السلوك الصحيح. وتذكر: هذا ليس توفو إذا سمح لك بالمزيد من العمل مع تحذير صغير. يجب أن تشاهد جمجمة عملاقة مع عظمتان متقاطعتان .

بالطبع ، سوف يدعي هؤلاء المرسلون الفوريون أن كل شيء على ما يرام ، لأنه يتم تحذير المستخدم. إذا أراد ، يمكنه التحقق من أرقام الأمان. لهذا السبب نحن لا نوافق على:

1. لم يتم إجراء التحقق لأنه يحدث كثيرًا.
   
2. تحقق تمتص.
   
3. حتى إجراء مسح سريع لأصدقائنا المهتمين بالأمن أظهر أنه لا يوجد أحد قلق بشأن هذا الاختبار.
   
4. لذلك فقط تثق في الخادم وتثق في الرسائل النصية القصيرة (حسناً ، جيدًا!) مرارًا وتكرارًا .
   
5. أخيرًا ، يجب ألا تعمل هذه التطبيقات بهذه الطريقة. خاصة عند تغيير الأجهزة. يمكن التعامل مع الحالة الطبيعية المعتادة بسلاسة وأمان ، وكلما كان الوضع نادرًا ، كلما بدا الأمر أسوأ. في دقيقة ، أظهر حل Keybase.

توقف عن تسميتها TOFU

هناك هجوم فعال جدا. لنفترض أن حواء تريد اقتحام محادثة أليس وبوب الحالية والوقوف بينهما. كان أليس وبوب على اتصال لسنوات عديدة ، بعد مرور فترة طويلة على اختبار TOFU.

حواء تجعل أليس تعتقد أن بوب اشترى هاتفًا جديدًا:

بوب (حواء): مهلا ، يا!

أليس: يو ، بوب! يبدو أن لديك أرقام أمان جديدة.

بوب (حواء): نعم ، اشتريت iPhone XS ، هاتف جيد ، مسرور جدًا به. دعنا نتبادل أرقام الأمان على RWC 2020. مهلا ، هل لديك عنوان كارولين الحالي؟ أريد أن أفاجئها أثناء وجودي في سان فرانسيسكو.

أليس: لا يمكنني مقارنة حياة أندرويد 4! نعم ، كوزي ستريت 555.

لذلك ، من غير المرجح أن يكسب معظم الرسل المشفر امتثال TOFU. هذا يشبه TADA - الثقة بعد إضافة الأجهزة. هذه مشكلة حقيقية وليست وهمية ، لأنها تخلق فرصة للتنفيذ الضار في محادثة سابقة. في TOFU الحقيقي ، بحلول الوقت الذي يهتم فيه شخص ما بمحادثتك ، لن يكون بإمكانه التسلل إليها. مع TADA ، هذا ممكن.

في الدردشات الجماعية ، فإن الوضع أسوأ. كلما زاد عدد الأشخاص الموجودين في الدردشة ، سيتم إعادة تثبيت الحساب في كثير من الأحيان. في شركة تضم 20 شخصًا فقط ، سيحدث هذا كل أسبوعين تقريبًا ، وفقًا لتقديراتنا. ويجب على كل شخص في الشركة مقابلة هذا الشخص. شخصيا. خلاف ذلك ، يتم اختراق الدردشة بأكملها عن طريق الخلد أو القراصنة.

قرار

هل هناك حل جيد لا يعني الثقة في خوادم المفاتيح الخاصة؟ نعتقد أن هناك: دعم حقيقي لأجهزة متعددة. هذا يعني أنك تدير سلسلة من الأجهزة التي تمثل هويتك. عندما تتلقى جهازًا جديدًا (هاتف ، كمبيوتر محمول ، كمبيوتر سطح المكتب ، iPad ، وما إلى ذلك) ، فإنه ينشئ زوج مفاتيح خاص به ، ويقوم الجهاز السابق بتوقيعه. إذا فقدت الجهاز ، فاحذفه من أحد الأجهزة الباقية. من الناحية الفنية ، يعد هذا الحذف بمثابة استدعاء ، وفي هذه الحالة يوجد أيضًا نوع من انعكاس المفتاح يحدث تلقائيًا.

نتيجةً لذلك ، لست بحاجة إلى الوثوق بالخادم أو الاجتماع شخصيًا عندما يستقبل المحاور أو الزميل جهازًا جديدًا . وبالمثل ، لا تحتاج إلى الوثوق بالخادم أو الاجتماع شخصيًا عندما يزيل الجهاز ، إذا لم يكن الأخير. المرة الوحيدة التي تحتاج فيها إلى رؤية تحذير هي عندما يفقد شخص حق الوصول إلى جميع إعداداته. وفي هذه الحالة ، سترى تحذيرًا خطيرًا ، كما ينبغي:


القبيح خصيصا للغاية

نتيجة لذلك ، تتم إعادة تعيين حسابات أقل وإعادة تثبيتها. من الناحية التاريخية ، في Keybase ، يبلغ إجمالي عدد الوظائف الإضافية والمراجعات للجهاز عشرة أضعاف عدد عمليات صرف الحساب (لا تحتاج إلى أخذ كلمتنا لذلك ، فهذا متاح للجميع في شجرة Merkle). على عكس الرسل الآخرين ، يمكننا إظهار تحذير مرعب حقًا عندما تتحدث إلى شخص قام بإعادة تثبيت المفاتيح مؤخرًا.

إدارة الأجهزة هي عملية هندسية معقدة قمنا بتحسينها عدة مرات. يقوم الجهاز الموجود بالتوقيع على المفاتيح العامة للجهاز الجديد ويقوم بتشفير جميع البيانات السرية المهمة للمفتاح العام للجهاز الجديد. يجب إجراء هذه العملية بسرعة (خلال ثانية واحدة) ، نظرًا لأننا نتحدث عن مدى انتباه المستخدم. نتيجة لذلك ، يستخدم Keybase تسلسل هرمي للمفاتيح ، بحيث عند نقل 32 بايت من البيانات السرية من جهاز قديم ، يمكن للجهاز الجديد رؤية جميع بيانات التشفير طويلة العمر (انظر الأسئلة الشائعة أدناه لمزيد من التفاصيل). قد يبدو هذا مفاجئًا بعض الشيء ، ولكن هذه هي بالضبط نقطة التشفير . لا يحل مشاكل إدارة الأسرار الخاصة بك ؛ بل يجعل النظام أكثر قابلية للتطوير.

الصورة الكاملة للأمن

الآن يمكننا صياغة أربع خصائص أمان أساسية لتطبيق Keybase:

1. مفاتيح سرية طويلة الأمد لا تترك الأجهزة التي تم إنشاؤها عليها أبدًا
   
2. الدعم الكامل متعدد الأجهزة يقلل من انخفاض الحساب
   
3. لا يمكن تأجيل إلغاء المفتاح أو إعادته بشكل ضار
   
4. السرية المباشرة باستخدام رسائل الوقت سريعة الزوال

الأولين يبدو مفهوما. يصبح الثلث مهمًا في التصميم حيث يتوقع استدعاء الجهاز ويعتبر طبيعيًا. يجب أن يتحقق النظام من أن الخوادم الضارة لا يمكنها تأخير مراجعات الجهاز ، والتي كتبنا عنها سابقًا .

راجع مقالتنا حول المراسلة المؤقتة لمزيد من المعلومات حول ميزة الأمان الرابعة.

الكثير من التشفير الجديد ، هل تم تنفيذ كل شيء بشكل صحيح؟

لم تنفذ Keybase وظائف الأمان الأساسية من قبل ولم تصفها أبدًا في المقالات العلمية. كان علينا أن نخترع بعض بروتوكولات التشفير بأنفسنا. لحسن الحظ ، هناك الكثير من خوارزميات التشفير القياسية والمستخدمة على نطاق واسع لأي موقف. كل كود عميلنا مفتوح . من الناحية النظرية ، يمكن لأي شخص أن يجد أخطاء في التصميم أو التنفيذ. لكننا أردنا إظهار الهيكل الداخلي وتوظيف أفضل شركة تدقيق أمان لإجراء تحليل كامل.

اليوم نقدم تقرير مجموعة NCC وتشجع النتائج للغاية. أنفق Keybase أكثر من 100000 دولار على التدقيق ، وعين NCC Group خبراء أمن وتشفير عالي المستوى. وجدوا خطأين مهمين في تطبيقنا ، وقمنا بإصلاحه بسرعة. يمكن أن تظهر هذه الأخطاء فقط إذا تصرفت خوادمنا بشكل ضار. يمكننا أن نؤكد أنهم لن يتصرفوا على هذا النحو ، لكن ليس لديك أي سبب لتصديقنا. هذا هو الشيء!

نعتقد أن فريق NCC قام بعمل ممتاز. احترم الوقت الذي قضوا فيه لفهم هيكلنا وتطبيقنا تمامًا. لقد عثروا على أخطاء دقيقة استحوذت على اهتمام مطورينا ، على الرغم من أننا شاهدنا هذا الجزء مؤخرًا من قاعدة الكود مرارًا وتكرارًا. نوصيك بالاطلاع على التقرير هنا ، أو الانتقال إلى الأسئلة الشائعة.

التعليمات

كيف تجرؤ على مهاجمة منتج XYZ؟

لقد أزلنا بالفعل إشارات إلى منتجات محددة من المقال.

ماذا بعد؟

نحن فخورون بأن Keybase لا يحتاج إلى أرقام هواتف ويمكنه التحقق من معرفات Twitter و HackerNews و Reddit و Github بشكل مشفر إذا كنت تعرف أي شخص.

و ... قريبًا ... سيكون هناك دعم لـ Mastodon.

ماذا عن هجمات إعادة توجيه الهاتف؟

العديد من التطبيقات عرضة لإعادة توجيه الهجمات. تدخل حواء في كشك في مركز للتسوق وتقنع بوب ، مشغل الهاتف المحمول ، بإعادة توجيه رقم هاتف بوب إلى جهازها. أو أنها تقنع الممثل عن طريق الهاتف. الآن ، تستطيع حواء المصادقة على خوادم messenger ، مدعيا أنها بوب. تبدو النتيجة أن مثالنا على Alice و Bob و Eve أعلى ، لكن Eve لا يحتاج إلى اختراق أي خوادم. تقدم بعض التطبيقات "حظر التسجيل" للحماية من هذا الهجوم ، لكنها بشكل افتراضي مزعجة.

سمعت Keybase يرسل بعض المفاتيح الخاصة إلى الخادم؟

في الأيام الأولى (2014 وأوائل 2015) ، عمل Keybase كتطبيق PGP على الويب ، ويمكن للمستخدم اختيار الوظيفة لتخزين مفاتيح PGP الخاصة به على خوادمنا ، مشفرة بعبارات المرور (التي لم يعرفها Keybase).

في سبتمبر 2015 ، قدمنا ​​نموذج Keybase الجديد. لا تستخدم مفاتيح PGP أبدًا (ولا تستخدم أبدًا) في نظام الدردشة أو نظام الملفات Keybase.

كيف تظهر الدردشات القديمة على الفور على الهواتف الجديدة؟

في بعض التطبيقات الأخرى ، لا ترى الأجهزة الجديدة رسائل قديمة ، لأن مزامنة الرسائل القديمة عبر الخادم تتعارض مع السرية المباشرة. يسمح لك تطبيق Keybase بتعيين رسائل معينة - أو محادثات بأكملها - على أنها "سريعة الزوال". يتم تدميرها بعد وقت معين ويتم تشفيرها مرتين: مرة واحدة باستخدام مفاتيح تشفير الدردشة طويلة العمر ، والآخر باستخدام مفاتيح سريعة الزوال تتغير بشكل متكرر. وبالتالي ، توفر الرسائل المؤقتة سرية مباشرة ولا يمكن مزامنتها بين الهواتف.

تبقى الرسائل غير المؤقتة حتى يقوم المستخدم بحذفها بشكل صريح ومزامنة E2E مع أجهزة Slack الجديدة ، فقط مع التشفير! لذلك ، عند إضافة شخص ما إلى فريق أو إضافة جهاز جديد لنفسك ، يتم إلغاء حظر الرسائل.

المزيد عن التزامن في الفقرة التالية.

أخبرنا عن PUKs!

قبل عامين ، قدمنا مفاتيح للمستخدمين (PUK) . يتم الإعلان عن النصف العام من PUK في sigchain العامة للمستخدمين. يتم تشفير النصف السري للمفتاح العمومي لكل جهاز. عندما تستعد Alice جهازًا جديدًا ، يعرف جهازها القديم النصف السري من PUK والمفتاح العام للجهاز الجديد. يقوم بتشفير النصف السري من PUK للمفتاح العام للجهاز الجديد ، ويقوم الجهاز الجديد بتنزيل هذا النص المشفر من خلال الخادم. يقوم الجهاز الجديد بفك تشفير PUK ويمكنه الوصول على الفور إلى جميع رسائل الدردشة الطويلة.

عندما تتذكر Alice جهازًا ، تقوم بتغيير PUK الخاص بها ، بحيث تتلقى جميع أجهزتها ، باستثناء ما تم استدعاءها مؤخرًا ، PUK جديد.

يختلف نظام المزامنة هذا بشكل أساسي عن نظام Keybase PGP المبكر. هنا ، تحتوي جميع المفاتيح المعنية على 32 بايتًا من الإنتروبيا الحقيقية ؛ فهي لا تنفصل عن القوة الغاشمة في حالة اختراق الخادم. صحيح ، إذا تم كسر Curve25519 أو PRNG من Go ، فكل شيء ينكسر. لكن تزامن PUK لا يقدم أي افتراضات تشفير مهمة أخرى.

ماذا عن دردشات المجموعة الكبيرة؟

تحتوي tL؛ dr Groups على سلاسل توقيع مدققة خاصة بها لتغيير الأدوار ، إضافة وإزالة أعضاء.

كتب باحثو الأمن عن هجمات المستخدمين الوهمية على دردشات المجموعة. إذا لم يتمكن عملاء المستخدمون من التحقق من عضوية المجموعة بشكل مشفر ، فيمكن للخوادم الضارة تضمين برامج التجسس والشامات في دردشات المجموعة. Keybase لديها نظام موثوق للغاية في شكل وظيفة خاصة للمجموعات ، والتي سوف نكتب عنها في المستقبل.

يمكنك التحدث عن NCC-KB2018-001؟

نعتقد أن هذا الخطأ هو أهم اكتشاف لتدقيق NCC. Keybase يستخدم بنشاط هياكل البيانات غير الثابتة للحماية من غموض الخادم من إلحاق فقط. في حالة وجود خطأ ، قد يبدأ خادم نزيه في التهرب: "لقد أخبرتك سابقًا ، ولكن حدث خطأ ، قصدت B". لكن لدى عملائنا سياسة مشتركة بعدم السماح للخادم بهذه المرونة: لديهم استثناءات مشفرة في حالة الأخطاء.

في الآونة الأخيرة ، قدمنا ​​أيضًا Sigchain V2 : هذا النظام يحل مشكلات قابلية التوسع التي لم نتنبأ بها بشكل صحيح في الإصدار الأول. أصبح العملاء الآن أكثر اقتصادا من خلال بيانات التشفير التي يسحبونها من الخادم ، حيث يتلقون توقيعًا واحدًا فقط من ذيل سلسلة التوقيع ، بدلاً من توقيع كل رابط وسيط. وبالتالي ، فقد العملاء الفرصة للذهاب في دورات للبحث عن تجزئة توقيع معين ، لكننا استخدمنا سابقًا هذه التجزئة للبحث عن روابط سلاسل سيئة في قائمة الاستثناءات المشفرة الثابت. كنا نستعد لإصدار Sigchain V2 ، متناسين هذه التفاصيل المدفونة تحت عدة طبقات من التجريدات ، لذلك النظام ببساطة يثق في المجال من استجابة الخادم.

بمجرد اكتشاف NCC لهذا الخطأ ، كان الإصلاح بسيطًا إلى حد ما: البحث عن استثناءات مشفرة بشكل ثابت مع تجزئة سلسلة الارتباط بدلاً من تجزئة توقيع سلسلة الارتباط. يمكن للعميل دائما حساب مباشرة هذه التجزئة.

يمكننا أيضًا أن نعزو هذا الخطأ إلى التعقيد الإضافي المطلوب لدعم Sigchain V1 و Sigchain V2 في وقت واحد. يكتب العملاء العصريون روابط Sigchain V2 ، لكن يجب أن يدعم جميع العملاء روابط v1 القديمة لفترة غير محدودة. تذكر أن العملاء يوقعون روابط مع مفاتيحهم الخاصة لكل جهاز. لا يمكننا تنسيق جميع العملاء بالكتابة فوق البيانات التاريخية في فترة زمنية معقولة ، حيث يمكن أن يكون هؤلاء العملاء غير متصلين بالإنترنت.

يمكنك التحدث عن NCC-KB2018-004؟

كما في 001 (انظر أعلاه) ، خذلنا مزيج من الدعم المتزامن للحلول القديمة والتحسين ، والتي بدت مهمة مع اكتسابنا خبرة أكبر في العمل مع النظام.

في Sigchain V2 ، نقوم بتقليل حجم السلاسل بالبايت من أجل تقليل النطاق الترددي اللازم للبحث عن المستخدمين. هذا التوفير مهم بشكل خاص على الهواتف المحمولة. وبالتالي ، نقوم بتشفير روابط السلسلة باستخدام MessagePack ، وليس JSON ، مما يوفر مدخرات جيدة. بدوره ، يقوم العملاء بالتوقيع والتحقق من التوقيعات على هذه السلاسل. لقد وجد الباحثون في NCC طرقًا صعبة لإنشاء "تواقيع" تشبه JSON و MessagePack في نفس الوقت ، مما يؤدي إلى حدوث تعارض. لقد أدخلنا غموضًا هذا الغموض في فك التشفير أثناء التحسين عندما قمنا بتحويل موزعي JSON من محلل Go القياسي إلى محلل Go الأكثر فعالية. تخطى هذا المحلل السريع بهدوء مجموعة من القمامة قبل العثور على JSON الفعلي ، والتي تضمنت ميزة الهجوم متعددة اللغات. تم إصلاح الخطأ عن طريق التحقق من إدخال إضافي .

في Sigchain V2 ، قبلنا أيضًا اقتراح آدم لانغلي بأن يوقع الموقرون حزمهم بالتوقيعات ببادئة سطر السياق والبايتة \0 حتى لا يتم الخلط بين المحققين ونوايا الموقع. على جانب التحقق من فكرة بادئة السياق هذه ، كانت هناك أخطاء قد تؤدي إلى هجمات متعددة اللغات الأخرى. لقد أصلحنا هذا الخلل بسرعة باستخدام قائمة بيضاء .

بعد إصلاح الخللتين ، يرفض الخادم الأحمال الخبيثة لهجوم متعدد اللغات ، لذلك لا يمكن استغلال هذه الثغرات الأمنية إلا بمساعدة خادم خطر.

أين هي الوثائق؟

https://keybase.io/docs

في الأشهر المقبلة ، سنخصص مزيدًا من الوقت للعمل على الوثائق.

يمكنك معرفة المزيد حول هذا البيان من قبل NCC: "ومع ذلك ، فإن المهاجم قادر على رفض تحديث sigchain أو استرجاع sigchain للمستخدم إلى حالة سابقة عن طريق اقتطاع الروابط اللاحقة في السلسلة"

تقوم Keybase باستخدام مكثف لهياكل البيانات العامة الملحقة فقط غير القابلة للتطبيق والتي تجبر البنية التحتية للخادم على التقاط تمثيل حقيقي لمعرفات المستخدم. يمكننا أن نضمن استدعاء الأجهزة وإزالة أعضاء المجموعة بطريقة لا يمكن أن يتراجع فيها الخادم المشكوك فيه. إذا قرر الخادم إظهار طريقة عرض غير متسقة ، يصبح هذا الانحراف جزءًا من السجل العام الثابت. يمكن لعملاء Keybase أو مدقق لجهة خارجية اكتشاف عدم التطابق في أي وقت بعد الهجوم. نعتقد أن هذه الضمانات تفوق بكثير ضمانات المنتجات المنافسة ، وهي مثالية تقريبًا ، مع مراعاة القيود العملية للهواتف المحمولة والعملاء ذوي القدرة المحدودة للحوسبة.

ببساطة ، Keybase لا يمكن أن يخترع توقيعات شخص آخر. مثل أي خادم ، يمكن أن تعقد البيانات. لكن شجرة Merkle الشفافة الخاصة بنا مصممة لتخزينها لفترة زمنية قصيرة للغاية ، ويمكن اكتشافها دائمًا.

كيف تتعامل Keybase مع إعادة تعيين الحساب؟

عندما يفقد مستخدمو Keybase بالفعل جميع أجهزتهم (على عكس إضافة أجهزة جديدة أو فقدان عدد قليل) ، فإنهم بحاجة إلى إعادة التعيين. بعد إعادة تعيين الحساب ، يكون المستخدم جديدًا بشكل أساسي ، لكن لديه نفس اسم المستخدم. لا يمكنه التوقيع على "تعليمات إعادة الضبط" لأنه فقد كل مفاتيحه. بدلاً من ذلك ، يرتكز خادم Keybase العبارة غير القابلة للمسح على شجرة Merkle ، مما يعني إعادة التعيين. يفرض العملاء استحالة إعادة هذه التعليمات. في مقال مقبل ، سيتم وصف آليات محددة بالتفصيل.

سيتعين على هذا المستخدم إعادة إضافة التحقق من الهوية (Twitter ، Github ، أيا كان) باستخدام المفاتيح الجديدة.

هل يمكن لخادم ببساطة تبديل ورقة شجرة Merkle لشخص ما للإعلان عن مجموعة مختلفة تمامًا من المفاتيح؟

يفكر مؤلفو NCC في وجود خادم Keybase معادي يقوم بتغيير ورقة شجرة Merkle تمامًا ، ليحل محل مجموعة مفاتيح Bob الحقيقية بمجموعة وهمية جديدة تمامًا. خادم الهجوم له خياران. أولاً ، يمكنه أن يتخيل حالة العالم بوضع بوب في مفترق ، وأولئك الذين يريد خداعهم في آخر. ثانياً ، يمكنه "الغش" من خلال نشر نسخة من شجرة Merkle مع المجموعة الصحيحة من مفاتيح بوب والإصدارات الأخرى مع مجموعة وهمية. يكتشف المستخدمون الذين يتفاعلون بانتظام مع Bob هذا الهجوم ، حيث سيتحققون من أن الإصدارات التي تم تنزيلها مسبقًا من محفوظات Bob هي بادئات صالحة للإصدارات الجديدة التي يقومون بتنزيلها من الخادم. ستلاحظ أيضًا مهاجمة الجهات الخارجية التي تفحص جميع تحديثات Keybase. إذا قمت بكتابة مدقق Keybase تابع لجهة خارجية نود ، فيمكننا تقديم مكافأة كبيرة. الرجوع إلى max على Keybase. خلاف ذلك ، نأمل أن نخطط قريبًا لإنشاء مدقق مستقل.

هل تصدق ما قرأته حتى النهاية؟

قراءة أو مجرد التمرير لأسفل؟