تنسيق سلك الكابلات

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

تسلسل مجموعة المفاتيح

يستخدم Tink Google protobuf لتسلسل مجموعات المفاتيح.

• مجموعة مفاتيح ثنائية مُسلسلة هي ملف proto مُسلسل لمجموعة مفاتيح تم تحديده في tink.proto. سمة قيمة KeyData للمفتاح هي ملف برمجي proto مُسلسل لنوع المفتاح المقابل.
• مجموعة مفاتيح مُسلسلة بتنسيق JSON هي ملف تعريف Keyset proto مُسلسل بتنسيق JSON. يُرجى العلم أنّ قيمة KeyData لا تزال ثنائية مُسلسلة.
• مجموعة مفاتيح مشفّرة هي ملف تعريف EncryptedKeyset مُسلسل تم تحديده في tink.proto. يحتوي على مجموعة مفاتيح مشفَّرة ثنائية تسلسلية وبعض البيانات الوصفية غير المشفَّرة لـ KeysetInfo اختياريًا.

بادئة نتائج Tink

تتوافق معظم عناصر Tink الأساسية مع بادئة إخراج تتألف من 5 بايت وتتضمّن ما يلي:

• الإصدار الذي يتضمّن بايتة واحدة: 0x01
• تلميح المفتاح المكوّن من 4 بايت: هذا هو معرّف المفتاح المستخدَم.

قد تتيح بعض المفاتيح القديمة أيضًا استخدام البايت الخاص بالإصدار 0x00.

يُرجى العلم أنّه لم يتمّت مصادقة هذه البادئة ولا يمكن الاعتماد عليها لأغراض الأمان. وتستخدم Tink هذه المعلومات كإشارة لتسريع عملية فك التشفير أو إثبات الهوية.

AEAD

بشكل عام، تُعدِّل Tink نصوص التشفير بتشفير AEAD على النحو التالي:

prefix || IV || ciphertext || tag

ما لم يُنصّ على خلاف ذلك في طلب RFC المقابل. يكون prefix إما فارغًا أو بادئة إخراج Tink بسعة 5 بايت.

‫AES-CTR-HMAC

بالنسبة إلى AES-CTR-HMAC، تحسب Tink معرّف الالتفاف المميّز بالبيانات المرتبطة (AD) على النحو التالي:

AD || IV || ciphertext || bitlen(AD)

حيث يكون bitlen(AD) هو طول الإعلان بالبت ويتم تمثيله على أنّه عدد صحيح بدون علامة بترميز Big Endian بسعة 64 بت. يتّبع مخطّط HMAC هذا مسودة AES-CBC-HMAC من Mcgrew.

AEAD الحتمي

تُنفِّذ Tink معيار RFC 5297 لتشفير AES-SIV، مع وضع ملف بدء التشفير (SIV) الاصطناعي في بداية النص المشفَّر. قد تضيف القيمة الأساسية بادئة إخراج Tink بحجم 5 بايت.

على الرغم من أنّ معيار RFC 5297 يتيح استخدام قائمة بالبيانات المرتبطة، لا يتيح Tink سوى استخدام بيانات مرتبطة واحدة بالضبط، ما يتوافق مع قائمة تتضمّن عنصرًا واحدًا في RFC 5297. البيانات المرتبطة الفارغة هي قائمة تحتوي على عنصر فارغ واحد، وليست قائمة فارغة.

بث AEAD

راجِع AES-CTR HMAC و AES-GCM-HKDF.

التشفير بطبقتَين

يشفّر "التشفير المُغلف" البيانات باستخدام مفتاح تشفير البيانات DEK باستخدام مبادئ التشفير الموحّد للتشفير والتشفير الموحّد للتشفير والتوقيع (AEAD) من Tink. تعمل ميزة التشفير على النحو التالي:

• يتم إنشاء DEK جديد باستخدام نموذج مفتاح معيّن (أو مَعلمات مفتاح).
• يتم تسلسل DEK إلى سلسلة بايت. تنسيق التسلسل هو تسلسل بروتوكول وحدة تخزين مؤقتة لنوع المفتاح proto. على سبيل المثال، هذه رسالة AesGcmKey في مخزن بروتوكول مؤقت تم تسلسلها وتعريفها في ملف aes_gcm.proto لمفتاح تشفير البيانات (DEK) من نوع مفتاح AES GCM. اطّلِع على تسلسل آلية سَلسلة البيانات المنظّمة لمعرفة كيفية تسلسل آلية سَلسلة البيانات المنظّمة.
• يتم تشفير DEK التسلسلي من قِبل مقدّم خدمة خارجي (مثل Google Cloud Platform)، ويُحوَّل إلى encrypted DEK.
• يُستخدَم DEK لتشفير النص العادي مع البيانات المرتبطة به إلى ciphertext. وبالتالي، يكون ciphertext بالشكل نفسه تمامًا لعنصر AEAD primitiv المرتبط بـ DEK.

تنسيق الإخراج لتشفير المظروف هو كما يلي:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length هو 4 بايت، ويخزّن طول encrypted DEK كعدد صحيح بترتيب البتات الكبير بسعة 32 بت.

التحكم في الوصول للوسائط

يتّبع Tink طلبات RFC المقابلة. قد تضيف العناصر الأساسية بادئة ناتجة عن Tink بحجم 5 بايت إلى العلامة.

مجموعة PRF

يتّبع Tink طلبات RFC المقابلة. يُرجى العِلم أنّ نوع المفتاح في مجموعة PRF يختلف عن نوع مفتاح MAC في الخوارزمية نفسها بسبب عدم تضمين طول الإخراج. لا تُضيف مفاتيح مجموعة PRF أبدًا بادئة إخراج Tink. يضمن ذلك أنّ الناتج هو ملف PRF.

التشفير المختلط

تنسيق الرسالة العام لتشفير Tink المختلط هو كما يلي:

prefix || encapsulated_key || encrypted_data

prefix إما فارغ أو بادئة إخراج Tink بسعة 5 بايت. يحتوي كل نوع مفتاح على معلومات عن عدد وحدات البايت التي يجب تحليلها وكيفية تحليل وحدات البايت هذه من encapsulated_key.

HPKE (التشفير المختلط للمفتاح العام)

يتّبع Tink معيار HPKE المحدّد في RFC 9180. تتضمّن مجموعة التشفير HPKE العناصر الأساسية الثلاثة التالية.

• آلية تشفير المفاتيح (KEM)
• دالة اشتقاق المفاتيح (KDF)
• التشفير المُعتمَد بالبيانات المرتبطة (AEAD)

لا يحدّد معيار HPKE تنسيقًا عامًا للبيانات في RFC 9180، القسم 10. يستخدم تطبيق HPKE في Tink قيم encapsulated_key وencrypted_data التالية.

• encapsulated_key
  • المفتاح العام للمُرسِل بتنسيق تسلسلي
  • تم تحديده على أنّه enc في RFC 9180، القسم 4.1
  • التنسيق الذي يحدّده مكوّن إدارة مفاتيح التشفير (KEM) في HPKE المُستخدَم
• encrypted_data
  • النص المشفَّر والعلامة (أي ‫ciphertext || tag بدون مفتاح التشفير العمودي)
  • تم تحديده على أنّه ct في الفقرة 4 من RFC 9180
  • التنسيق الذي يحدّده معيار HPKE AEAD المحدّد المستخدَم

دالة تشفير مفتاح مشترَك X25519 المستندة إلى خوارزمية Diffie-Hellman

بالنسبة إلى مخططات DHKEM‏ X25519، تكون القيمة enc هي المفتاح العمومي لتشفير Diffie-Hellman الذي يبلغ طوله 32 بايت والمملوك للمُرسِل.

ECIES-AEAD-HKDF

في عملية تنفيذ ECIES-AEAD-HKDF في Tink، يمثّل encapsulated_key ناتج آلية تشفير المفاتيح (KEM)، ويمثّل encrypted_data ناتج آلية تشفير البيانات (DEM).

KEM

استنادًا إلى نوع المفتاح، يستخدم Tink نقاط منحنى إهليلجي مكتوبة وغير مكتوبة، وذلك وفقًا لمعايير ترميز RFC 8422/ANSI.X9-62.2005. بالنسبة إلى النقاط غير المضغوطة، يتبع البايت 0x04 الإحداثي x والإحداثي y كأرقام صحيحة ذات حجم ثابت. بالنسبة إلى الإحداثيات المضغوطة، يتم استخدام البايت 0x02 أو 0x03 وإحداثية x كعدد صحيح بحجم ثابت. بالنسبة إلى X25519، يتم استخدام تعريف RFC 7748 (إحداثية x بالتنسيق عدد صحيح بحجم ثابت).

DEM

بالنسبة إلى encrypted_data، يستخدم Tink التنسيق نفسه المستخدَم في AEAD. ويشمل ذلك تحديد مفتاح تشفير.

اشتقاق المفتاح

أولاً، يتم احتساب الإحداثي x x_ss للنقطة المشتركة. يتم بعد ذلك ضبط مفتاح AEAD على:

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

حيث يكون encapsulated_key هو الناتج الكامل لبروتوكول KEM بالتنسيق البايت.

التوقيعات الرقمية

يتّبع Tink طلبات RFC المقابلة. قد تضيف العناصر الأساسية بادئة ناتجة من Tink تبلغ 5 بايت إلى العلامة التي يتم إنشاؤها.

ECDSA

استنادًا إلى حقل EcdsaSignatureEncoding في المفتاح، يكون تنسيق توقيع ECDSA إما IEEE P1363 أو ASN.1 DER.

تنسيق توقيع IEEE P1363 هو r || s، حيث يتم استخدام r وs كحشو صفري ويكون حجمهما بالبايت هو نفسه ترتيب المنحنى. على سبيل المثال، بالنسبة إلى منحنى NIST P-256، تتم إضافة صفر إلى r وs ليصبحا 32 بايت.

يتم ترميز توقيع DER باستخدام ASN.1:

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

وعلى وجه الخصوص، يكون الترميز على النحو التالي:

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

تتّبع Tink أفضل الممارسات لفحص التوقيعات، من خلال قبول توقيعات ECDSA بترميز DER فقط (التوقيعات البديلة بترميز BER غير صالحة).

ويساعد ذلك في منع هجمات قابلية التلاعب بالتوقيعات، التي غالبًا ما تؤثر في أنظمة العملات المشفّرة.